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

Re: Utterly Confused by Resync



Hal Finney wrote:
> Ben Laurie writes:
>> I just implemented the Symmetrically Encrypted Data packet.
>>
>> It also does a "resync" after the first blocksize+2 bytes. However, I
>> find that, unlike the MPI resync for v3 keys, as well as wiggling around
>> the IV I have to encrypt it.
>>
>> That is, the resync operation for MPI looks like this:
>>
>> 1. Set the IV to the last blocksize bytes of ciphertext
>> 2. Set the offset within the IV to zero.
>>
>> Whereas for the Symmetrically Encrypted Data resync looks like:
>>
>> 1. Set the IV to the last blocksize bytes of ciphertext
>> 2. Encrypt the IV
>> 3. Set the offset within the IV to zero.
>>
>> Can this possibly be right? Does the spec explain this at all?
> 
> The resync operation is the same for encrypted data packets as for
> V3 keys.  There is a difference between the two cases, but it doesn't
> involve the resync.  The difference is that V3 keys use a regular IV,
> while encrypted data packets use an IV of 0 and then discard the first
> blocksize+2 bytes.  But that does not affect the resync; the resync is
> done exactly in the same way.
> 
> CFB works like this.  Encrypting plaintext block N starts with the
> ciphertext of block N-1. Encrypt that ciphertext and then XOR the result
> with plaintext block N to get ciphertext block N.  For the 1st block,
> where there is no previous ciphertext block, the IV is used.  Encrypt the
> IV and XOR with the 1st plaintext block to get the 1st ciphertext block.
> 
> The resync operation can be though of as setting the IV to the previous
> blocksize bytes of ciphertext, and starting this process from the
> beginning.  Encrypt the IV, XOR with the 1st bytes of the plaintext,
> and you get your ciphertext.
> 
> This will work for both encrypted data packets and for V3 private keys.
> Your description fo the data packet case says as step 2, encrypt the IV.
> I don't know how to interpret that.  Of course you encrypt the IV, it
> is part of the CFB process as I just described.  Is that all you mean?
> Or do you think you encrypt the IV twice?  Is that what you are implying?
> That would not work.
> 
> The details of encryption for data packets are described in RFC2440bis
> in section 12.8.  It's a cumbersome and wordy description but if you read
> it carefully it will hopefully shed light on what you need to do.

I'm hesitant to say definitively I'm right, after the previous debacle,
but... my resync function does _not_ perform an encryption, all it does
is wriggle around the previous and current IVs, and it works fine with
V3 keys.

After I have called resync for the symmetric encrypted data packet, I
have to encrypt the new IV, or it doesn't work. If I add the encrypt
step to the resync, it breaks V3 keys.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff