[4418] in cryptography@c2.net mail archive
Re: 1024 bit RSA exportable?
daemon@ATHENA.MIT.EDU (Kawika Daguio)
Thu Apr 1 13:02:34 1999
Date: Thu, 01 Apr 1999 12:36:43 -0500
From: "Kawika Daguio" <KDAGUIO@aba.com>
To: <cryptography@c2.net>, <pgut001@cs.auckland.ac.nz>, <David_Conrad@isc.org>
Peter,
The standard that you are joking about is in fact one of the reference =
tests used by the regulatory community here. If, for example, it would =
take as much time to write the code as alter it, and as much experience to =
write it as alter it, you should not have a problem with the "easily =
converted" standard. =20
With respect to the time it took to export the MISPC stuff you should take =
into account the sensitivity of export controls policy for the affected =
agencies. The folks at NIST are extremely cautious and dot every "I" and =
cross every "T" and check them repeatedly when it comes to export control =
issues. The folks that make up the export controls team are not unreasonab=
le and in my experience are very interested and educable. We have never =
failed to achieve our objectives any of times we advanced a rationale for =
a reasonable change in policy or an individual export application.
The situation here is not as bad as it sounds, and it is getting better =
all the time. Each time an area of policy is resolved or an application =
is made and moves forward, the policy and process gets easier for everyone =
that follows. I expect the DNSSEC and similar packages to be moved rather =
quickly in the future with minimal need for expensive counsel and time =
delays. In fact, I am personally very active in an education and =
negotiation process - making sure that export controls do not get in the =
way and getting government buy-in and support for efforts like these which =
would help to secure the infrastructure. The senior policy makers =
involved in these decisions today are well informed and working very hard =
to resolve very difficult policy problems that cannot be fairly described =
in sound bite or bumper sticker slogan exchanges. Policy makers and the =
affected communities will have to continue to work together to resolve =
these issues over time. In this area of operations and policy, patience =
is not merely a virtue, it is required in large measure.
Respectfully,
...kawika daguio...
The above represent my views which may or may not coincide with the views =
of my employer or our membership
>>> Peter Gutmann <pgut001@cs.auckland.ac.nz> 04/01/99 06:42PM >>>
"David R. Conrad" <David_Conrad@isc.org> writes:
=20
>It appears that the definition of whether authentication code is =
exportable or
>not now depends on whether BXA (NSA) feels the code can be "easily" =
converted
>to encryption uses.
=20
Just as a data point, this morning I got a copy of NIST's reference PKI=20
implementation (MISPC) which contains (signature-only) crypto code. The =
PKI=20
stuff is in source form, the signature component is supplied as a Windows =
DLL.=20
I don't know what key sizes it'll handle (I have to get to a Windows =
machine=20
first), but going by the MISPC guidelines it should do 1K keys. The =
paperwork=20
included indicates that it went through the full export approval =
process,=20
taking more than six months from filing to approval (the shippers =
export=20
declaration is a copy of a fax dated 3 September 1998, the shipping date =
is 12=20
March 1999, looks like the BXA could give NZ's Ministry of Foreign Affairs =
and=20
Trade a run for their money :-). Actually I'm not sure whether it really =
took=20
that long, maybe that was just the date the original form was faxed... in =
any=20
case it looks like NIST is being forced to jump all the export hurdles, =
even=20
for something which would be almost impossible to convert for encryption =
use=20
(you could probably write an implementation from scratch faster than you =
could=20
patch extra code into the binary to make it do encryption).
=20
Peter.
=20
=20
