Dr Stephen Henson <shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk>
writes:
EKR wrote:
Dr Stephen Henson
<shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk> writes:
I propose this option not because its the best but because its what the
two versions I've tested use: viz Netscape Messenger and Microsoft
Outlook.
Representatives from both companies are here. It seems to me best
to see what their opinions are.
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.
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.
Oh BTW I did some tests on Netscape and Outlook 98 anyway. As I said
they both use X/8 on send but neither assumes X/8 on receive. So that's
two implementations a fixed keysize wont break anyway...
As for this being more complicated to code and test I'd say that depends
on the implementation. Currently, for example, SSLeay would need some
modification to support option 2 with its envelope routines whereas
option 1 is already supported.
That's not a reasonable standard. Clearly, any change is more
difficult to develop and test than no change. That's why we
take current practice into account. The issue with development
and test assumes you're starting from scratch. From THAT
perspective fixed is easier.
Well current practice seems to be X/8 on send with the implementations
I've tested. Anyone know of anything that doesn't use X/8 on send?
At Chicago, Blake asserted that a number of implementationd o other
things. Perhaps he'd be willing to speak up.
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.
If this isn't stated then we either need a standard for key lengths
larger than 128 or an absolute prohibition of a key length greater than
128 bits for RC2.
This would be fine with me.
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.
-Ekr
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."