polymorphic cipher

Hmm.. the Giant Polymorphic Block Cipher is about integrity and all of my implementations provide an extra parameter for encryption and decryption routines that changes the internal state for each encryption/decryption operation.
It's phantastic that you ask!
Here's the scenario with "standard" ciphers: Let's say an RTP or HTTP or whatever Internet Protocol data packet is to be encrypted: With 128 bit block size (16 bytes only!) it is highly likely that the very same information is encrypted again and again - notably the header of the respective protocol. This problem is less and less significant the larger the block size is as payload data is likely to be different, but not the data that is found in headers.
With MTU sizes rarely exceeding 1492 bytes, large block sizes are not at all feasible due to inevitable overhead for padding (filling not fully used blocks with zeroes or ones). So I've proposed the Giant Polymorphic Block Cipher. If your data is 1327 bytes in length, the ciphertext is 1327 bytes long. If an image file is 1127981 bytes in size, the ciphertext will as well be 1127981 bytes long AND the data will be encrypted in a SINGLE block by a Luby-Rackoff construction. In contrast to AES or whatever standard cipher, the SAC (strict avalanche criterion), something that is even more basic in order to parry chosen plaintext/chosen ciphertext or any combinaion of such attacks, is truly satisfied by such a design.
I should probably mention that I'm most probably holding the world record in block size with (currently) 4 gigabytes. Source code is available here:
http://downloads.turbocrypt.com/sou...code_breaker_64bit_wo_encryption_routines.zip

Why don't you answer to questions? You constantly raise topics that you suppose that they were not sufficiently addressed.
The reality is this: Severe deficiencies of (in my opinion) obsolete designs resulting from minimalistic construction (atomic block size, lack in variability, lack in number of parameters that help programmers to implement those ciphers properly) can be adressed by new designs and, believe it or not, have been addressed by me and it is almost certain that I'm only the first who does this. Maybe you are unfamiliar with the concept of engineering. So here's an example:
Let's say that only carriages with horses exist and an engineer sees a brand new super cool V8 diesel injection engine used to generate electricity at a power station. An engineer quickly realizes that horses are fun to watch, but that they are pretty slow. That engineer might thus be able to make a ground-breaking invention by replacing the horse by that freakin' motor. And - voilá - transportation of human beings is revolutionized!
What if other designers of encryption algorithms read this and also realize that some aspects of my work are somewhat ok?

Would be nice, wouldn't it?

 

Coarse block lengths make manipulation harder, as was employed by Microsoft BitLocker, but the best they offer is "poor-man's authentication." There's still no proper integrity check; you're just hoping the manipulation leads to something other than the adversary's desired effect. Unless you're dealing with constraints that can't afford a MAC, you shouldn't avoid using one.

To make sure I understand, is PMC a stream or block cipher? You're taking a lot of cryptographically weak generators, and calling it a Luby-Rackoff construction because you're applying three rounds of what you hope are secure round functions. That, and it seems that the block cipher can handle an arbitrary block length; that is, whatever the length is of what you're encrypting, that's your block length. But that's what a stream cipher does, essentially. Could you clarify, please?

Most, if not all, of the AES finalists exhibited pretty good stability in regards to SAC; the S-boxes of Rijndael can achieve it. Are you saying that after only three rounds of stringing together weak generators, you've achieved SAC?

But million-bit Virtual Matrix Encryption has you beat on key length. (I threw this in to keep things as lighthearted as possible.)

They haven't been; if they have, you've also invented your own way of proposing, which will require decrypting first before anything else can follow.

But if code is where we most often find problems -- rarely ever the cryptography -- then it would make sense to design with code simplicity in mind. Therefore, it's good to be minimalist and not burden developers with a plethora of options. After all, why ask developers to make cryptographic decisions when it's outside of their expertise?

 

Hmm , yes good to remember that!
It would not surprise me, that often the encryption software is trusted
because the cipher used is trusted.


