IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: draft-miller-secsh-umac-00.txt
In article <Pine.BSO.4.64.0706151056490.5801%fuyu.mindrot.org@localhost> you write:
>On Thu, 14 Jun 2007, Damien Miller wrote:
>
>> On Wed, 13 Jun 2007, Wei Dai wrote:
>>
>> > Both UMAC and VMAC require unique nonces. Using the sequence number
>> > as the nonce as in your draft may cause nonces to be reused if
>> > someone takes a snapshot of an active SSH connection running an a
>> > virtual machine, and when that snapshot is restored, the SSH program
>> > sends out new packets before realizing that the connection is no
>> > longer valid.
>> >
>> > Unless there is a good reason to believe this can't occur, it would
>> > be safer to use random nonces instead.
>
>Markus Friedl suggested a good compromise: use the KEX PRF to extract
>192 bits of MAC key, give the first 128 to UMAC and use the remaining 64
>bits as a "nonce seed".
>
>The nonce that is supplied to UMAC can be nonce_seed + sequence_number.
>The seed would be private like the other keying material and, while the
>nonces would still be reused under this attack, the actual nonce values
>would be not be known to the attacker.
Does that help? RFC 4418 certainly doesn't suggest that it does -- it
says that repeated nonces break the security guarantee, with no
suggestion that the secrecy or otherwise of the nonce makes a
difference.
In any case, isn't 64 bits too short to be a useful secret?
--
Ben Harris
Home |
Main Index |
Thread Index |
Old Index