Re: NSA back doors in encryption products

[Steven M. Bellovin]

In message , "Arnold G. Reinhold" writes:
>At 11:17 AM -0500 5/25/2000, Rick Smith wrote:


>o There is the proposed legislation I cited earlier to protect these 
>methods from being revealed in court.  These are not aimed at news 
>reports (that would never get passed the Supreme Court), but would 
>allow backdoors to be used for routine prosecutions without fear of 
>revealing their existence.

That's tricky, too, since the Constitution provides the *defense* with 
a guarantee of open trials.  At most, there are laws to prevent 
"greymail", where the defense threatens to reveal something sensitive.  
In that case, the judge reviews its relevance to the case.  If it is 
relevant -- and a back door used to gather evidence certainly would be 
-- the prosecution can either agree to have it revelated or drop the 
case.

I'm not saying there aren't back doors that wouldn't fall into this 
category; I am saying that such a law would have to be very narrowly 
crafted to pass constitutional muster.

--Steve Bellovin

Re: Electronic elections.

[Mark A. Herschberg]

A few years back I implemented the scheme described in "A practical secret 
voting scheme for large scale elections", by Atsushi Fujioka, Tatsuaki 
Okamoto, and Kazuo Ohta (Proceedings AUSCRYPT '92, 1993, 244-251).  The system 
is called E-Vox and can be found at http://theory.lcs.mit.edu/~cis/voting/votin
g.html

This summer (probably July or August) I'm planning on turning it into an Open 
Source project, since neither Ben Adida nor I are currently doing work at MIT.

The web page given above also has a list of other Electronic Voting projects.  
You should also check out Lorrie Cranor's  web page 
http://www.research.att.com/~lorrie/voting/


--Mark

Re: Electronic elections.

[Helger Lipmaa]

On Sat, 27 May 2000, Per Kangru wrote:

> So Im looking for a system that will give me the following:
> 
> * Ease of use for non computer experts.
> 
> * Secure, i.e. one vote per person.
> 
> * Anonymous voting, i.e. no conection between a certain vote and a certain
>   person.
> 
> * Shall produce good statistics and be able to perform sanity checks of
>   the data, i.e. if any cheating is undertaken it shall be easy to find
>   out.
> 
> * Easy to administrate, shall be able to handle both parties and
>   persons. (A vote can be casted both on a party and on a special person
>   in that party)

Cryptographers are usually also concerned with the possibility that the
server is corrupted. Your solution does not address that.

My own a little bit (i.e. more than one year) survey 'for dummies' on
e-voting is available at
http://www.cc.ioc.ee/training/unesco/onlinegov/security/vote.html.

Helger Lipmaa
http://www.tcm.hut.fi/~helger

Electronic elections.

[Per Kangru]

I am currently investigating the possibility to conduct electronic
elections on the web.

My aim is to be able to cut the costs and the administative overhead of
having an ordinary election. 

The organization it involves right now is Uppsala university student union
and its approximate 30.000 members. Every year they elect 41 people to
rule over the student union for the nexrt year, currently 2/3 of the votes
comes via snail-mail and the rate of participation is very low.

So Im looking for a system that will give me the following:

* Ease of use for non computer experts.

* Secure, i.e. one vote per person.

* Anonymous voting, i.e. no conection between a certain vote and a certain
  person.

* Shall produce good statistics and be able to perform sanity checks of
  the data, i.e. if any cheating is undertaken it shall be easy to find
  out.

* Easy to administrate, shall be able to handle both parties and
  persons. (A vote can be casted both on a party and on a special person
  in that party)


One can assume that all the voters have a encryted passfrase stored in a
central password file. 

The voters are not familiar with personal certificates and we can't expect
that we can use thoose for identification.

The system I have sketched on works as follows:

1) A website presents all the data on the candidates and the parties
   involved. 

2) A voter can log in to the system and cast a vote on a special
   candidate in a special party.

3) The login is carried out using SSLv3 encrypted connection and
   authorizing against a encrypted passwd file.