Justin,berndroellgen,

I appreciate this,

Please continue to use less abbreviations or explain them as was done here.
Some of us do have to do some homework to completely understand this jargon,
and remember, some also have to translate even the whole text, to their own language.

Slowly we are getting more insight in this cipher,
keep up this good work!

 

+1

 

That product, as well as Truecrypt, has an even bigger issue: There's commercial software out there that breaks it. Shouldn't such issues be addressed first? I wonder what you might do as a captain when your ship sinks: a) make sure that your hairstyle is ok or b) try to make all pumps run so that you can somehow keep the boat above the water line.
As the thread is extremely long, it might be good to clarify once again that none of the encryption software that I've so far written has ever been cracked - in contrast to the software that is heavily supported by people who claim that they want to help to improve the security of data security applications.

Luby-Rackoff has nothing to do with motor oil, but a bit more with block ciphers and you pretty well know that.
http://citeseerx.ist.psu.edu/viewdo...33F872A8?doi=10.1.1.26.1042&rep=rep1&type=pdf

Luby and Rackoff provided in 1988 a proof for the underlying principle of the "Feistel cipher" by Horst Feistel (with DES being a weak version of that thing). This passage from http://en.wikipedia.org/wiki/Feistel_cipher summarizes things quite well:
"Michael Luby and Charles Rackoff analyzed the Feistel cipher construction, and proved that if the round function is a cryptographically secure pseudorandom function, with Ki used as the seed, then 3 rounds is sufficient to make the block cipher a pseudorandom permutation, while 4 rounds is sufficient to make it a "strong" pseudorandom permutation (which means that it remains pseudorandom even to an adversary who gets oracle access to its inverse permutation)."
Such ciphers don't need to be balanced (e.g. Skipjack) and nobody has postulated any limit in size for the left and right pieces L and R.

What is the SAC? In simple words: Let's say that 1kB of payload data (e.g. on a network data packet) needs to be encrypted (8kbit). If approx. half of those 8kbit of the ciphertext change their state compared with a previous encryption with only 1 plaintext bit flipped, then the SAC is OK. So if bit # 7988 changes from 0 to 1 in the plaintext and approx 50% of the ciphertext bits 0 .. 8191 differ in the resulting ciphertexts, the SAC is good.
But all AES finalists are 128 bit ciphers (block length is 128 bit). SAC is certainly good within those 16 bytes with or without CBC mode (ciphertext chaining). But starting with byte # 17, the first block has already been encrypted and there is no way for any bit in bytes #16 to 1023, which account for almost 100% of the size of the data packet, to influence ciphertext bytes #0 to 15. This is a clear advantage for an attacker as he will focus on the first block.
The SAC of ANY cipher with a block size < exactly 8192 bit block size is thus INEVITABLY bad.
An attacker knows that the first (approx.) 16 bytes of an IP data packet are STATIC (source IP address, destination IP adress, fixed identifiers, etc.).
Using stream ciphers for securing IP data packets is even worse! After the first chunk of data (usually 1 byte granularity) has been encrypted using logical XOR, the following data has NO effect any more on the encipherment of that first byte. This, in conjunction with known issues of the ARCFOUR stream cipher) was the decisive deficiency of WEP (for securing wires LAN connections).
In contrast has a block cipher with variable block size the phantastic feature that each and every plaintext bit in a block influences the encryption of each and every other bit in that block (and the following blocks if CBC mode of some sort is being used). I've taken this so far up to the size of a movie on DVD. A change in one bit affects the encryption of each other bit.
Here I want to stress the following: This is a real eye-opener! Yes, this is possible. The maths behind this are simple. Of course it is possible to create ciphers supporting this important feature (especially important for internet data packets). If future ciphers have this capability, it might be because of the information contained in this thread. People, please open your eyes! There are so many sharks out there who try to contaminate open discussions. But I think it's worth to encourage designers of encryption algorithms (and encryption software) to implement features that put their designs in a new century!

