ietf-smime
[Top] [All Lists]

Re: RC2 Keylength Strawpoll

1998-09-01 13:06:10
EKR wrote:

As I've said before. I know they use X/8 on send. I'm not expecting
anyone to just take my word for it. I can demonstrate this to anyone who
doubts it.
There are two primary reasons to be concerned with current behavior:
1. Backwards compatibility
Provided that they are prepared to accept arbitrary keylength
on receive, this isn't an issue. They'll have to change their
code to accomodate S/MIMEv3 ANYWAY, so they can change
this behavior as well.
2. Implementation hassle for the programmers.
Often, changing one's behavior is a hassle. Sometimes it's not.
I expect that the Netscape and Microsoft representatives
can take this into account when voting.

It's not that I don't believe you about what Netscape and Microsoft
do. I just don't think it's that relevant.


Fair enough. Comments NS and MS please?

IMHO, anyone who assumes X/8 when receiving has broken the cardinal
rule of being liberal in what you accept. Sending is a different
issue.


Yes I suppose that could be argued. Of course a "hands up whose software
is broken" question may bring a limited response :-)

In some crypto libraries (SSLeay for example) you specify the unwrapping
cipher when you unwrap a key with RSA. In the case of RC2 with 40 bits
this specifies the effective bits and key size. The key size is then
used as an additional integrity check on the decrypted RSA block.
In the face of the Million Message attack, this no longer
seems like such a great idea.


I've just checked the bulletin re this attack. Under "Countermeasures"
doing a stronger integrity check was one way of considerably reducing
the probabilty of a random ciphertext being "good". It says checking the
length actually makes the attack harder: it quotes from 1 million to 20
million questions.

Anyway the main cause of that problem was being able to determine the
integrity check had failed based on the type of error. 

All irrelevant to S/MIME though, as it points out.


In any case CMS needs an additional note if fixed keylength is adopted.
Something like it MUST be fixed if key agreement is used for any
recipient used and SHOULD|MUST|MAY (Comments?) if no recpients use key
agreement.
Nonsense. Provided that all recipients will accept a fixed
length key, MUST is perfectly acceptable in all cases.

I have no problems with MUST. But with purely key exchange it is not
mandatory. I agree though that MUST would be better for both.


IMHO prohibiting a keysize larger than 128 bits is not a good idea. Even
if hardly anyone will ever use anything larger than 128 bits we should
at least define a standard to handle this so people don't all do
different and incompatible things.
On the contrary. I think it's a fantastic idea. People who want
a cipher that is 128 bits strong should choose something better
analyzed than RC2.


I have a very vague recollection of some advertising material suggesting
something using 255 bit RC2 for S/MIME, though I might be thinking of
something else.

Comments anyone?

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk
PGP key: via homepage.


<Prev in Thread] Current Thread [Next in Thread>