RE: Xenc Requirements req - comments on security and other issues

I've been mostly lurking in the shadows, but thought I'd ask about this
one... I haven't seen anyone else commenting on this specific point...

Amir Herzberg wrote (in response to Joseph Reagle's comments on the
subject):
>The problem is beyond that of a transform, since it is the result of
>the encryption itself - if proper precautions are not taken. Specifically,
>a dishonest signer can send a signed message sign(E_k(m)) but when there's
>a dispute, and the recipient is showing <k,E_k(m),sign(E_k(m))>, the sender
>produces another pair <k',E_k'(m'),sign()> where E_k'(m')=E_k(m). Or a
>dishonest recipient may find such <k',m'>. So I believe XML Encrypt should
>address this concern.

I agree with Amir that signing encrypted documents isn't ideal.  If I'm
understanding correctly, this is an example of a traditional birthday
attack.  As a non-cryptographer, how feasible are birthday attacks using
modern cryptographic schemes (e.g., 3DES with SHA-1 or AES with SHA-1)?  My
impression is that they're computationally infeasible, even if theoretically
possible.

>In the requirements document we just need to warn about this issue and
>maybe mention some known techniques to address it. One technique is to
>sign the plaintext (instead or in addition to signing the ciphertext), with
>proper randomization to prevent guessing attack of course. Another
technique
>is to use encryption mechanisms where it is infeasible to find <k1,m1> and
><k2,m2> s.t. E_k1(m1)=E_k2(m2).

I have no problem with noting this as a security consideration (as I believe
Joseph Reagle suggested).  However, I think that we should not overemphasize
the threat.  Unless I'm misunderstanding the problem, it would have to be a
*very* determined adversary who would have the computational power to do a
birthday attack (whether it's a dishonest signer, a dishonest recipient, or
an attacker in the middle who's trying to foul the relationship between the
two).

IMHO, the threat posed by a birthday attack is far less than the threat of
incorrect implementations, or of poor choice of keys due to bad random
number generators, or the myriad of other things that go wrong.  I believe
that security considerations will be most useful if we give an indication of
how important each one is.  And I don't think this one is all that big a
deal.

Cryptographers, please prove me right or wrong!

Regards,
--Jeremy

Received on Monday, 16 April 2001 11:41:26 UTC