Board index » delphi » RC4 encrypted data and headers for password validation

RC4 encrypted data and headers for password validation

(This stuff is Delphi, but the principles might be of use to BP/TP
users, as it's just a simple I/O issue)

I'm writing an encryption program, which can encrypt data in RC4, RC5,
DES, IDEA, Blowfish and hash in MD5 and SHA.

I'm currently testing it in RC4 mode, and have run across a problem.
Basically, I can read, write and decrypt 'pure' RC4 files (ie ciphertext
and nothing else) which is no problem, as long as the key supplied is
correct, but if the decryption key supplied is incorrect, the program
will blindly attempt to decrypt the ciphertext, producing gibberish.

It needs to say 'invalid password' without compromising it.

My idea for doing this is to, just before RC4 encryption, prefix the
data with 'TrayCrypto RC4' - the name of the program and the crypto
algorithm. On decryption, the resulting plaintext is tested for this,
and if it's not there, then the password is deemed incorrect. If it's
found there, then the header is stripped to leave the original
plaintext.

This means the files produced still remain RC4, but with a predictable
set of bytes inside, which can be checked on decryption. If the bytes
match the expected ones, then the password is OK and the text is
decrypted.

Any ideas on how to do this?
Not the RC4, just the header stuff. Like this pseudocode:

Confirm_Password();
Write_Header();
RC4_Encrypt();         // which would produce the output, and then

RC4_Decrypt();
if NOT HeaderValid() then complain();
strip_Header();

The stripping must be OK for binaries as well as ASCII text - if I use
this method on an EXE, it must still function afterwards.

--

 

Re:RC4 encrypted data and headers for password validation


Quote
In article <zc$uTBAt4250E...@netbook.demon.co.uk> James MacDonald <tr...@netbook.demon.co.uk> writes:
>I'm writing an encryption program, which can encrypt data in RC4, RC5,
>DES, IDEA, Blowfish and hash in MD5 and SHA.
>I'm currently testing it in RC4 mode, and have run across a problem.
>Basically, I can read, write and decrypt 'pure' RC4 files (ie ciphertext
>and nothing else) which is no problem, as long as the key supplied is
>correct, but if the decryption key supplied is incorrect, the program
>will blindly attempt to decrypt the ciphertext, producing gibberish.
>It needs to say 'invalid password' without compromising it.

There are various "one way hash" functions, as you know, and one thing that
comes to mind would be to prefix the data with the correct one-way hash of the
password.  When given a password you should compute the hash-value of what the
user entered.  Then decrypt the first block of text.  The same hash value
should occur at the start of the plaintext.

Enclosing such information as a CRC-32 of the plaintext data, the
version-number and identity of the encryption program, and so forth would also
enable you to verify correct decryption.

Re:RC4 encrypted data and headers for password validation


Quote
In article <zc$uTBAt4250E...@netbook.demon.co.uk> James MacDonald <tr...@netbook.demon.co.uk> writes:
>I'm writing an encryption program, which can encrypt data in RC4, RC5,
>DES, IDEA, Blowfish and hash in MD5 and SHA.
>I'm currently testing it in RC4 mode, and have run across a problem.
>Basically, I can read, write and decrypt 'pure' RC4 files (ie ciphertext
>and nothing else) which is no problem, as long as the key supplied is
>correct, but if the decryption key supplied is incorrect, the program
>will blindly attempt to decrypt the ciphertext, producing gibberish.
>It needs to say 'invalid password' without compromising it.

There are various "one way hash" functions, as you know, and one thing that
comes to mind would be to prefix the data with the correct one-way hash of the
password.  When given a password you should compute the hash-value of what the
user entered.  Then decrypt the first block of text.  The same hash value
should occur at the start of the plaintext.

Enclosing such information as a CRC-32 of the plaintext data, the
version-number and identity of the encryption program, and so forth would also
enable you to verify correct decryption.

Other Threads