[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] Is calculating an MD5 hash of a Rjindael encrypted block and it's key insecure?

Richard Atterer wrote:

On Thu, Aug 12, 2004 at 01:56:53PM +0200, Marcel Weber wrote:

No, it doesn't mean that. Current browsers will cache the password, AFAIK
until the end of the session by default, and forever if you enable the
option "Remember this password" or similar.

I know.

- No more credentials that are sent in plain over the internal network (which is the case if you use basic authentication), except for the initial login.

Hmm, but the initial time is enough... :-/ You will need to use SSL for that.

It's already used ;-)

The block size of the data to be encrypted has to come in chunks of 16
bytes. I always append random numbers to the credentials, ip and time
strings to the next 16 bytes before encryption. Like this, the attacker
cannot know or guess all of the content of the encrypted data, can he?

This makes things more difficult for the attacker, yes. Presumably your
code adds no random padding if the data already has the right length, but

Well it adds random values even if the block size would fit.

The trouble is, as far I figured out, that Crypt::Rjindael does not
return, when you try to decrypt an encrypted string that's, a. damaged or
b. encrypted with a different key. Don't know why.

This cannot be. Rijndael gets bits as input, and it outputs bits. The only
thing that will happen is that you'll get random-looking garbage if the
input is incorrect in some way. (I don't know what Crypt::Rjindael does.)

Well I figured this out. It was a non ending loop in my code, as I looked for a special character in the decrypted key. Very dumb of me...

Why $s? Surely you'll only store $c in the cookie, otherwise there's no
point in encrypting the data.

Ahem, well $s is encrypted and $c is only a md5 checksum for $s and $k.

Sorry, I misinterpreted your message and thought that $s was not encrypted.



Thanks again


Reply to: