polymorphic cipher

Ah ok, I understand now.

Well, yes, technically in this case the second file is safe against this kind of attack. However, it would still be safe even if you had not placed that file inside the AES container. Of course, placing the second file inside of a mountable container is probably safer, however it does not add any protection against this particular type of attack that we are discussing.

And remember: if the second file is decrypted (when you are using the data), even though there will be no key in memory, the data is still decrypted; anyone with access to the computer will be able to see it, without any keys. So you still need to make sure this data is only decrypted while you are using the files, and encrypt them again before leaving your computer unattended. So it's exactly the same outcome.

I will take a look at that link.

 

Perhaps this will make it easier for readers. In real-world systems that employ symmetric cryptography, there are specific notions of privacy and authenticity that we shoot for, and we know that authenticated encryption is necessary for achieving that, since encryption alone is useless against active, online attacks where attackers can inject and/or manipulate data.

Suppose we want to use the AES; we'd use it in a recommended mode of operation, like CTR. At this point, we'd need to authenticate (preserve the integrity of) the ciphertext, and we do this by using a MAC (Message Authentication Code). We can even use the AES for this part to, by using CMAC. So, we'd do AES-CTR-then-AES-CMAC.

This construction achieves the two notions of privacy and authenticity that we want: IND-CCA2, which protects against adaptive chosen-ciphertext attacks, and INT-CTXT, which preserves the integrity of ciphertext. But for this to happen, we must always authenticate the ciphertext; there's really no better way to do.

PMC is no exception, since it's essentially a hodgepodge of several weak generators; the ciphertext needs to be authenticated, yet a proper MAC is absent from any documentation or discussion regarding PMC. If there isn't a dedicated mechanism for preserving integrity, then PMC would have only the option of resorting to the very designs its author finds inferior. With that said, it's logical to conclude that PMC cannot satisfy these notions, and is therefore insecure in real-world implementations.

Briefly touching on the BitLocker issue; once again, and lastly, my paper praises the AES-CBC+Elephant diffuser design decision as a risky, yet calculated and conservative, move. The only attacks mentioned here, in regards to BitLocker, are attacks on the physical implementation; they are neither cryptanalytical nor affect the cryptographic primitives in use. Therefore, they are irrelevant to my past article. I really don't know what else to say here to make this any clearer.

 

I will be posting updates ASAP. I have been insanely busy with work.

The sources will help, but I am still reversing it to be sure nothing was 'added' in to the compiled version.

Drop the BS on Cold Boot attacks already. I just dumped the key from a mounter turbocrypt volume easily. This doesn't mean the cipher is broken, only that a side-channel is available.

If you think that this software is so able to crack truecrypt then lets put money up for it (just like you like too).

LINK: http://www.box.com/s/05d410a4b242520a6113

What is in it? A bitcoin wallet with $1000USD in it. You crack it you get it! I will leave the wallet full for 30-days after which I will use my copy of the wallet and transfer the funds back to me. Have fun.

Info:

Code:

10MB file
AES-256
64 Char. ASCII password Randomly Generated
MD5 HASH:564d7f18a933c6d93a1849d2ecc0b56d 
SHA256 HASH: 815f2cf9412856782ba1986b2a6ddcd95d8b6e0f8a410dc2dabf1279322c0791

 

Thanks Justin and x942

 

and

Totally correct. The password will be there this way or another and a piece of software that spies out this info can as well be on a computer. One can even be sure that is IS on the computer as this attack is so phantastically versatile.

This is the entire interface of AES (seen from a programmer's view):
int aes_set_key( struct aes_context *ctx, uint8 *key, int nbits );
void aes_encrypt( struct aes_context *ctx, uint8 data[16] );
void aes_decrypt( struct aes_context *ctx, uint8 data[16] );

This is what stays over for AES to function after aes_set_key() has been called:
struct aes_context
{
int nr; // number of rounds
uint32 erk[64]; // encryption round keys
uint32 drk[64]; // decryption round keys
};

So the key is simply converted into 256 bytes for the encryption round keys and 256 bit for the decryption round keys.

Encryption works this way for disk encryption software if counter mode (CTR) is used: XOR plaintext with the sector number and a block counter and call encrypt().

Now the important aspect: The round keys stay the same all the time!!!

PMC: The Internal State of the cipher (which is several kilobytes or more) is first altered and only then encryption is performed.

This makes an attack that takes snapshots of the Device Extension of the driver difficult. The Device Extension is the place in RAM where the driver stores all the data. The exact location in RAM is determined by the Operating System.

syncmaster913n is actually totally right. The Polymorphic cipher used in TurboCrypt has although been hardened as good as possible against such attacks. But the result could be better. This is for sure.

One thing can be learned from this: different applications may require different ciphers !!!
Example: A cipher that is used for smart card applications should really resist "Power Attacks" like DPA (Differential Power Attack).
On a PC, a power attack will certainly not be feasible. But on a PC it is well possible to read the Internal State of the cipher at any time. So it's definitely good if a cipher used for disk encryption or file encryption changes the Internal State frequently and if possible, data should only be accessible through pointers. By doing this, memory dumps of gigantic size may be needed for an attacker to succeed.
The Giant Polymorphic Block Cipher takes advantage of that. At 4GB block size, the Internal State is 1.5GB in size (as far as I remember).

This should sum things up for this question.

 

True. This will work. But on the other hand it would be nice if the disk encryption software was secure in the first place!
As long as the computer has no network connection, things are quite easy.

By analyzing the insufficiencies of existing applications like Truecrypt or E4M (Encryption for Masses) which appears to be the "mother" of all disk encryption programs, I had to realize that a brand new cipher had to be designed and that some "extras" needed to be implemented into the software as well. I quickly realized that the entire thing needed to be rewritten !

This here is one of the extras:

The password is the primary target and the mount process is where that data is usually passed as plaintext to the operating system. To somebody who either makes the OS or who can hook into the DeviceIoControl() function of the OS, this is even easier than searching for key data in the RAM that is reserved for the kernel and for drivers.

Internal state: yes. key: very unlikely. Why? Because the password is first decrypted, then fed into the routine that initializes the Internal State (either AES or PMC) and then the password is "burned". I've checked the source code moments ago as I don't remember every detail after four years.

Niels Ferguson writes this:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=13866
"2.4 Poor-man's authentication
That leaves us with an encryption algorithm that provides no authentication, yet we need authentication to provide a secure boot process. The best solution is to use poor-man's authentication: encrypt the data and trust to the fact that changes in the ciphertext do not translate to semantically sensible changes to the plaintext. For example, an attacker can change the ciphertext of an executable, but if the new plaintext is effectively random we can hope that there is a far higher chance that the changes will crash the machine or application rather than doing something the attacker wants. To get the best possible poor-man's authentication we want the BitLocker encryption algorithm to behave like a block cipher with a block size of 512 -8192 bytes. This way, if the attacker changes any part of the ciphertext, all of the plaintext for that sector is modified in a random way."

The man is totally right! I'm using a 1024 bit cipher, which provides sufficient margin to pass back nonsense information if only one ciphertext bit is altered.

Background: a disk encryption driver gets let's say four sectors, each 512 bytes long from the driver stack, and it CAN ONLY SEND BACK 4 x 512 bytes to the driver stack. Mr. Ferguson writes on page 9: "However, making the ciphertext larger than the plaintext is not feasible."

Very true. Conclusion: A block cipher with 1024 does the job very well. BTW this is a problem of disk encryption: A single bit flips and one cannot read an entire sector! This is why manufacturers of such software with pre-boot authentication always have a tough time when they must tell customers that their data cannot be recovered any more.

Readers can try this: Change a bit in one sector of an encrypted volume, then mount that volume and see what happens: If you've changed the boot sector, then the OS gets incredibly slow. It probably tries to saves the day by trying whatver it can do to recover the data. But it fails.
When you program a disk encryption driver, you'll see this happening very often during the debugging phase.

Here one can fully trust Mr. Ferguson as he uses the very same authentication method as everybody else who makes disk encryption.

 

Thanks berndroellgen

 

Just like AES/TrueCrypt/Bitlocker (as you mentioned) Your key has to be in plain text at some point and thus it is (in this case at least) in RAM. I am NOT referring to the user's password but the actual encryption key used to encrypt and decrypt the data.

Also I love how you ignored the TrueCrypt challenge I posted. What? Can't put your words into action? If passware can crack AES/truecrypt/bitlocker (With out the drive being mounted; using bruteforce) Than have at it. $1000USD for you if you get in. Somone downloaded it already.

You like challenges so come on. Break AES as you say the software can.

I will post proof of the RAM attack working against PMC later. Which according to you means PMC is "cracked". So what is it? Are you going to admit that RAM attacks are side-channels and break crypto in no way, shape, or form? Or are you saying PMC is "cracked" just like Truecrypt/Bitlocker?

Any one with any knowledge of crypto would answer the first one. Any one else *cough* you *cough* doesn't know what they are talking about and is just digging their hole deeper.

 

That would be me. I wanted to give it a go with some coworkers later. Though we will be using our own methods and only in it for the challenge not the money however check your inbox.

 

Haha! Good Luck! The password is completely random 64 Char. ASCII. Thats more permutations than a 256 bit symmetric key. (AKA you would be more likely to crack AES before the password).

 

Haha! Good Luck! The password is completely random 64 Char. ASCII64 Hahaha !

Why is that ?

see this the PMC cipher challenge:
http://www.pmc-ciphers.com/eng/content/Backround-Info/01-2012-challenge.html

Please change the password to the same length and specs, it is a bit strange to compare these 2 ciphers this way.

Is there one of the experts here that can calculate the difference in the number of possible passwords
Between these challenges?

 

There is no difference in possible passwords (x^y where x is character set and y is length.) It's a matter of how long it takes to generate keys.

The idea is that this polymorphic cypher takes longer than AES to generate the keys. Of course, it takes so long on either end that you'd need more energy than is contained on this planet to power machines capable of cracking AES 256bit.

edit in this particular challenge the difference is

26^3 + 4 against 26^64

that's for password length combinations.

 

It doesn't matter at all. These are two different challenges.

Bernd's challenge was geared towards brute forcing the password. Therefor it makes sens that in such a challenge the password would be relatively short.

x942's challenge is geared toward the software that according to Bernd supposidly "cracks" AES. This software doesn't mention anything regarding password length, so it makes no difference.

 

Actually it's
4 + (4 * 62^1) + (4 * 62^2) + (4 * 62^3) + (4 * 62^4) + (4 * 62^5) (3,724,605,612)
vs.
256^64 (1.3407807929942597099574024998206e+154)

Although x942 was probably talking about just the printable ascii character set, so it would be only:
95^64 (3.7524139211116134188015047676627e+126)

I don't think that was the point of x942's challenge. He is not comparing the two ciphers. berndroellgen keeps saying that TrueCrypt with AES256 is completely broken and that there are programs out there that can crack it instantly (he is completely wrong about this, by the way). I think the point of x942's challenge was to prove that berndroellgen doesn't know what he is talking about.

I gave it a shot with my TrueCrypt bruteforce tool that can try about 795 passwords per second running 16 threads on my dual Quad core machine against AES when the Hash function is unknown. I didn't even program it to count high enough to be able to figure out the actual number of passwords it needed to try. I used INT64 which can only count up to 9,223,372,036,854,775,808 and it still said it would take 368,627,544.7 years to brute force.

 

Yeah, ascii set is 95 with space. I wasn't thinking, I went with 26 for lower case letters.

I don't see why the pmc challenege is waht you say it is. He doesn't say characters can't be repeating (or does he?) It should just be a 3 character password with 62 possibilities (3^62) and then a fourth character with 4 possibilities (4^1) ? I don't know what I missed. The placement of the last character is the last space so you dont need to account for it moving around.

I don't see how PMC can solve attacks where RAM is frozen and/or the HDD is decrypted and then restarted with the key dumped yada yada without hardware encrypted RAM and a key stored on registers (which are flushed to 0 at restart.) I don't know anything about that though.

I think the biggest selling point with PMC is:
1) Large block size means you can't garner any semantics from the information because a single bit = all new information.

