Crypto problems again

Crypto problems again

[Lars Magne Ingebrigtsen]

I've just had a mail from Stallman about crypto-related code in
Gnus.  He wants the crypto code out of Emacs (due to the
still-lingering crypto export restrictions in the US).  (I thought
those problems were gone by now, but apparently not.)

So we need to compile a list of crypto-related files and functions in
Gnus, so that Stallman can remove those from the Emacs distribution...

Most of the crypto code was added post Gnus 5.9, so there might not
be all that much to remove, but I'm not intimately familiar with the
crypto code.
 
-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Crypto problems again

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I've just had a mail from Stallman about crypto-related code in
> Gnus.  He wants the crypto code out of Emacs (due to the
> still-lingering crypto export restrictions in the US).  (I thought
> those problems were gone by now, but apparently not.)
>
> So we need to compile a list of crypto-related files and functions in
> Gnus, so that Stallman can remove those from the Emacs distribution...
>
> Most of the crypto code was added post Gnus 5.9, so there might not
> be all that much to remove, but I'm not intimately familiar with the
> crypto code.

What's the definition of crypto code?  For example, does an elisp
wrapper around GnuTLS count?  A wrapper around GnuPG?  Emacs contains
a MD5 implementation in C, is it "crypto"?  Or MD4, SHA-1?  Are
authentication mechanisms based on hashing, like CRAM-MD5, "crypto"?

In any case, files that may be relevant to look at include (not all
might have been part of Gnus 5.9):

ntlm.el
pgg*.el
sasl*.el
md4.el
hmac-*.el
imap.el
sieve-manage.el
tls.el
starttls.el
sha1-el.el
pop3.el
mml-sec.el
mml-smime.el
mml1991.el
mml2015.el
canlock.el
netrc.el

crypto in netrc.el and gnus-encrypt.el (was: Crypto problems again)

[Ted Zlatanov]

I'm also unsure (like Simon) about what's considered crypto code.  In
any case, netrc.el wraps around OpenSSL right now, but that will be
removed as soon as I put gnus-encrypt.el into Gnus.  So netrc.el is
not crypto code by any measure.

gnus-encrypt.el has a built-in XOR cipher which is very simple, I
doubt that's considered strong encryption.  It may use encryption
ciphers from gencrypt.el, which is not written yet, but I don't plan
to add any strong ciphers to gnus-encrypt.el.  I may add an encoding
cipher, which won't even encrypt anything.  Does that help?

By the way, gnus-encrypt.el is working pretty well for me so I'll be
putting it into Gnus soon, together with support in netrc.el.  I hope
that's OK with everyone.

Ted

Re: Crypto problems again

[Wes Hardaker]

>>>>> On Mon, 02 Feb 2004 19:02:54 +0100, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

Lars> I've just had a mail from Stallman about crypto-related code in
Lars> Gnus.  He wants the crypto code out of Emacs (due to the
Lars> still-lingering crypto export restrictions in the US).  (I thought
Lars> those problems were gone by now, but apparently not.)

They are.  He's probably just complaining they didn't go far enough.
You have to register the code one time only but beyond that it's free
and clear.  In fact, since he's already released it it seems even more
pointless.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: Crypto problems again

[Wes Hardaker]

>>>>> On Mon, 02 Feb 2004 19:54:16 +0100, Simon Josefsson <jas@extundo.com> said:

Simon> What's the definition of crypto code?

<IANL>
I think that also depends on the era of the regulation being
considered.  A number of years ago, it included wrappers or even
comments like "put encryption calls here".  Now, however, I believe at
least with the U.S. that it actually means implementation of the
actual cryptography algorithm itself.  I'd ask RMS what he actually
means by it since he probably cares.
</IANL>

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: Crypto problems again

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> What's the definition of crypto code?  For example, does an elisp
> wrapper around GnuTLS count?  A wrapper around GnuPG?  Emacs contains
> a MD5 implementation in C, is it "crypto"?  Or MD4, SHA-1?  Are
> authentication mechanisms based on hashing, like CRAM-MD5, "crypto"?

