[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 31 Dec 2011 15:40:53 -0500
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
Cc: magnum <john.magnum@...hmail.com>
Subject: Re: SSE/intrinsics for sapB/sapG [was: john-users]
> On 12/31/2011 02:47 PM, magnum wrote:
> That presumtion was wrong. I'm starting to get this straight now. We can
> actually do the described procedure for 56-63 bytes and for any of those
> lengths, the 0x80 fits in the first buffer and the second buffer is all
> nulls except for the length byte.
>
> For exactly 64 bytes, the 0x80 obviously comes first thing in the second
> buffer.
>
> > I suppose the figures are sligthly different for MD4 and MD5, where the
> > length byte is placed at 14*4 instead of 15*4?
Nope. The formats in this situation are the same. They all have an 8 byte integer, that MUST be in the last block (64 bytes). For MD4/5 it is in LE format. For SHA1, it is in BE format. What the 4 bytes of 0's are, is simply part of this 8 byte number. Until you more than encrypt 2^24 characters, it will always be 0.
>
> Perhaps not. It will be exactly the same, right?
>
> I think all coins fell down now :) but we should document this on the
> wiki. Now, at least it's in the list archives!
The easiest way to 'view' this, is to build a 'flat' buffer. This buffer MUST
1. end on an even 64 byte boundary.
2. The last 8 bytes MUST be the length of the 'real' data in bits.
3. The bit right after the real data must be set.
4. all bits between this 'extra' bit, and the start of the last 8 bytes, must be set to 0.
5. There must not be any extra total blank 64 byte buffers, i.e. the whole buffer length must be minimal to satisfy all other conditions.
This is the same for SHA1/MD4/MD5 (probably others also).
So, if you have < 56 bytes of data to encrypt, it will fit into 1 packet, and satisfy the above situation. Actually, a 'believe' you can put 55 bytes, and 7 bits into a single buffer, but this part, I am not fully clear about. I have never tried to encrypt anything other than byte data. I have not tried to encrypt arbitrary number of bits, so I do not fully understand just how to do that. The reason we 'use' a 0x80 byte, is because that high bit is adjacent to the prior bits that make up the message.
But I am glad to hear you have gotten the internals figured out.
jim.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