I've asked why Mr. T never answers any questions, especially when they are about software that he might even have promoted with that software featuring one or more blatant security holes. Obviouly my English is too bad to characterize this behaviour properly.

Hmm, are we all idiots?

 

Hmm it seems as if you could turn this around as well.

 

The commercial software "breaking" you speak of were simply side channel attacks or memory dumping software. Do you mean to say that the PMC is immune to such attacks, and if so, how did you achieve that?

 

No news of X942 yet,

I,ve seen that the Polymorhic cipher was available since 2003, no flaw or breach or weakness in the software has been reporterted yet, as far as i can find.
If anyone here knows of any please let us know.
Now Berndroellgen has even handed the sources over?!
Yesterday i watched a documentary on Discovery channel, on Bletchley park, where the British secret service codebreakers worked to break the Enigma machine during WW2.
And i realized that for us as none-experts it is rather strange, that if you make a new cipher,
you have to hand over the sources or write a book on the details to have it valued by encryption experts?
It is like the British to ask their 'enemy' may we see the sources of your Enigma encryption so we can see if it is a strong one? ( of course i understand, but it is funny)
If the cipher is truly as strong as the creator claims, handing over these sources seems like a logical step to ever have is cipher aproved.
I can't hardly believe it 'snake oil'.
if there are weak spots in the cipher, why is there not one of the experts who wants to inform us how the cipher can be broken?
The fact is, that there is written evendence that several experts had a look at it.
A new cipher, although brought by an outsider must have their attention.
And i think it is their moral obligation to inform us if it is safe or not and why so.

But if the cipher is strong, who is able to officially say so?

First i hope X942 will inform us.
But if he can't find a weak spot,

Q:can anyone inform us what else must be done to ever know if it is safe?

 

I have stayed out of this as Justin is a professional and has handled himself as such. I, frankly, have a problem with the PMC approach of pushing their cipher. I think a lot of it boils down to this: What's wrong with the established channels that work for every other serious cryptographer?

 

That's because nobody gives a damn about it. No one is going to waste their time trying to break something that no one is going to use. And the only way to get people interested in it is to produce well written documents about it that "experts" would want to read. I'm not in the cryptography field, so I couldn't analyze it even if I wanted to, but I'll never go anywhere near the cipher as a user. The materials presenting it look like something done for a sleazy late night infomercial by someone just out to make a buck. You may not like that answer, but if you don't present professional looking materials you aren't going to get anyone to take you seriously.

 

You're referring to BitLocker, I know; you've tried this once before. I wrote an analytical paper on BitLocker for Microsoft TechNet Magazine some years ago, before the cold boot attacks. I praised the cryptographic design decisions behind it, given the tough constraints they were working with. When the cold boot attacks surfaced, you called my credibility into question. Of course, my paper was about the risky, yet conservative, choice of introducing the new-at-the-time Elephant diffuser for providing some level of integrity preservation where a proper MAC couldn't fit.

With Twofish co-designer Niels Ferguson having been responsible for this decision, it was a clear sign that cryptographic expertise was behind the scenes. Unfortunately for your argument, cold boot attacks aren't direct cryptographic attacks; they're side channel attacks on the implementation; as such, your point was irrelevant. Cold boot attacks are certainly intriguing, and side channels must be addressed, but perhaps you were a little overly ambitious in proving me wrong on something.

Your answers to my PMC-specific questions are usually questions themselves, asking me about the (in)security of other software; sure, other software does have issues. Real-world security and privacy tools suffer in many regards, but this discussion is supposed to be about why PMC is good -- not why everything else is bad.

And so it goes that I'll ask for one thing and get another. SAC (Strict Avalanche Criterion) statistics? I get a Wikipedia quote on what SAC is, and a lot of off-topic rhetoric in between. I ask for information regarding notions of security (e.g., IND-CPA, IND-CCA2), integrity preservation (e.g., MAC), and other foundational elements of cryptographic design, and get something other than the answer in return. I'm at a loss as to why someone so adamant about their design's security wouldn't at least attempt to present it using models that we understand.

Decisions should match the expertise of the decision maker. For example, patients aren't tasked with making a self-diagnosis of their own medical symptoms and coming up with an ad-hoc pharmaceutical regimen for addressing that diagnosis. No, they go to a doctor who makes that diagnosis for them given their symptoms, and prescribes them something that a pharmacist will dispense to them, accompanied by proper dosage. The medical process requires these levels of expertise in order to function -- so does the cryptographic process.

I feel that I've been civil thus far, and have tried to point out unaddressed concerns that would apply to PMC in the real world, yet I don't see how this discussion will ever produce anything useful for readers. Unfortunately, it has been made apparent that the author's personal prestige is the most important aspect of this ordeal, with the plethora of self-aggrandizing statements. Ultimate this, world's fastest, biggest, and best that, I'm the first one to do this, and so on and so forth. This type of arrogance repels any serious attention; that, and the utter lack of ability to accept criticism of any kind paints a picture of a product whose strength depends more on thick layers of marketing than cryptography itself.

Perhaps we should wrap this up -- at least between you and I -- in respect to readers who are looking for substance instead of verbal sparring. As an incentive, feel free to have the final word, claim victory, and carry on promoting the unscathed PMC. As always, none of this has ever been personal -- just about cryptographic know-how. The cryptographic community thrives because of respectful dialogue that gives no mercy to the designs themselves, but such a thing has eluded this dialogue, and that's unfortunate. To potential users of PMC, there's a reason this author, and his product, is relatively unknown; when it is referenced, it's within the context of snake oil. The reason, however, is not that the entire cryptographic community has a personal vendetta against the author, or cryptographic progress.

 

I tip my hat to you Mr. Troutman you made it through 5 pages of their endless circles around your honest attempts at discussion. I only made it to page 2 before the arrogance and misinformation proved to be too much. Thanks for sticking around and at least trying to address the original issues around PMC. I do believe you hit the nail in the head with the paragraph I quoted you on and you kept it classier than most would in this scenario.

 

This is not very scientific.
Please stick to the subject , the cipher rather then the person and his marketing again.

What i like to know as a user of encryption software is:

1) If i encrypt a file with this software can it be broken? (i did not see an answer on that)

2) There are threads that are much and much longer, so that is not a reason to end the discussion without an answer on 1)

3) I see that both parties are not answering some questions.

X492 any news yet ??

 

Justin has made every attempt in this thread to stick to scientific arguments, and the responses he got in return were pseudo-scientific. Thanks Justin for sticking around.

I feel that this has been answered many times in this thread: in order to determine if a cipher is safe, it would need to undergo years of testing by the community - this is the only way to get your answer, that is how it works with mathematics - just look at how long it is taking X942 to do a ''simple'' randomness test, which only really begins to scratch the surface of actual cryptanalysis. And PMC is simply not going to get that kind of attention unless Bernd changes his approach and convinces the experts that his product is really worth spending tons of their valuable time to analyse. And yes, the author's approach has A LOT to do with how his product is perceived - you can't completely separate the too, no matter how good a product potentially might be.

I don't think the discussion will end We'll get X942's analysis and hopefully it'll resume from there.

At a risk of sounding biased; the questions Justin didn't answer I felt were irrelevant, while the questions Bernd didn't answer had everything to do with the fundamental security of the PMC. Just my opinion

 

Of course i respect your opinion syncmaster913n.
The fact that people sometimes think different on a subject here,
will in most cases provide more information and insight.

He was disassembling the software wasn't he?

 

I think that at some point he said he doesn't need to do that anymore, since he now has the source code. I'm not sure though.

 

In most cases I didn't receive any answer at all ! "Because my questions are difficult to decrypt".

*

 

Did you find any other ?

 

* stands for deleted content. My post wasn't that short.
Here's the important part of it and this one is clearly NOT off topic:

Part of this is true - except for the cold-boot attack thing !
Here's the original text from this thread:
https://www.wilderssecurity.com/showthread.php?t=285136

Ok, Mr. Troutman, I agree that it's good to be frank:

You more than less belong to extorque.com. Right? I think that you ARE extorque.com.
You've written this paper here in 2007:
http://www.extorque.com/files/bitlocker.pdf

Right?

"The link that I gave you yesterday (http://www.lostpassword.com/hdd-decryption.htm) addresses an inherent weakness of two popular encryption products.
These guys write: ".. Passware Kit scans the physical memory image file (acquired while the encrypted BitLocker or TrueCrypt disk was mounted, even if the target computer was locked), extracts all the encryption keys, and decrypts the given volume".

Ouch! I begin to understand why you don't want to have a closer look at Passware Kit! The truth might be pretty embarrassing!"

"Cold boot attack" can be applied to any DRAM chip in this world: Freeze it and the leakage current of the capacitors in the dynamic RAM (DRAM) cells falls to almost zero. Even after hours the entire content of the DRAM of a PC can thus be read out and it can undergo forensic analysis. Well, it's hard to image that my tablet PC can be cooled down to the boiling point of liquid nitrogen (77,36 K = -195,79 °C) and I don't notice that.

An attack that is based on some piece of software having Ring 0 access to the DRAM of a computer anytime during runtime is an entirely different thing as it is very feasible for trojan horses or other malicious software and it can even be built into Operating Systems!
".. Passware Kit scans the physical memory image file (acquired while the encrypted BitLocker or TrueCrypt disk was mounted, even if the target computer was locked), extracts all the encryption keys, and decrypts the given volume".
The Windows kernel definetely has Ring0 access.
This guy possibly as well (June 21, 200:
http://www.codeproject.com/Articles/27162/Entering-Ring-0-using-minimalistic-approach
This nice program appears to make use of Ring0 access since at least 2007:
http://en.wikipedia.org/wiki/Cheat_Engine

As a matter of fact, plenty of people appear to be able to scan any location in physical memory of a PC.

Why is my disk encryption software not on the list of products that can (so far) be broken with that tool?

 

Unfortunately not, I was only able to find the source codes for them, but no software that actually uses them. I haven't searched thoroughly yet though, which is why I haven't gotten back to you yet on this But it does seem to be a difficult task

I would guess that this is because it is unknown, no offence.

Can you tell us where does the your software store the key for a PMC cipher while the encrypted hard drive is mounted?

 

Wow i did not know that truecrypt drives could be broken dat easy
Especially shocked about the "hiberfil.sys" story.

berndroellgen, in this case a second encryption could save the day or not?
I asked that earlier in this thread , i prefer to use a combination of ciphers.
If i create a TrueCrypt drive or container, mount it and store my data in a file on it,
and encrypt that file again with another cipher, it can't be broken with this software!
For me this is a fact, this is clearly the difference between theory and the way things are implemented.
And not very complicated.

Also regarding the implementation and explenation of the block lenght,
of the polymorphic cipher,
makes clear that you did not only think about the encryption algorthm but also on the implementation of the software it can be used in.

I've been trialing your software, and i am now convinced i am safer with a
combination with the Polymorphic cipher or any other that could be found.

It must be clear now, that since the sources are available ,
almost like open source software , the cipher must be well studied by your opponents, and it must have past the first impression.

X942 mentionend that he has unmasked another cipher, that it only did a xor
even when that cipher was used as a second encryption, it might have helped some against the attack mentioned above, although i would never reccomend it of course.
Yeh it seems good not to bet on one horse.

 

Every cipher that stores the keys in memory while a container is mounted (ie. ALL ciphers, as far as I know) can be "broken" this way. It is not a weakness of the cipher itself; it is kind of like having a keylogger on your machine and saying that it is a weakness of the cipher because the keylogger can reveal your password. If a container is mounted, the key must be accessible somewhere for constant on-the-fly encryption/decryption - that place can either be your hard drive (slow/risky), or your memory (fast / more secure). There is no other place in your PC to store this data.

After the container has been dismounted, the key disappears from RAM. So basically what this software actually does is it allows you to get the key to a container, if that container is mounted....if the container is mounted, then your data is already plainly available to see for anyone with access to your computer, so they wouldn't even need the key. This has been mentioned at least a few times in this thread, yet it seems like you and Bernd are completely oblivious to it. You cannot leave your system with decrypted data unattended. If you do, it doesn't matter how good the cipher is.

As for the hibernation file - one of the prime requirements for using any software encryption is to disable hibernation on your system. It is among the most important security requirements in the TrueCrypt documentation - http://www.truecrypt.org/docs/ (search for "hibernation file" in the left-hand menu). This is encryption 101 basics and from what I can say it's been known since the dawn of time.

Again, I would like it for Mr. Bernd to explain how he manages to protect against memory dumping or analysis of the hiberfile (which is essentially a dump of your RAM content at the time the hibernation takes place), particularly in the case of whole drive encryption.

Me too. I even created a thread about this here: https://www.wilderssecurity.com/showthread.php?t=321749

See X942's response in particular.

However, I am using AES and Twofish.

Of course it CAN still be broken by this software. While the first container is mounted (the truecrypt one), the key to that container remains in memory. And when you mount the second container inside that first TrueCrypt container, the key of that second container will also be stored in memory, for as long as that container is mounted. Therefor, as long as you have access to the files, all keys are stored in RAM. And it won't matter if you are using 1, 2 or 20 different containers created with 20 different ciphers using 20 different software - at the time your files are decrypted, all of the keys of all the ciphers will be readily available in RAM for anyone to access. Of course, like I said above - if someone has access to your computer while your encrypted data container is mounted, you should worry about the files themselves, and not whether someone will retrieve the key to that data.

 

No problem syncmaster,

Perhaps my translation wasn't that good.
1) truecrypt create a container and mount it as a logical drive ( like f:\)
2) put your data in a file (word,txt,xls,jpg or zip etc) and file encrypt it
With another cipher in your case twofish