2) Slower to calculate.

1 is nice. 2 doesn't matter at all. AES128 is already not bruteforceable even with an 8 character all lower case password. 256 wouuld take ages.

The disadvantages of PMC are that no one's actually heard of it. Security through obscurity is maybe arguable for an antivirus, not even slightly arguable for crypto where you should know every detail about the implementation and it should be reviewed by people who know what they're talking about. AES is the standard, people know it, it works. Maybe it's too fast for generating keys in 1000 years, but it's slow enough for now no one's actually broken the crypto (not talking about side channel attacks that have no bearing.)

 

He said the "keyphrase is up to 6 characters long" which means it can be:
1 character (4) a + b + c + d
2 characters (4 * 62^1) [a-zA-Z0-9]a + [a-zA-Z0-9]b + [a-zA-Z0-9]c + [a-zA-Z0-9]d
3 characters (4 * 62^2) [a-zA-Z0-9][a-zA-Z0-9]a + [a-zA-Z0-9][a-zA-Z0-9]b + [a-zA-Z0-9][a-zA-Z0-9]c + [a-zA-Z0-9][a-zA-Z0-9]d
etc.

 

Unfortunately for the seller, semantic security is a 30-year-old fundamental aspect of any secure scheme.

 

Eveyone else already answered your question, but I would like to add I did post a challenge before that matched his challenge. I used AES with multiple rounds to slow down a bruteforce. He never accepted the challenge (6 char. password) and made excuses.

(YAY! 1000 posts XD)

 

The hash use was RIPEMD-160. I basically left it at defaults.

 

So now I can try about 1660 passwords per second with only RipeMD160, instead of 795 for all three. Ok, now I should be able to crack it...as soon as I figure out how to live just short of forever.

 

haha XD If you firgure that out I don't think you'll need to crack it

 

You obviously haven't understood it. "the actual encryption key" is static for AES once the cipher has been initialized. It's an easy target as a couple of bytes with lots of entropy stick out of pages in RAM of (at least) 4kB size!
PMC: the crypto context is much bigger and it changes rapidly. Very difficult to attack due to lots of pointers to functions and to data which in turn contains pointers. This makes it necessary to analyze the code as well while it is an RAM.

Again you've missed the decisive point: The attacks works only when your computer is on and when that disk encryption software is running.

PMC and AES are ciphers. Truecrypt/Bitlocker are disk encryption programs. You can only compare a Boeing 747 with some other aircraft and certainly not with a chicken.
A side-channel attack bypasses a security mechanism.
This specific side-channel attack can be applied on any software that utilizes any kind of encryption algorithm. This of course includes PMC.
BUT: Encryption algorithms can be hardened - just like smart cards can be hardened against Power Attacks. Example: If a smart card chip has an internal capacitor that enables the chip to run for a millisecond from the energy that is stored on that capacitor, no power samples can be recorded any more. The chip is hardened against that attack and even Twofish cannot be analyzed as simply as it can be on standard hardware.

Knowledge of crypto is nice, but to have a notion about organizations is also good: "just digging their hole deeper" in conjunction with this should let the alarm bell ring:

A geographical location is also given. Strange.

Anyways, this one here is nice:

Encrypting noise with a key of (almost) arbitrary length leaves any opponent NO chance to reveal the encrypted message.
Reason: Even if the key is only 1 ASCII character (!!!), there exist at maximum approx. 128 possibilites to decrypt the message. If you try all 128 key combinations, you end up with 128 plaintexts THAT ARE EQUALLY LIKELY TO BE THE ORIGINAL PLAINTEXT.
Wikipedia helps here once again:
http://en.wikipedia.org/wiki/Unicity_distance
"In cryptography, unicity distance is the length of an original ciphertext needed to break the cipher by reducing the number of possible spurious keys to zero in a brute force attack. That is, after trying every possible key, there should be just one decipherment that makes sense, i.e. expected amount of ciphertext needed to determine the key completely, assuming the underlying message has redundancy.

Consider an attack on the ciphertext string "WNAIW" encrypted using a Vigenère cipher with a five letter key. Conceivably, this string could be deciphered into any other string — RIVER and WATER are both possibilities for certain keys. This is a general rule of cryptanalysis: with no additional information it is impossible to decode this message."

For 128-bit ciphers, approx. 19 bytes are needed to recognize plaintext.

But x942 intuitively did the right thing with his lame duck cipher: He increased the number of rounds as he thought that 6 character long passwords won't protect data for long.

So he modified the code so that a 6 char password was safe while this is not the case with the standard version of his favourite cipher.
It's nice to know that short passwords can as well not be broken!

Why is there no interface in that cipher that allows programmers to select "standard" or "extremely insane" security?
Yeah, nobody needs that, bla, bla, ...
He felt that he needed that.

