How Do Decryption Programs Know You've Entered the Wrong Passphrase?
in [Cryptography]
|
From: Datesfat Chicks on 25 May 2010 12:49 My notion of passphrase-based decryption is that you take the entered passphrase, use some sort of cryptographic hash function to get an AES-256 key, then decrypt with AES-256. (AES-256 is just for the purposes of example--it could be any block cipher.) But what is the standard approach to detect that the wrong passphrase is entered? The most obvious approach seems to be to include (for example), a bunch of 0 bytes at the start of the portion to be decrypted, then call it the wrong passphrase if the decryption does not result in these 0's. But I suspect there is a better way ... I've noticed that Word and WinZip (both of which use AES-256, I believe), complain if I use the wrong passphrase. But how do they know it is the wrong passphrase? Thanks, Datesfat
From: Gordon Burditt on 25 May 2010 13:14 >passphrase, use some sort of cryptographic hash function to get an AES-256 >key, then decrypt with AES-256. (AES-256 is just for the purposes of >example--it could be any block cipher.) > >But what is the standard approach to detect that the wrong passphrase is >entered? There are several approaches, but most of them just involve permitting a known-plaintext attack against the encryption. 1. Put a known value somewhere, say, at the beginning. If that value doesn't appear on decryption, you have the wrong key. 2. Include a checksum or hash of the contents, and if the hash doesn't match on decryption, assume it's the wrong key. 3. If the plaintext is known to be, say, 7-bit ASCII text, then any part of the decryption that has the 8th bit set indicates the wrong key. #2 seems to give you the best chance at also detecting damage to the ciphertext as well as an incorrect key. Note that none of these methods absolutely guarantee to detect a wrong key, but they will detect a wrong key with very high probability.
From: Datesfat Chicks on 25 May 2010 13:47 "Gordon Burditt" <gordon(a)hammy.burditt.org> wrote in message news:FL6dnciX47jFmGHWnZ2dnUVZ_tudnZ2d(a)posted.internetamerica... > >passphrase, use some sort of cryptographic hash function to get an > >AES-256 >>key, then decrypt with AES-256. (AES-256 is just for the purposes of >>example--it could be any block cipher.) >> >>But what is the standard approach to detect that the wrong passphrase is >>entered? > > There are several approaches, but most of them just involve > permitting a known-plaintext attack against the encryption. > > 1. Put a known value somewhere, say, at the beginning. If that value > doesn't > appear on decryption, you have the wrong key. > 2. Include a checksum or hash of the contents, and if the hash doesn't > match on decryption, assume it's the wrong key. > 3. If the plaintext is known to be, say, 7-bit ASCII text, then any part > of the decryption that has the 8th bit set indicates the wrong key. > > #2 seems to give you the best chance at also detecting damage to > the ciphertext as well as an incorrect key. Note that none of these > methods absolutely guarantee to detect a wrong key, but they will > detect a wrong key with very high probability. #2 makes the most sense to me, but I don't think it is done that way. Using PGP, for example, if I make a self-decrypting archive a couple gigabytes big, I suspect it would tell me immediately that the passphrase is wrong. In order to use approach #2, you'd need to decrypt the item and compare the hash--this could take several minutes with a large file (i.e. not immediate). #1 would seem to give immediate results (consistent with the way I suspect PGP behaves). Another approach would seem to be to have two different hashing procedures: one to create the block cipher key and the second one to check if the passphrase is correct. (They could be the same algorithm, but maybe one has a nonce or different salt.) Anyway, the decryption procedure would be: a)Hash the passphrase using Procedure 1 and see if the hash mashes what is stored. If not, error out. b)Hash the passphrase using Procedure 2 to get a decryption key and decrypt using the block cipher. Thanks for the ideas and info. Datesfat
From: Maaartin on 25 May 2010 15:51 On May 25, 7:47 pm, "Datesfat Chicks" <datesfat.chi...(a)gmail.com> wrote: > Another approach would seem to be to have two different hashing procedures: > one to create the block cipher key and the second one to check if the > passphrase is correct. (They could be the same algorithm, but maybe one has > a nonce or different salt.) Anyway, the decryption procedure would be: > > a)Hash the passphrase using Procedure 1 and see if the hash mashes what is > stored. If not, error out. > > b)Hash the passphrase using Procedure 2 to get a decryption key and decrypt > using the block cipher. I don't see what advantage it should give you. You still need to store something and you need to do twice as much work (given the correct password), but the adversary needs to do only the first step. Here is the description how Truecrypt verifies the key (no idea how PGP does it): http://www.truecrypt.org/docs/?s=encryption-scheme "Decryption is considered successful if the first 4 bytes of the decrypted data contain the ASCII string "TRUE", and if the CRC-32 checksum of the last 256 bytes of the decrypted data (volume header) matches the value located at byte #8 of the decrypted data..."
From: Datesfat Chicks on 25 May 2010 16:24
"Maaartin" <grajcar1(a)seznam.cz> wrote in message news:d482afc8-9ece-4781-85ba-685ebf4d2bbb(a)c22g2000vbb.googlegroups.com... On May 25, 7:47 pm, "Datesfat Chicks" <datesfat.chi...(a)gmail.com> wrote: > Another approach would seem to be to have two different hashing > procedures: > one to create the block cipher key and the second one to check if the > passphrase is correct. (They could be the same algorithm, but maybe one > has > a nonce or different salt.) Anyway, the decryption procedure would be: > > a)Hash the passphrase using Procedure 1 and see if the hash mashes what is > stored. If not, error out. > > b)Hash the passphrase using Procedure 2 to get a decryption key and > decrypt > using the block cipher. > >I don't see what advantage it should give you. You still need to store >something and you need to do twice as much work (given the correct >password), but the adversary needs to do only the first step. > >Here is the description how Truecrypt verifies the key (no idea how >PGP does it): >http://www.truecrypt.org/docs/?s=encryption-scheme >"Decryption is considered successful if the first 4 bytes of the >decrypted data contain the ASCII string "TRUE", and if the CRC-32 >checksum of the last 256 bytes of the decrypted data (volume header) >matches the value located at byte #8 of the decrypted data..." This is essentially a variation on what I suggested with "0" bytes at the start. The reason I was concerned about this is that it makes attacks cheaper. Better to force an attacker to do a lot of work to figure out if they are successful. For a legitimate user, they only need to tolerate the cost once, when they try to mount the volume. But an attacker would have to tolerate it many times. Seems to make a brute force attack easier. Datesfat |