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.
If you permit a larger key length then it may break an existing
implementation that assumes that the the keylength is X/8. It would
break mine for example but I can fix that.
I can't comment on whether the above implementations assume X/8, can
anyone else? If no one knows then I can do some tests and post the
results back here.
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.
Using the keysize as an integrity check is IMHO not unreasonable but
this would make things difficult if the keysize is not known in advance.
As to how many implementations or crypto libraries this affects I've no
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?
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.
If option 2 is taken then what should the fixed keylength be? If we set
it as (for example) 128 bits then that restricts anyone who wishes to
use more. So you couldn't just say "fixed keylength" you'd have to say
for example: "the keylength is rounded up to the nearest multiple of 16
to X/8". One conclusion to this is, of course, you might as well have a
variable key length to begin with.
This is a non-problem. The permissible RC2 keylengths in S/MIME are
40,64, and 128. Consequently, fixed 128 will work just fine.
I may have missed something here but is this explicitly stated anywhere?
I know that 40, 64 and 128 are given as examples but the RC2 spec
permits larger keysizes as does the S/MIME capabilities attribute.
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.
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.
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.