[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 3DES with 40-bit key?



niklas@appli.se wrote:
> As for the initial question, Ari did not state from which country he
> wanted to export from.  Some have understood it to be the US, others
> have guessed a Wassenar country.  I did read up a bit on Wassenaar and
> found it not to be as bad as I initially been afraid of.

I'm sorry for accidentally omitting this piece of information.
What I meant was indeed exporting from US. Because of internal
reasons we're actually having coding and exporting from Finland
as well as re-exporting from US. The US version gets tagged with
strict export control rules.

> Back to the subject, if I understand Ari's question right, it was: how
> do I provide no-stronger-than-N bits of protection if the only known
> transform to talk to other IKE's with are 3DES.  My answer is along
> the line of another guy in the thread; by publishing 192-N bits of the
> key in a vendor defined NOTIFY STATUS message always sent out after
> every exchange, and going to your government and show them that you
> disclose the extra bits.

Never! I'd rate that criminal behaviour...

> Now, I don't particularily like this, given that the party you talk to
> might trust the actual keylengths, and send data it would not send at
> a lower security level.  Maybe your government allows you to just log
> these extra bits in a write-only black-box memory of some sort,
> together with the SPIs.  That'll at least protect your communication
> for the non-governmental bad guys.  And the government can get at the
> extra bits when they need, with a warrant.

Actually I was thinking more of only allowing single-DES in the
re-exported version and variable keylength algorithms with the
length limited to 56 bits. This might not be very interoperable,
particularly if our our implementation is the responding side,
but at least it's exactly what it claims to be.

I would very much prefer an interoperable way to limit the keysize,
something that is controllable with the security policy. The default
policy might be to not allow watered down cryptography, and the customer
would have to specifically allow it.

Ari Huttunen
begin:vcard 
n:Huttunen;Ari
tel;fax:+358-9-2992634
tel;work:+358-9-2992472
x-mozilla-html:FALSE
org:L M Ericsson;LMF/T/TK
version:2.1
email;internet:Ari.Huttunen@lmf.ericsson.se
title:Software Designer
adr;quoted-printable:;;Oy L M Ericsson Ab=0D=0ATelecom R&D;;;02420 Jorvas;Finland
x-mozilla-cpt:;-30024
fn:Ari Huttunen
end:vcard

Follow-Ups: References: