You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@znep.com> on 1998/09/18 06:06:42 UTC
US gov't crypto export
anyone care to comment on the US gov'ts easing of export restrictions?
As pathetic as it may be, from what I understand they have eliminated the
need for licenses to export 56-bit crypto, wihch means that there should
be no doubt at all about crypt() being exportable. (yes, I know, in
theory you can do crypt() safely and argue it is not two-way but AFAIK
it isn't entirely clear if that can be supported)
Is this true? If so, are we willing to add code required to do crypt()
so Win32 can have consistent htaccess passwd encryption.
Hmm. Ok. Looks like it may not be true, the media is just lying again.
Can't find actual hard documentation on what they plan.
Oh, lovely. cmp says, that instead of "key recovery":
But the White House plan also boosts a different kind of back-door
recovery method, in which a network administrator would have access to
the plain text of a corporation's internal documents, and could provide
this information to law enforcement. Software with this feature will be
given the green light under the new export rules.
Erm... yea, whatever.
Ok, from the press briefing:
With respect to our existing policy, we have for two
years ending this December, permitted the export of 56-bit products
after an initial one-time review without further review by the
government. What we're announcing today is the maintenance of that
window permanently. And so 56-bit products will be freed from export
controls after a one-time review, in perpetuity, not ending at the
end of this year. We are, however, removing the requirement for key
recovery plans or key recovery commitments to be provided in return
for that change, which was the initial condition that we extracted.
http://library.whitehouse.gov/ThisWeek.cgi?type=b&date=1&briefing=9
Re: US gov't crypto export
Posted by Ben Laurie <be...@algroup.co.uk>.
Marc Slemko wrote:
> > Surely the easy way is to lift the exportable crypt() things like
> > FreeBSD use (which is based on MD5, and hence has no problems)?
>
> The easy way is to use the md5 code already built into Apache. The only
> problem with that is it means that most Unixes can't use the same passwd
> file.
That's more-or-less what I meant - but you still have to turn it into a
crypt replacement (I agree this is pretty trivial). I think sharing the
passwd file is a non-issue - especially since we already do this on
FreeBSD (so, hey, they can share with FreeBSD, whoo!).
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/
Re: US gov't crypto export
Posted by Marc Slemko <ma...@worldgate.com>.
On Fri, 18 Sep 1998, Ben Laurie wrote:
> Bill Stoddard wrote:
> >
> > Marc Slemko wrote:
> > >
> > > anyone care to comment on the US gov'ts easing of export restrictions?
> > >
> > > As pathetic as it may be, from what I understand they have eliminated the
> > > need for licenses to export 56-bit crypto, wihch means that there should
> > > be no doubt at all about crypt() being exportable. (yes, I know, in
> > > theory you can do crypt() safely and argue it is not two-way but AFAIK
> > > it isn't entirely clear if that can be supported)
> > >
> > > Is this true? If so, are we willing to add code required to do crypt()
> > > so Win32 can have consistent htaccess passwd encryption.
> >
> > I've been talking to some of IBM's security guys who keep current on the
> > regs. They tell me there are no government regs preventing us from
> > putting crypt() on Win32. The crypt function actually hashes passwords
> > and does not encrypt them. Data put through crypt() is not recoverable
> > (i.e., it is not two way) as you say.
> >
> > If we have crypt() with clear copyrights, we should include it in Win32,
> > IMHO.
>
> Surely the snag is that to implement crypt() you have to implement DES,
> even if the crypt() interface doesn't expose the full functionality?
Exactly. For example, with some crypt() implementations, you can actually
dump the symbols and figure out how to use it to implement two-way
encryption. Other companies have historically had issues exporting
crypt() as well.
>
> Surely the easy way is to lift the exportable crypt() things like
> FreeBSD use (which is based on MD5, and hence has no problems)?
The easy way is to use the md5 code already built into Apache. The only
problem with that is it means that most Unixes can't use the same passwd
file.
Re: US gov't crypto export
Posted by Ben Laurie <be...@algroup.co.uk>.
Bill Stoddard wrote:
>
> Marc Slemko wrote:
> >
> > anyone care to comment on the US gov'ts easing of export restrictions?
> >
> > As pathetic as it may be, from what I understand they have eliminated the
> > need for licenses to export 56-bit crypto, wihch means that there should
> > be no doubt at all about crypt() being exportable. (yes, I know, in
> > theory you can do crypt() safely and argue it is not two-way but AFAIK
> > it isn't entirely clear if that can be supported)
> >
> > Is this true? If so, are we willing to add code required to do crypt()
> > so Win32 can have consistent htaccess passwd encryption.
>
> I've been talking to some of IBM's security guys who keep current on the
> regs. They tell me there are no government regs preventing us from
> putting crypt() on Win32. The crypt function actually hashes passwords
> and does not encrypt them. Data put through crypt() is not recoverable
> (i.e., it is not two way) as you say.
>
> If we have crypt() with clear copyrights, we should include it in Win32,
> IMHO.
Surely the snag is that to implement crypt() you have to implement DES,
even if the crypt() interface doesn't expose the full functionality?
Surely the easy way is to lift the exportable crypt() things like
FreeBSD use (which is based on MD5, and hence has no problems)?
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/
Re: US gov't crypto export
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
Marc Slemko wrote:
>
> anyone care to comment on the US gov'ts easing of export restrictions?
>
> As pathetic as it may be, from what I understand they have eliminated the
> need for licenses to export 56-bit crypto, wihch means that there should
> be no doubt at all about crypt() being exportable. (yes, I know, in
> theory you can do crypt() safely and argue it is not two-way but AFAIK
> it isn't entirely clear if that can be supported)
>
> Is this true? If so, are we willing to add code required to do crypt()
> so Win32 can have consistent htaccess passwd encryption.
I've been talking to some of IBM's security guys who keep current on the
regs. They tell me there are no government regs preventing us from
putting crypt() on Win32. The crypt function actually hashes passwords
and does not encrypt them. Data put through crypt() is not recoverable
(i.e., it is not two way) as you say.
If we have crypt() with clear copyrights, we should include it in Win32,
IMHO.
--
Bill Stoddard
stoddard@raleigh.ibm.com