And if he feels this, then others do as well.
Here are the top 10 passwords in the UK of 2006: http://modernl.com/article/top-10-most-common-passwords
'123' (3.784‰)
'password' (3.780‰)
'liverpool' (1.82‰)
'letmein' (1.76‰)
'123456' (1.63‰)
...
They are all short and the top 5 allow access to over 10% of user accounts, encrypted volumes, etc.

 

Does anyone have an idea how long i will take for a (1) supercomputer
of > 10.51 Petaflop/s like this one:
http://top500.org/lists/2011/11/press-release
to brute-force a list of the million most used passwords with the most used cipher
(with no tricks users normally can't use, like adding extra rounds)?

Or just to brake (any) 6 chars password by brute forcing it?

For the record i don't know, and i am NOT suggesting anything here,
i am curious and i just want to learn

Btw i like this thread a lot, and you can see that other do as well.
Just look at the threads that are started as a spinoff of this.



btw : And in the near future with something working on this technology (news of April 12 / 2012) ?:
- http://tudelft.nl/en/current/latest...chappers-vinden-langgezocht-majorana-deeltje/ -
- http://www.animatorprogram.com/dutc...or_nano-wires_tu_delft_holland_12_april_2012/
-
- http://www.rnw.nl/english/bulletin/dutch-scientists-find-new-particle -

 

http://golubev.com/gpuest.htm

7970 against WinZip AES (128bit) is about 1million password generations per second (if I'm reading this right, and I may not be - seems way too high honestly by like 10-50x, so consider this a worst case scenario.) An 8 character password = 95^8 = 6,634,204,312,890,625 combinations.

6,634,204,312,890,625 / 1,000,000 = 6,634,204,312.89062

That's ~6.5 billion seconds.

6.5billion seconds in years = 206.1 years.

That's for a simple 8 character password.

7970 is 3788.8 GFLOPS.

So if we're assuming a linear correlation between FLOPS and passwords (which we should not) it would still take ~ a decade.

Also keep in mind that WinZip may not be the best comparison. They don't have anything closer. WPA uses AES but I've seen vastly different timings when trying to crack it.


EDIT: I think the chart I posted is incorrect and I read it wrong. In reality it can likely do 50-60,000 per second. If we say 100,000 you can just bump everything up by x10 years.

The test I personally saw on Truecrypt was a quad core i7 with some GPU doing a mere 17,000 passwords per second - nothing, really.

Even if the super computer can calculate 1billion per second


EDIT2:
http://www.lockdown.co.uk/?pg=combi

According to that chart it would take 72 days for a "Class F" attack on an 8 character password with 96 character set - hash unknown.

Basically, slowing it down doesn't matter. It would take a super computer months to crack an 8 character password. If you're using a secure password (12 characters) you're untouchable.

 

I'm not repeating my self for the third time.

WAIT!!! So this attack is only a irrelevant side-channel attack when it suites you? The rest of the time it's an attack against AES and why we should all use PMC?

That exact quote is what we have all been saying all along. YOU are the one who has said multiple times the software "cracks" AES. Now when challenged with something you can't prove you resort to changing you opinion and hoping no one notices.

I know. Yet again you are the one referring to them unanimously. You keep sugesting that attacks (like the one you posted) attack AES and Truecrypt yet they attack neither of the two and only their implementation.

How does any alarm ring? He PM'd me because a name was used on drop box. The name wasn't my real name only a pseudo-name I use for selling stuff online as I am required to show proof of owner ship and prefer not to disclose my real name. I changed it back to x942 so no one else would PM me about it (5 users did).

What geographical location? You mean my time zone? I can assure you I don't live in LA. I don't even live in the states.

Your right this is nice. The same lame excuse as last time. The plain text doesn't matter. If you can crack the password (6 chars) you would see the unique token in the keepass database. It doesn't matter if it's random or not. Bruteforce the password and it loads like a normal database in keepass. You obviously misunderstand or choose not to understand the challenge. The challenge was simple crack the 6 Char. password and post the long token that was in the database to prove you cracked it. This has nothing to do with cryptanalysis, this challenge was showing you can't crack a 6 char. password in which AES is used multiple rounds.

Speaking of lame duck ciphers, who's the one who has to post on multiple forums, spreading FUD just to make living? If your cipher is so great, pay for a FIPS-Certification.