Ok; I'll ask RMS...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Crypto problems again

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> What's the definition of crypto code?  For example, does an elisp
>> wrapper around GnuTLS count?  A wrapper around GnuPG?  Emacs contains
>> a MD5 implementation in C, is it "crypto"?  Or MD4, SHA-1?  Are
>> authentication mechanisms based on hashing, like CRAM-MD5, "crypto"?
>
> Ok; I'll ask RMS...

And here's the response from RMS:

----------

    What's the definition of crypto code? 

I will explain how I understand the matter.  However, why ask me when
you can learn from experts?  There must be web sites that explain this
issue in detail.  I don't know which sites, but you can find them more
easily than I can.

					   For example, does an elisp
    wrapper around GnuTLS count?

Yes.

				  A wrapper around GnuPG?

Yes.  Anything designed specifically to work with an encryption
program is encryption-related code.  However, the existence of general
hooks that could be used for anything does not constitute
encryption-related code.

							   Emacs contains
    a MD5 implementation in C, is it "crypto"?

No, checksums do not count as encryption.

						Or MD4, SHA-1?

I never heard of them and I don't know what they do,
so I cannot answer.

								Are
    authentication mechanisms based on hashing, like CRAM-MD5, "crypto"?

Authentication does not count as encryption.

------------

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Crypto problems again

[Wes Hardaker]

>>>>> On Thu, 05 Feb 2004 18:25:03 +0100, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

Lars> A wrapper around GnuPG?

Lars> Yes.  Anything designed specifically to work with an encryption
Lars> program is encryption-related code.  However, the existence of general
Lars> hooks that could be used for anything does not constitute
Lars> encryption-related code.

Bummer, that means your scrubbing will bee much harder.

Lars> Emacs contains
Lars> a MD5 implementation in C, is it "crypto"?

Lars> No, checksums do not count as encryption.

At least he got that  right.

Lars> Or MD4, SHA-1?

Lars> I never heard of them and I don't know what they do,
Lars> so I cannot answer.

Hasn't heard of SHA-1?  Wow.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: Crypto problems again

[Ted Zlatanov]

On Thu, 05 Feb 2004, larsi@gnus.org wrote:

> And here's the response from RMS:
> 
> ----------
> 
>     What's the definition of crypto code? 
> 
> I will explain how I understand the matter.  However, why ask me
> when you can learn from experts?  There must be web sites that
> explain this issue in detail.  I don't know which sites, but you can
> find them more easily than I can.

Bah, this makes no sense.  There's a clear distinction between
trivial ciphers, such as ROT-13 and the XOR cipher I put into
gnus-encrypt.el, and strong crypto.  Is Base64 crypto?  UUdecode?

Going to web sites is nice, but does not answer the questions.  I
hope RMS can assign someone specific to look at the particular issues
in Gnus instead of what he suggests above.

Considering code that wraps around a crypto program also crypto is
even stranger, IMHO.  It really complicates life needlessly.

Anyhow, I can make gnus-encrypt.el optional, and the functions it
provides can be defined as empty wrappers in gnus.el, overridden if
you explicitly load gnus-encrypt.el.  Would that be OK?

Thanks
Ted

Re: Crypto problems again

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Simon Josefsson <jas@extundo.com> writes:
>>
>>> What's the definition of crypto code?  For example, does an elisp
>>> wrapper around GnuTLS count?  A wrapper around GnuPG?  Emacs contains
>>> a MD5 implementation in C, is it "crypto"?  Or MD4, SHA-1?  Are
>>> authentication mechanisms based on hashing, like CRAM-MD5, "crypto"?
>>
>> Ok; I'll ask RMS...
>
> And here's the response from RMS:
>
> ----------
>
>     What's the definition of crypto code? 
>
> I will explain how I understand the matter.  However, why ask me when
> you can learn from experts?  There must be web sites that explain this
> issue in detail.  I don't know which sites, but you can find them more
> easily than I can.

Anyone?  Preferably authoritative information from a governmental
department or so.

> 					   For example, does an elisp
>     wrapper around GnuTLS count?
>
> Yes.

This implies several modifications, for example to imap.el.  I don't
think I'll be able to look into this soonish.  If someone else wants
to look into this, I could probably find the time to review a proposed
patch for any (non-intended) negative effects.

> 								Are
>     authentication mechanisms based on hashing, like CRAM-MD5, "crypto"?
>
> Authentication does not count as encryption.

So our new SASL library is not a problem, I think.  OTOH, some
mechanisms (NTLM?) might use encryption as part of the authentication.
Does that count?  Even if it is weak encryption?  (56-bit DES.)

Re: Crypto problems again

[Jesper Harder]

Wes Hardaker <wes@hardakers.net> writes:

>>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> said:
>
> Lars> I've just had a mail from Stallman about crypto-related code
> Lars> in Gnus.  He wants the crypto code out of Emacs (due to the
> Lars> still-lingering crypto export restrictions in the US).  (I
> Lars> thought those problems were gone by now, but apparently not.)
>
> They are.  He's probably just complaining they didn't go far enough.
> You have to register the code one time only but beyond that it's
> free and clear.

AFAIK, even if you do register it with some US spy agency, you're
still not allowed to export to certain countries.

Why should, say, Cubans not be allowed to use Emacs?  I can see why he
doesn't want to do that.

Re: Crypto problems again

[Josh Huber]

This all seems a little silly.

Can't we just notify the BXA?

For a lot more information (including legal advice), see what Debian
had to go through to get crypto into main:

http://www.debian.org/legal/cryptoinmain

-- 
Josh Huber

Re: Crypto problems again

[Wes Hardaker]

>>>>> On Thu, 05 Feb 2004 21:53:18 +0100, Simon Josefsson <jas@extundo.com> said:

>> Are authentication mechanisms based on hashing, like CRAM-MD5,
>> "crypto"?  Authentication does not count as encryption.

Simon> So our new SASL library is not a problem, I think.

I'm pretty sure SASL has some encrypted forms of authentication.

Simon> Even if it is weak encryption?  (56-bit DES.)

Yes, DES would count too.


-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: Crypto problems again

[Wes Hardaker]

>>>>> On Thu, 05 Feb 2004 16:29:32 -0500, Josh Huber <huber+news@alum.wpi.edu> said:

Josh> Can't we just notify the BXA?

I suspect this is due to RMS not wanting to do that.  He must know
about it.  It's certainly not hard too notify the BXA (I've done so 3
times in the past so far)

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: Crypto problems again

[Wes Hardaker]

>>>>> On Thu, 05 Feb 2004 22:22:29 +0100, Jesper Harder <harder@ifa.au.dk> said:

>> They are.  He's probably just complaining they didn't go far enough.
>> You have to register the code one time only but beyond that it's
>> free and clear.

Jesper> AFAIK, even if you do register it with some US spy agency, you're
Jesper> still not allowed to export to certain countries.

Jesper> Why should, say, Cubans not be allowed to use Emacs?  I can see why he
Jesper> doesn't want to do that.

No, If you publish it on a web page (for example) or an ftp site (for
another example) the current regulations do not prohibit you from
worrying about who accesses it (including Cubans, North Koreans,
...).  There are 7 countries that you can't *push* it to.  But they're
allowed to pull it from a public site.  Silly ain't it.


-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: Crypto problems again

[Jesper Harder]

Wes Hardaker <wes@hardakers.net> writes:

>>>>>>  Jesper Harder <harder@ifa.au.dk> said:
>
> Jesper> AFAIK, even if you do register it with some US spy agency,
> Jesper> you're still not allowed to export to certain countries.
>
> Jesper> Why should, say, Cubans not be allowed to use Emacs?  I can
> Jesper> see why he doesn't want to do that.
>
> No, If you publish it on a web page (for example) or an ftp site
> (for another example) the current regulations do not prohibit you
> from worrying about who accesses it (including Cubans, North
> Koreans, ...).  There are 7 countries that you can't *push* it to.
> But they're allowed to pull it from a public site.  Silly ain't it.

But the stuff on the Debian page still recommends blocking embargoed
countries:

  We recommend that you perform IP checking and deny downloads to
  known embargoed countries. This due diligence also would provide a
  defense to a claim of civil liability. If you find out that your
  software has been downloaded to a prohibited destination, then I
  recommend that you block future downloads to that specific site
  unless and until you obtain a license from BXA.

Re: Crypto problems again

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> 				  A wrapper around GnuPG?
>
> Yes.  Anything designed specifically to work with an encryption
> program is encryption-related code.  However, the existence of general
> hooks that could be used for anything does not constitute
> encryption-related code.

Can we have general hooks to invoke a shell stream (which is already
implemented, at least in imap.el) in the code, and then in the manual
describe how to use that mechanism to invoke, e.g., GnuTLS instead?
That is, giving explicit encryption related examples.  Or does the
export ban cover writing too?  I think using general shell streams
could be a reasonable solution, given the circumstances.  It would
make it easier for users if they can cut'n'paste an example to use
GnuTLS.

Re: Crypto problems again

[Wes Hardaker]

>>>>> On Thu, 05 Feb 2004 23:36:36 +0100, Simon Josefsson <jas@extundo.com> said:

Simon> That is, giving explicit encryption related examples.  Or does the
Simon> export ban cover writing too?

Well, you'd have to ask RMS again.  He's the one being picky.  In the
past, written non-machine readable code was how pgp used to be
exported.  It was printed on paper, sent out of the country, and the
OCRed as best as possible back in.  But the manual will be sent
electronically in this case, and thus cut-n-paste is possible and I'm
not sure that'd fly with RMS since it sounds like he's using old
legal definitions and that would probably be prohibited.


-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: Crypto problems again

[Wes Hardaker]

>>>>> On Thu, 05 Feb 2004 23:18:46 +0100, Jesper Harder <harder@ifa.au.dk> said:

Jesper> We recommend that you perform IP checking and deny downloads
Jesper> to known embargoed countries. This due diligence also would
Jesper> provide a defense to a claim of civil liability. If you find
Jesper> out that your software has been downloaded to a prohibited
Jesper> destination, then I recommend that you block future downloads
Jesper> to that specific site unless and until you obtain a license
Jesper> from BXA.

That last part seems to imply that after you get a license you should
release the block.  This paragraph makes no sense, since you can't do
the first part until after you write BXA and the second part isn't
required after you write the BXA.  It's almost written like an opinion
that even though you can release it to one of the 7 evil countries of
the world (TM) (or is it now 5 since we took over 2 of them?) you
shouldn't do so because it would be morally wrong.

(in no way am I stating an opinion on the matter one way or another in
the above text...  Just ranting at the end of the day)


-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: Crypto problems again

[Jesper Harder]

Wes Hardaker <wes@hardakers.net> writes:

>>>>>> On Thu, 05 Feb 2004 23:18:46 +0100, Jesper Harder <harder@ifa.au.dk> said:
>
> Jesper> We recommend that you perform IP checking and deny downloads
> Jesper> to known embargoed countries. This due diligence also would
> Jesper> provide a defense to a claim of civil liability. If you find
> Jesper> out that your software has been downloaded to a prohibited
> Jesper> destination, then I recommend that you block future downloads
> Jesper> to that specific site unless and until you obtain a license
> Jesper> from BXA.
>
> That last part seems to imply that after you get a license you should
> release the block.  This paragraph makes no sense, since you can't do
> the first part until after you write BXA and the second part isn't
> required after you write the BXA.

I think what they mean is:

  If you become aware that an evil Taleban is downloading cryptoEmacs,
  you should block his IP unless you obtain permission to export it to
  Taleban controlled Afghanistan.  You won't get this permission, of
  course, so the IP should stay blocked.

> It's almost written like an opinion that even though you can release
> it to one of the 7 evil countries of the world (TM) (or is it now 5
> since we took over 2 of them?) you shouldn't do so because it would
> be morally wrong.

I don't think that's the intent.  It might make more sense if you read
the context, <http://www.debian.org/legal/cryptoinmain> near the
bottom.

Re: Crypto problems again

[Jesper Harder]

Simon Josefsson <jas@extundo.com> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> I will explain how I understand the matter.  However, why ask me when
>> you can learn from experts?  There must be web sites that explain this
>> issue in detail.  I don't know which sites, but you can find them more
>> easily than I can.
>
> Anyone?  Preferably authoritative information from a governmental
> department or so.

