On 9/11/13 6:00 AM, Alexandre Anzala-Yamajako wrote:
Chacha20 being  a stream cipher, the only requirement we have on the ICV is 
that it doesn't repeat isn't ?

You mean IV, the Initialization Vector.  ICV is the Integrity Check Value,
usually 32-64 bits appended to the packet.  Each is separately keyed.

This means that if there's a problem with setting 'mostly zeroed out' ICV for 
Chacha20 we shouldn't use it at all period.

I strongly disagree.  In my network protocol security designs, I always
try to think about weaknesses in the implementation and potential future
attacks on the algorithm -- and try to strengthen the security margin.

For example, IP-MAC fills every available zero space with randomness,
while H-MAC (defined more than a year later) uses constants instead.
IP-MAC was proven stronger than H-MAC.

Sadly, in the usual standards committee-itis, "newer" is often assumed to
be "improved" and "better".  So H-MAC was adopted instead.  Of course, we
know that H-MAC was chosen by an NSA mole in the IETF, so I don't trust it.

Also, there's a certain silliness in formal cryptology that assumes we
shouldn't have longer randomness keying than the formal "strength" of the
algorithm.  That might have been true in the days of silk and cyanide,
where keying was a hard problem, but modern computing can generate lots of
longer nonces without much effort.

In reality, adding longer nonces may not improve the "strength" of the
algorithm itself, but it improves the margin against attack.  A nearly
practical attack of order 2**80 could be converted to an impractical
attack of order 2**96....

As far as your proposition is concerned, the performance penalty seems to 
largely depend on the target platform. Wouldn't using the same set of 
operations as Chacha prevent an unexpected performance drop in case of lots of 
short messages ?

I don't understand this part of your message.  My ancient CBCS
formulation that I'll probably use for PPP (Xor'ing a per-session key
with a per-packet unique value) is demonstrably much faster than using
ChaCha itself to do that same thing.

We've been using stream ciphers and pseudo-stream ciphers (made by
chaining MACs or chaining block ciphers) to create per-packet nonces
for as long as I can remember (over 20 years).  You'll see that in CHAP
and Photuris and CBCS.

So I'm not arguing with Adam's use of ChaCha for it.  It just bugs me
that we aren't filling in as much randomness as we could!

The cryptography mailing list

Reply via email to