Re: IGE mode is broken (Re: IGE mode in OpenSSL)

2006-09-25 Thread James A. Donald

On 9/9/06, Adam Back [EMAIL PROTECTED] wrote:

 IGE if this description summarized by Travis is correct, appears to be
 a re-invention of Anton Stiglic and my proposed FREE-MAC mode.
 However the FREE-MAC mode (below described as IGE) was broken back in
 Mar 2000 or maybe earlier by Gligor, Donescu and Iorga.  I recommend
 you do not use it.  There are simple attacks which allow you to
 manipulate ciphertext blocks with XOR of a few blocks and get error
 recovery a few blocks later; and of course with free-mac error
 recovery means the MAC is broken, because the last block is

Travis H. wrote:

I don't see why integrity+confidentiality has to cost n log n
operations.  I haven't read the whole paper yet (and the proof is at
the end)

The idea is to costlessly piggy back integrity on top of confidentiality 
is to have error propagation, so that any fiddling with the message will 
cause all packets after the fiddling to be random noise.

Unfortunately, if this is done with linear operations, it can be undone 
with linear operations.  If it is done with non linear operations (my 
recommendation), it is hard to prove anything.

 Or are universal hashes

considered cryptographic-weight primitives, and thus this constitutes
a second pass over the plaintext? 


The idea is to get integrity for free, but unfortunately so many 
integrity-for-free schemes have come undone, making people suspicious.

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: Exponent 3 damage spreads...

2006-09-25 Thread Philipp Gühring

We have been researching, which vendors were generating Exponent 3 keys, and 
we found the following until now:

* Cisco 3000 VPN Concentrator
* CSP11
* AN.ON / JAP (they told me they would change it on the next day)
(perhaps more to come)

My current estimate is that 0.26% of the certificates in the wild have 
Exponents =17

Best regards,
Philipp Gühring

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: A note on vendor reaction speed to the e=3 problem

2006-09-25 Thread Travis H.

On 9/15/06, Taral [EMAIL PROTECTED] wrote:

*That* is the Right Way To Do It. If there are variable parts (like
hash OID, perhaps), parse them out, then regenerate the signature data
and compare it byte-for-byte with the decrypted signature.

You know, this sort of reminds me of a problem with signatures on tar.gz files.
Basically, you have to keep them around so you can check the signature,
but you can't delete them because you can't reconstruct the original tar file
from an untarred copy because it's full of metadata that won't necessarily
be replicated on your system.  For example, uids and gids.  Unfortunately,
cpio appears to be worse.  From a tape backup standpoint, tar doesn't
store enough (extended attributes, hard links, etc.) and so it appears to
store both too much and too little at once.

It would be nice if there was a format other than shar which was deterministic
and only contained the contents of the files; no metadata.  Then we could sign
the code and nothing else.  From a security point of view, shar has obvious
problems :-)  Anyone know of a relevant tool?
Enhance your calm, brother; it's just ones and zeroes.
Unix guru for rent or hire --
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: Exponent 3 damage spreads...

2006-09-25 Thread Simon Josefsson
Leichter, Jerry [EMAIL PROTECTED] writes:

 I agree that there are two issues, and they need to be treated
 properly.  The first - including data after the ASN.1 blob in the
 signature computation but then ignoring it in determining the
 semantics - is, I'll argue, an implementation error.  You list only
 OpenSSL as definitely vulnerable, NSS as ?, so it sounds like
 only one definitive example.

Yes.  I'm only familiar with NSS as a user, not as a developer.  For
some reason, the Mozilla bug tracker hides information about this
problem from us, so it is difficult to track the code down.

I believe I identified the patch that solved the problem in NSS,
search for 350640 in:

The bug discussion is not public:

Possibly also bug reports 351079 and 351848 are related to the same
problem, but these bugs are also hidden.

The actual patch for 350640 is:

If some NSS developer could chime in, that would help.

 Even if NSS has the same problem, one has to look at code


 OSS efforts regularly share code, and code to pick apart data fields
 is hardly kind of thing that is going to inspire someone to go out
 and do it better - just share.

I think you want to read up on free software license compatibilities,
and in particular OpenSSL vs GPL.  But this is a very different topic,
that we shouldn't pursue here...

 The second - embedded parameter fields - is a much deeper issue.
 That's a protocol and cryptographic error.  The implementations
 appear to be correctly implementing the semantics implied by the
 spec - ignore parameters you don't care about.

At least some versions of PKCS#1 does NOT say that, e.g., RFC 3447.

RFC 3447 essentially says to generate a new token and use memcmp().
Such implementations would not be vulnerable to any of the current
attacks, except the Kaliski ASN.1 OID attack (an attack that doesn't
work on existing implementations).

 This is common practice, and a fine idea in *most* situations, since
 it allows for extensions without breaking existing implementations.

I believe the principle of Be conservative in what you do; be liberal
in which you accept from others is generally a bad advice.

The principle hides problems that should be fixed.  Hiding a problem
instead of fixing it typically enables bad things to happen.  We've
seen that lead to security problems for many years, this is just one


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]