,----[ http://www.bxa.doc.gov/Encryption/EncFactSheet6_17_02.html ]
|
| no review or notification is required to export or reexport the
| following: [...]
| 
|   3. Items with limited use of cryptography, such as for
|      authentication, digital signature, execution of copy protected
|      software [...]
`----

So authentication should be fine (and ditto for signatures).

Re: Crypto problems again

[Jesper Harder]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Most of the crypto code was added post Gnus 5.9, so there might not
> be all that much to remove, but I'm not intimately familiar with the
> crypto code.

How about a `defcripple' macro?

(defvar cripple nil)

(defmacro defcripple (&rest body)
  (if cripple
      `(defun ,(car body) ,(cadr body)
	 (error "This software has been crippled according to US export regulations.
If you are a non-US citizen you can get the good stuff at http://crypto.foo"))
    `(defun ,@body)))

We use `defcripple' rather than `defun' for all crypto functions, and
when it's time to include in Emacs proper, we just set cripple to t
and macroexpand the defcripple forms.  Voila, no crypto code.

Re: Crypto problems again

[Wes Hardaker]

>>>>> On Fri, 06 Feb 2004 02:47:43 +0100, Jesper Harder <harder@ifa.au.dk> said:

Jesper> (defmacro defcripple (&rest body)
Jesper> (if cripple
Jesper> `(defun ,(car body) ,(cadr body)
Jesper> (error "This software has been crippled according to US export regulations.
Jesper> If you are a non-US citizen you can get the good stuff at http://crypto.foo"))
Jesper> `(defun ,@body)))

Jesper> We use `defcripple' rather than `defun' for all crypto functions, and
Jesper> when it's time to include in Emacs proper, we just set cripple to t
Jesper> and macroexpand the defcripple forms.  Voila, no crypto code.

I think RMS' view is that you can't even leave a mark where the crypo
code *should* go (IE, even a comment saying 'put it here' would be
illegal).  This definitely falls into "leaving a mark".

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: Crypto problems again

[Jesper Harder]

Wes Hardaker <wes@hardakers.net> writes:

>>>>>> Jesper Harder <harder@ifa.au.dk> said:
>
> Jesper> (defmacro defcripple (&rest body)
>
> I think RMS' view is that you can't even leave a mark where the
> crypo code *should* go (IE, even a comment saying 'put it here'
> would be illegal).  This definitely falls into "leaving a mark".

Yeah, you're probably right.

Hmm, but since digital signatures are explicitly not covered by the
export restrictions, we could just move the encryption functions to
contrib.

That would leave the infrastructure code intact.  I don't even think
it's particularly sneaky -- most of that code would be the same even
if it was only designed for signatures ... not really surprising since
most of the difference between signing and encryption is just the
options passed to gpg.

Re: Crypto problems again

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 742 bytes --]

I would appreciate any advice regarding gnus-encrypt.el, please.
This is important because I have to remove the crypto wrapper code in
netrc.el!

gnus-encrypt.el works for me, I'm able to encrypt my .authinfo file
and decrypt it.  I haven't comitted the changes to CVS, because I
need to know where to put the code and how to hook it into Gnus.

The problem is that I want the gnus-encrypt package to be supported by
Gnus, meaning that the user should just load gnus-encrypt and have
support for gnus-encrypt-file-alist and all the other nice things in
that package.  But I'm not allowed to use most normal facilities in
order to do this.  What can I do?

Thanks
Ted

p.s. including gnus-encrypt.el for those who missed it the first
time...


[-- Attachment #2: gnus-encrypt.el --]
[-- Type: application/emacs-lisp, Size: 8436 bytes --]

Re: Crypto problems again

[Kai Grossjohann]

Ted Zlatanov <tzz@lifelogs.com> writes:

> The problem is that I want the gnus-encrypt package to be supported by
> Gnus, meaning that the user should just load gnus-encrypt and have
> support for gnus-encrypt-file-alist and all the other nice things in
> that package.  But I'm not allowed to use most normal facilities in
> order to do this.  What can I do?

It seems that the two entry points are *-insert-file-contents and
*-write-file-contents.  It looks as if you might be able to make it a
file handler.  You could just forego completion and that stuff, or
forward these operations to the normal handlers.

I wonder if crypto regulations require the Emacs maintainers to remove
file-name-handler-alist from the code?  That would break Ange-FTP and
Tramp and jka-compr...

Kai