Often the truecrypt "drives" are open between the mounting of the drive and shutdown of the pc.

File encryption however ends after the file is encrypted (like a creating zip file)
and shouldn't be in memory anymore.

And yes i am also curious if Turbocrypt does not store plain text password in memory!

 

Yes, this is also what I was talking about. Example:

Truecrypt container (AES) is mounted as drive F:\
Another container (Twofish) is mounted inside drive F:\. Let's say that this container is G:\

The key for G:\ is readily available in memory, as long as G:\ is mounted.

At the same time, as long as G:\ is mounted, then it means that F:\ is also mounted (it has to be mounted in order for you to be able to access the G:\ container). Therefor, the key for F:\ is also readily available in memory. If someone were to gain access to your computer at this point and dump your memory, they would find the keys to both F:\ and G:\. So basically this multi-container approach will not help us at all against analysis of your RAM content's dump. The only way to be safe against it is to make sure that you unmount G:\ and F:\ after you are done using your private files, and never leave your computer unattended while the container(s) are mounted.

Let me know if this is clear.

 

Syncmaster, the second file is NOT a mountable container,
But a file only just like a encrypted zip file.

And i was just started to read this:
http://www.pmc-ciphers.com/eng/content/TurboCrypt/Mount-Control-Code-Attack.html

He is something new for you

he explains why turbocrypt doesn't store passwords as plain tekst in memory, i had the idea the was solved in truecrypt by now also.
See: "Countermeasure against the MOUNT Control Code Attack"
He used Diffie-Hellman for this if i understand this correctly.

But berndroellgen or X942 must be better able to explain this