4) Ones a voter submits the vote a post in a sql-database is created
   where one stores that a certain person has submitted a vote and from
   what computer (ip#) and at what time. 

5) The vote is stored in another table. The party and the possible
   candidate is stored. As well is a encrypted value about how submitted
   the vote stored. This is pgp encrypted using a public key that belongs
   to a trusted third party. Possible even with a key that is in
   part stored at several different locations, i.e. one pice at each of
   the participating parties.


In point 5 above I wonder wether there is any other good way of securing
both the anonymity of the voters and preserving the security. 

If there is no system available for doing this I will most probably
implement it as a Roxen module with a mysql backend.

What do you think of the above described system? What work has been dowe
before and is there any similar organizations having electronic elections? 




Best regards,



/Per

|-Per Kangru--http://kangru.org-+46-(0)[EMAIL PROTECTED]| 
|Lasercooling @ Stockholm Univ. +46-(0)8-161136   [EMAIL PROTECTED]   |
|Consultant   @ Roxen IS AB +46-(0)709-153939 [EMAIL PROTECTED]|  
|-PGP-fingerprint-672C8-5632-7DC49-CFECC-E0EE-3DA4-E82E-A036F-59A1| 

Re: NSA back doors in encryption products

[Eugene Leitl]

Jim Choate writes:

 > No, you don't. Sign the source and binaries.

You trust your secure hash reporting you the truth? Duh.

Re: NSA back doors in encryption products

[Ben Laurie]

David Honig wrote:
> 
> At 09:54 PM 5/24/00 -0500, Jim Choate wrote:
> >As to inserting a trapdoor in an FPGA, I don't see any reason at all that
> >a trapdoor can't be inserted with the appropriate understanding of the
> >state space and chosing a rare state to trigger your bypass.
> 
> Yes but *once* you've verified the RTL (and from them the masks)
> you don't have to worry about some stray applet hosing your security.
> You do with software.

Errr ... you do with an FPGA, surely?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/

Andrew Fernandes on NSA back doors

[John Young]

Duncan Campbell sends along with permission of Andrew:

Additional comment from Andrew D. Fernandes of Cryptonym 
Corporation  (who discovered the NSA_KEY) on the MS/Campbell
exchange on the NSA_KEY :


Microsoft's insistence that the second key is there for backup 
purposes is not a satisfying explanation for a number of reasons. 
The reason that the arguments are not satisfying is clear if you 
have experience using dedicated tamper-resistant crypto-boxes.

A dedicated crypto-box internally generates a key pair, exports 
the public key, and then digitally signs designated input whenever 
properly prompted. These boxes are specifically designed to 
NEVER export the private key as plaintext. Furthermore, these 
boxes are designed to destroy their private key if the box detects 
any attempted physical tampering.

The danger with a crypto-box is not only the potential compromise 
of the private key. An almost as great danger is the loss of the 
private key! Consider that a disgruntled employee could destroy 
the private key by merely hitting the crypto-box, sticking a paperclip 
into an input port, or dropping an ice cube on the box... (no, I'm not 
making up the ice cube part - these boxes are usually temperature 
sensitive). What you would have is a very ready denial-of-service 
attack.

Therefore, almost universally, crypto-boxes allow the export of the 
private key in encrypted format. A good crypto-box will even use 
advanced cryptographic techniques called "secret splitting" to split 
the encrypted key into several different parts - one part for each 
senior manager. That way, if the crypto-box is lost or destroyed, a 
new crypto-box can be quickly initialized and utilized.

It is possible that Microsoft's CSP team has a crypto-box that will not 
export the private key even if it is in encrypted or secret-split format. 
If that is true, it would be natural to assume a second backup key 
would be necessary. However, look at this scenario in terms of 
"failure analysis", where the security of the CSP scheme fails if a 
signing key is lost.

There are two signing keys that can load a CSP. If the first key is 
lost, Microsoft could rely on using the second key. If the second 
key is lost, then Microsoft is out of luck, and must patch or upgrade 
every copy of Windows in the world, as well as every CSP it has 
ever signed, all because they did not buy a crypto-box capable 
of data recovery.

Call me draconian, but given the extraordinarily high level of 
cryptographic expertise that Microsoft employs, I would fire the 
design team that presented a CSP signing system based on a 
single backup, rather than data recovery.

So it is rather strange that the CSP signing key (labeled "_KEY") 
has backup key at all... even more strange that it would be labeled 
"_NSAKEY".

In fact, there is no specific requirement in the BXA's EAR that 
backup keys exist.   That document draws heavily on the 
Wassenaar Arrangement on the export of dual-use goods 
(http://www.wassenaar.org/) for its wording and substance.

-

SST: Snake-oil?

[Dave Del Torto]

Snake Oil Alert:

"Secure Shuttle Transport"
 

 Security Grade: "D-"   (Preliminary Review)

"Boomerang Online" Software offers "Secure Shuttle Transport" (SST),
an "encrypted" instant-message utility modeled somewhat after AOL's
"AIM".

I give them credit for realizing that it's a nice idea to encrypt
such IM's but, unfortunately, their representatives state that they
are not planning on releasing the source code, and see no need to
seek validation of their implementation of the RSA algorithm --even
by trusted third party security reviewers.

 From what I can tell, this one's basically Dead On Arrival. They
appear to be doing just about *everything* wrong... (certainly as far
as security, which seems to the the "raison d'etre" of this product)
...but at least they're consistent. :)

Some Telltale Signs:

1. The website is an embarrassing mess of frames (see:
,
 ...and Boomerang is
supposedly known for Web Design software?). Competence?
2. This appears to be their first public foray into security software
design, and they seem to think they know best how it's done.
3. The SST docs (which I can no longer even find separately on their
website) are in HTML but aren't even viewable on their website(?).
There's no technical information at all about how SST actually
encrypts, or what formats are used or ANYthing on their website (when
you can actually view the frames)
4. Their software is more eye-candy (plenty of "skins" but no bones)
than security oriented ...and, last but not least...
5. Their sales people haven't even been trained to _parrot_ anything
remotely responsible about the security of their product.

Encourage your worst enemies to download it ASAP. ;)

dave

___
"Security is not for wimps."  --J. Gilmore

Re: NSA back doors in encryption products

[Jim Choate]

On Fri, 26 May 2000, David Honig wrote:

> At 09:54 PM 5/24/00 -0500, Jim Choate wrote:
> >As to inserting a trapdoor in an FPGA, I don't see any reason at all that
> >a trapdoor can't be inserted with the appropriate understanding of the
> >state space and chosing a rare state to trigger your bypass.
> 
> Yes but *once* you've verified the RTL (and from them the masks) 
> you don't have to worry about some stray applet hosing your security.
> You do with software.

No, you don't. Sign the source and binaries.



The future is downloading. Can you hear the impact?

O[rphan] D[rift>]
Cyber Positive

   The Armadillo Group   ,::;::-.  James Choate
   Austin, Tx   /:'/ ``::>/|/  [EMAIL PROTECTED]
   www.ssz.com.',  `/( e\  512-451-7087
   -~~mm-'`-```-mm --'-

Re: NSA back doors in encryption products - "gaming the system"

[John Gilmore]

> ... I cannot conceive that the NSA or some even blacker
> agency of the US intelligence community has not obtained a complete set
> of source code for all major releases and upgrades of Windows and
> NT/2000 and probably many major MS applications.

He's right, and not just for Windows...

Under the old export controls, NSA could demand source code as a
condition of granting ANY export license.  Even under today's utterly
serene and benevolent regime (Big Brother says we're currently not at
war with Oceania) there's still this mysterious "one-time review" for
commercial software exports.  I believe it exists almost solely for
the purpose of giving NSA access to source code, so it can, in its own
words, "game the system" to get back-door access to encrypted data.

If you don't think NSA is using export controls as a lever to work
covertly with US industry to undermine the security of US products,
read this abridged transcript of classified hearings held with the
House International Relations subcommittee in July, 1997.  (This
unclassified version was later released.)  The whole thing is at:

http://jya.com/hir-hear.htm

[page 17]
 5STATEMENT OF WILLIAM P. CROWELL, DEPUTY DIRECTOR, NATIONAL
 6SECURITY AGENCY
 7
 8 Mr. Crowell. Since this is a closed session, I would
 9like to go a lot further than we have in a lot of hearings
10about the national security implications.
11 I would like to begin by saying that the National
12Security Agency in particular understands that we have a dual
13responsibility with regard to this issue. We have a
14responsibility for providing signals intelligence to the
15Nation, intelligence information which is vital for us being
16able to do our war planning and our weapons developments,
17weapons assessments, all of those kinds of things, [redaction
18---] and so we have an interest in<===
19[redaction--] the encryption system. But we also have <===
20an interest in protecting information, and that is part of
21national security, and we recognize that.
[page 29]
 1 Mr. Hamilton. In other words, you cannot accept any
 2export -- anything with keys longer than 56 bits? You cannot
 3accept those exports?
 4 Director Freeh. Yes, with all the other provisions of
 5the bill with respect to exports.
 6 Mr. Hamilton. That is your bottom line?
 7 Mr. Reinsch. Let me phrase it slightly differently, if I
 8may, because this is closed. Coming to terms with this issue
 9is an evolutionary process. You have just referred to some
10phases of the evolution, and I think your point is well taken  ...
[page 30]
 4 Mr. Reinsch. This is an evolutionary process. So I want
 5to look down the road, and I can't walk you very far down that
 6road quite yet, but think a little bit about what we are
 7saying. What he needs is key recovery. What he needs is
 8review of each product once before it goes out the door.  <===
 9 Mr. Crowell. And key management infrastructure.
10 Mr. Reinsch. I was including that. The question is how
11do we get there? We were trying to get there through export
12controls. That may or may not be the best way. Arguably
13import control might be the better way, but nobody wants to do
14import controls, and they are off the map.
15 If you can think of a better way to get to where we want
16to go, then I think that that is a worthwhile discussion to
17have, but we haven't been able to come up with a better way.
18And the more we erode the export control base, the farther
19away we get from our goal. 
[page 31; This is Rep. Goodlatte speaking:]
19 Sun Microsystems just a few weeks ago announced a program
20with a Russian company to create the cryptography, import it
21into the United States, attach it to the underlying software.
22Sun Microsystems would sell it domestically, and the Russians
23would sell it internationally. Everybody would be able to
24communicate with each other, bypass our export control laws,
25and suddenly we have the Russians creating our cryptography
[page 32]
 1rather than U.S. companies.
 2 It makes no sense, in my opinion, to allow that kind of
 3transition of an industry that we dominate to take place and
 4take away from Mr. Crowell the opportunity to work with the   <===
 5domestic U.S. companies on a case-by-case, confidential basis <===
 6to create the kind of information they need to have to game   <===
 7the system and instead turn that over to foreign governments  <===
...
[page 34]
14 Mr. Crowell. I will repeat something I said when I came
15in. We have accepted that we will be faced with a much harder
16problem in the future than we have been in the past. We have
17accepted that. We hav

Re: NSA back doors in encryption products

[Ben Laurie]

Bill Stewart wrote:
> 
> At 02:08 PM 05/24/2000 +0100, Ben Laurie wrote:
> >John Gilmore wrote:
> >> Anybody tested the primes in major products lately?
> >Interesting point ... of course, these days one can produce checkable
> >certificates of primality - but I'm not aware of any free software to do
> >it ... is there any?
> 
> There's primality testing software in PGP's key generation routines,
> and also in the GIMPS Great Internet Mersenne Prime Search software.
> It's not designed for an independent input of test material,
> but that's not a tough thing to add wrappers for.
> I think somebody also did an N-Lines-Of-Perl version.
> 
> GIMPS uses Lucas-Lehmer tests; I forget if PGP uses that or Miller-Rabin.
> It's a probablistic primality testing system, and if you wanted to do a
> widespread-use backdoor-checker, it might make sense to use some
> test primes in the usual sequence and some chosen at random.
> 
> IIRC, Technically, it won't catch use of Carmichael numbers, but
> there aren't a lot of those.

I meant actual proofs of primality, not statistical tests!

> 
> More seriously, there's David Jablon's point that it won't catch
> use of real primes from a small search space or other RNG tricks.

?? For a lot of applications the prime is published...

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/

Re: NSA back doors in encryption products

[Dan Geer]

Conspiracy theories are irresistable labor-saving devices
in the face of complexity.
 -- Henry Louis Gates, speaking of OJ Simpson


--dan