From hh at hackhawk.net  Fri Feb  1 13:41:02 2002
From: hh at hackhawk.net (Hack Hawk)
Date: Fri, 01 Feb 2002 10:41:02 -0800
Subject: biometrics
In-Reply-To: <15447.61804.952105.436434@sandrock.uwaterloo.ca>
References: <v03110709b87cb2b1859c@[165.247.214.234]>
 <OFA3D51110.AFB34E00-ON87256B50.00005183@internet.ny.fdms.firstdata.com>
 <v03110709b87cb2b1859c@[165.247.214.234]>
Message-ID: <5.0.2.1.0.20020201103049.02b2f770@localhost>

At 08:13 AM 1/30/02 -0500, you wrote:
>Bill Frantz writes:
>  >
>  > What would be really nice is to be able to have the same PIN/password for
>  > everything.
>
>Do you really mean that?  Sure, if I only have to remember one thing
>it is easier for me.  It is also a complete nightmare if it is ever
>compromised.

Way back in the day (about a year ago), this guy I worked with set the 
security PIN for our local office and gave the PIN to several people in the 
office (about 5 people).

About a week later in casual conversation he said something to the effect 
that he hated remembering all these separate PIN's and such, so he always 
used the same PIN for everything to keep things simple.

I, being the devils advocate that I am, sparked up and said, "So, by 
knowing our Office security PIN, I now have access to your bank account if 
I get a hold of your ATM card?".  Man, I never seen a guy's face turn so 
many shades of red in just a few seconds.  LOL

I just thought I'd share it because I found it really funny at the 
time.  The office security PIN was changed shortly after that conversation.

- hawk




---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



From BKossmann at dthr.ab.ca  Fri Feb  1 13:40:50 2002
From: BKossmann at dthr.ab.ca (Kossmann, Bill)
Date: Fri, 1 Feb 2002 11:40:50 -0700 
Subject: FW: update.575
Message-ID: <2F1A38DC0413D311A7310090273AD52704201FC5@dthrexch01>

The article below may be of interest to members of this list.

Bill


-----Original Message-----
From: AIP listserver [mailto:physnews at aip.org]
Sent: Wednesday, January 30, 2002 09:04
To: physnews-mailing at aip.org
Subject: update.575


PHYSICS NEWS UPDATE                         
The American Institute of Physics Bulletin of Physics News
Number 575  January 30, 2002   by Phillip F. Schewe, Ben Stein,
and James Riordon

<snip previous article>

SQUEEZING INFORMATION FROM ZIPPING PROGRAMS.
Data compression programs, such as the file zipping applications
found on many personal computers, provide an unusual means to
analyze information. Researchers at the La Sapienza University in
Rome (Emanuele Caglioti, caglioti at mat.uniromal.it, 39-06-4991-
4972) have demonstrated how compression routines can accurately
identify the language, and even the author, of a document without
requiring anyone to bother reading the composition. The key to the
analysis is the measurement of the compression efficiency that a
program achieves when an unknown document is appended to
various reference documents.
      Zipping programs typically compress data by searching for
repeated strings of information in a file. The programs record a
single copy of the information and note the locations of subsequent
instances of the string. Unzipping a file consists of replacing various
bits of information at the locations recorded by the zipped file. 
Such file compression routines work better on long files because
programs are, in effect, learning about the type of information they
are encoding as they move  through the data. Add a page of Italian
text to an Italian document, and a zipping  program achieves good
efficiency because it finds words and phrases that appear earlier  in
the file. If, however, Italian text is appended to an English
document, the program is forced to learn a new language on the fly,
and compression efficiency is reduced.
       The researchers found that file compression analysis worked
well in identifying the language of files as short as twenty characters
in length, and could correctly sort books by author more than 93%
of the time.  Because subject matter often dictates vocabulary, a
program based on the analysis could automatically classify
documents by semantic content, leading to sophisticated search
engines. The technique also provides a rigorous method for various
linguistic applications, such as the study of the relationships
between different languages. Although they are currently focusing
on text files, the researchers note that their analysis should work
equally well for any information string, whether it records DNA
sequences, geological processes, medical data, or stock market
fluctuations. (D. Benedetto, E. Caglioti, and V. Loreto, Physical
Review Letters, 28 January 2002)



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



From dahonig at home.com  Fri Feb  1 14:09:37 2002
From: dahonig at home.com (D. A. Honig)
Date: Fri, 01 Feb 2002 11:09:37 -0800
Subject: An attack on the 'Trusted Traveler' Pass
In-Reply-To: <p0510031bb87f6ab2b152@[10.0.1.2]>
Message-ID: <3.0.5.32.20020201110937.007e39c0@mail.orng1.occa.home.com>

>
>Some day in the future, maybe a year from now, you may have a "trusted
>traveler" card. Congress wants it, the airlines need it and security
>experts endorse it.
>
>The benefits appear clear. With a tool to separate the wheat from the

So does an attack.  Befriend someone with such a card, give
her a gift with well hidden, unscented plastique and a barometric
detonator.  After some time she takes her planned flight and gets only a
cursory exam.  She neglects to mention the gift she's carrying (they don't
even ask the 2 security questions reliably, any more, anyway).  

It worked over Lockerbie, it'll work again.  The Lockerbie carrier
had the equivalent of a "trusted traveller" card --she was a white
woman.












---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



From ncb at pobox.com  Fri Feb  1 17:02:09 2002
From: ncb at pobox.com (Nicholas Brawn)
Date: Sat, 2 Feb 2002 09:02:09 +1100
Subject: CFS vs. loopback encryption (was Re: [open-source] File encryption)
In-Reply-To: <Pine.OSF.4.10.10201300450160.5755-100000@alpha.hut.fi>
Message-ID: <56A53A20-175F-11D6-9052-000393471DA8@pobox.com>

What are people's thoughts on CFS vs. loopback encryption? I've used CFS 
in the past and found it quite useful, though as Matt said - a little 
long in the tooth. Never really looked into loopback encryption (which 
I'm aware is not something present across the majority of Unixes).

Nick

--
Real friends help you move bodies.




---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



From marius.corbu at analog.com  Fri Feb  1 17:41:52 2002
From: marius.corbu at analog.com (marius)
Date: Fri, 01 Feb 2002 14:41:52 -0800
Subject: Losing the Code War by Stephen Budiansky
Message-ID: <3C5B19B0.10B8FA15@analog.com>


"But there was an utterly trivial fix that DES users could employ if
they were worried
about security: they could simply encrypt each message twice, turning
56-bit DES into 112-bit DES, and squaring the number of key sequences
that
a code breaker would have to try. Messages could even be encrypted
thrice;
and, indeed, many financial institutions at the time were already using
"Triple DES." "

Not quite true. Encrypting each message twice would not increase the
"effective" key size to 112 bits.
There is an attack named "meet in the middle" which will make the
effective key size to be just 63 bits. This is why twice was not used
and they are using Triple DES, which has an effective key size of 112
bits.

Marius Corbu



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



From ben at algroup.co.uk  Sat Feb  2 08:57:16 2002
From: ben at algroup.co.uk (Ben Laurie)
Date: Sat, 02 Feb 2002 13:57:16 +0000
Subject: Losing the Code War by Stephen Budiansky
References: <3C5B19B0.10B8FA15@analog.com>
Message-ID: <3C5BF03C.115B9450@algroup.co.uk>

marius wrote:
> 
> "But there was an utterly trivial fix that DES users could employ if
> they were worried
> about security: they could simply encrypt each message twice, turning
> 56-bit DES into 112-bit DES, and squaring the number of key sequences
> that
> a code breaker would have to try. Messages could even be encrypted
> thrice;
> and, indeed, many financial institutions at the time were already using
> "Triple DES." "
> 
> Not quite true. Encrypting each message twice would not increase the
> "effective" key size to 112 bits.
> There is an attack named "meet in the middle" which will make the
> effective key size to be just 63 bits.

?? 56 bits "plus a little", surely.

Cheers,

Ben.

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

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



From ben at algroup.co.uk  Sat Feb  2 09:09:01 2002
From: ben at algroup.co.uk (Ben Laurie)
Date: Sat, 02 Feb 2002 14:09:01 +0000
Subject: Perdue Done (Watermarked) It (was Re: Edupage, February 1, 2002)
References: <BF80E749A362F945AB759AEF88B503C865BA23@message.educause.edu> <p05100355b8811a03076d@[10.0.1.2]>
Message-ID: <3C5BF2FD.65DD210F@algroup.co.uk>

"R. A. Hettinga" wrote:
> 
> At 5:54 PM -0700 on 2/1/02, EDUCAUSE wrote:
> 
> > DIGITAL WATERMARKING MAKES INTERNET VIDEO SPLASH
> > Purdue University researchers have found a way to ensure
> > Internet-delivered video maintains its watermark and keeps
> > channel disturbance to a minimum, protecting the content from
> > copyright infringement and hackers. Purdue professor of computer
> > engineering Edward Delp said the technique allows for
> > resynchronization at the receiving end that can decipher and
> > piece together Internet video streams that are often chopped
> > and mixed up while traveling over noisy networks. The result,
> > said Delp, is the integrity of the watermark and image, while
> > the stream is still delivered in real time. Traditional methods
> > of piecing together Internet-delivered content largely do not
> > work for audio and video, he added. The technique also helps
> > guard against hackers because of the way it controls channel
> > disturbance, and could also be used to decipher terrorist
> > messages embedded in Internet-delivered video.
> > (NewsFactor Network, 31 January 2002)

Yeah right, and it makes coffee and will prevent kiddyporn, too. Oh, did
they mention that it also does biometrics through your mouse?

Cheers,

Ben.

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

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



From rahettinga at earthlink.net  Sat Feb  2 09:49:08 2002
From: rahettinga at earthlink.net (R. A. Hettinga)
Date: Sat, 2 Feb 2002 09:49:08 -0500
Subject: Perdue Done (Watermarked) It (was Re: Edupage, February 1, 2002)
Message-ID: <p0510036bb881acd9874a@[10.0.1.2]>

At 5:54 PM -0700 on 2/1/02, EDUCAUSE wrote:


> DIGITAL WATERMARKING MAKES INTERNET VIDEO SPLASH
> Purdue University researchers have found a way to ensure
> Internet-delivered video maintains its watermark and keeps
> channel disturbance to a minimum, protecting the content from
> copyright infringement and hackers. Purdue professor of computer
> engineering Edward Delp said the technique allows for
> resynchronization at the receiving end that can decipher and
> piece together Internet video streams that are often chopped
> and mixed up while traveling over noisy networks. The result,
> said Delp, is the integrity of the watermark and image, while
> the stream is still delivered in real time. Traditional methods
> of piecing together Internet-delivered content largely do not
> work for audio and video, he added. The technique also helps
> guard against hackers because of the way it controls channel
> disturbance, and could also be used to decipher terrorist
> messages embedded in Internet-delivered video.
> (NewsFactor Network, 31 January 2002)

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



From decoy at iki.fi  Sat Feb  2 15:47:16 2002
From: decoy at iki.fi (Sampo Syreeni)
Date: Sat, 2 Feb 2002 22:47:16 +0200 (EET)
Subject: FW: update.575
In-Reply-To: <2F1A38DC0413D311A7310090273AD52704201FC5@dthrexch01>
Message-ID: <Pine.SOL.4.30.0202022242000.27835-100000@kruuna.Helsinki.FI>

On Fri, 1 Feb 2002, Kossmann, Bill wrote:

>The article below may be of interest to members of this list.
[An article on categorizing textual strings by appending them on
reference documents and measuring aggregate compressibility snipped.]

This shouldn't be a big surprise, considering how close to the estimated
entropy of various sources current compression algorithms get. In essence,
compressors are statistical learners, and classification problems can be
formulated as partitionings based on statistical similarity. I just wonder
if the overhead of doing a significant number of compression runs against
known sources isn't a bit expensive compared to current methods of
identification.

Sampo Syreeni, aka decoy - mailto:decoy at iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2




---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



From amir at beesites.co.il  Sun Feb  3 02:24:44 2002
From: amir at beesites.co.il (Amir Herzberg)
Date: Sun, 3 Feb 2002 09:24:44 +0200
Subject: Losing the Code War by Stephen Budiansky
In-Reply-To: <3C5BF03C.115B9450@algroup.co.uk>
Message-ID: <001d01c1ac83$dbe81d80$323cfea9@newgenpay>

Ben wrote: 
> marius wrote:
...
> > Not quite true. Encrypting each message twice would not increase the
> > "effective" key size to 112 bits.
> > There is an attack named "meet in the middle" which will make the
> > effective key size to be just 63 bits.
> 
> ?? 56 bits "plus a little", surely.

The `meet in the middle` attack works against double encryption; that's
why Triple DES is performing three DES operations with two keys. There
are some attacks also against using three encryptions with two keys and
against Triple DES (encryption-decryption-encryption). But the attacks I
know require huge amounts of chosen plaintext or known plaintext. In
particular with t known plaintext-ciphertext pairs, the known attack on
triple-DES requires 2^120-log(t) operations. I think most applications
can limit the amount of known plaintexts to a million; this means the
complexity of attacking triple-DES is at least 2^100, which is probably
sufficiently secure for most applications. 

Of course, using three different keys for the three DES operations (in
triple DES or simply in triple encryptions by DES) is expected to
considerably improve security. 

I think the edge of AES is mostly when improved performance (esp. in
software) is needed. 

Cheers, 

Amir Herzberg
See http://amir.beesites.co.il/book.html for lectures and notes (draft
of chapters) on `secure communication and commerce using cryptography`;
feedback welcome!






---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



From ben at algroup.co.uk  Sun Feb  3 06:56:31 2002
From: ben at algroup.co.uk (Ben Laurie)
Date: Sun, 03 Feb 2002 11:56:31 +0000
Subject: Losing the Code War by Stephen Budiansky
References: <001d01c1ac83$dbe81d80$323cfea9@newgenpay>
Message-ID: <3C5D256F.EAD095D1@algroup.co.uk>

Amir Herzberg wrote:
> The `meet in the middle` attack works against double encryption; that's
> why Triple DES is performing three DES operations with two keys.

Some variants use 3 keys, in fact.

Cheers,

Ben.

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

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



From pgut001 at cs.auckland.ac.nz  Sun Feb  3 09:09:57 2002
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Mon, 4 Feb 2002 03:09:57 +1300 (NZDT)
Subject: Welome to the Internet, here's your private key
Message-ID: <200202031409.DAA01058@ruru.cs.auckland.ac.nz>

It is accepted practice among security people that you generate your own
private key.  It is also, unfortunately, accepted practice among non-security
people that your CA generates your private key for you and then mails it to you
as a PKCS #12 file (for bonus points the password is often included in the same
or another email).  Requests to have the client generate the key themselves and
submit the public portion for certification are met with bafflement, outright
refusal, or at best grudging acceptance if they're big enough to have some
clout.  This isn't a one-off exception, this is more or less the norm for
private industry working with established (rather than internal, roll-your-own)
CAs.  This isn't the outcome of pressure from shadowy government agencies, this
is just how things are done.  Be afraid.

(I have a paper in the works which covers things like this in some detail, but
 the number of times this has come up recently is sufficiently alarming that I
 thought I'd post a heads-up here to let others who aren't exposed to this sort
 of stuff know about it.  This also doesn't begin to go into the number of CAs
 who are re-certifying the same user key over and over again, year after year
 ("We haven't been informed that it's been compromised, so it's safe to keep
 using it for another year")).

Peter.



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



From jamesd at echeque.com  Sun Feb  3 14:27:07 2002
From: jamesd at echeque.com (jamesd at echeque.com)
Date: Sun, 3 Feb 2002 11:27:07 -0800
Subject: Welome to the Internet, here's your private key
In-Reply-To: <200202031409.DAA01058@ruru.cs.auckland.ac.nz>
Message-ID: <3C5D1E8B.4178.AADD87@localhost>

    --
On 4 Feb 2002, at 3:09, Peter Gutmann wrote:
> It is accepted practice among security people that you 
> generate your own private key.  It is also, unfortunately, 
> accepted practice among non-security people that your CA 
> generates your private key for you and then mails it to you 
> as a PKCS #12 file (for bonus points the password is often 
> included in the same or another email).  Requests to have 
> the client generate the key themselves and submit the 
> public portion for certification are met with bafflement, 
> outright refusal, or at best grudging acceptance if they're 
> big enough to have some clout.  This isn't a one-off 
> exception, this is more or less the norm for private 
> industry working with established (rather than internal, 
> roll-your-own) CAs.  This isn't the outcome of pressure 
> from shadowy government agencies, this is just how things 
> are done.  Be afraid.

The public key infrastructure is simply not working.

Ordinary mortals do not understand how it works, therefore 
cannot use it correctly.

Certified public keys are therefore of limited value.

This is in part a result of an impenetrable and 
incomprehensible user interface that makes what is hard to 
understand far harder.

For example I can see no good reason why an active X control 
with public source cannot generate your private key -- so 
that as far as the normal user knows he is getting it from 
the authority by logging in to their web page.  We had this
arrangement some years ago -- what happened to it?

I just learnt that Windows 2000 and Windows XP construct a 
key pair for every user.  The interface around this seems 
designed to be utterly impenetrable, as though they were 
trying to protect against stupid users by using security by 
obscurity.

With Windows XP, we enter a world where everyone has a key 
pair securing his stuff -- and is unaware of it, and unable 
to use it. 

    --digsig
         James A. Donald
     6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
     E2AfFWpRWRrQk9TjIHVW4PIkCIefZn7D7LUkwgdH
     4144WI1nmwDQ3k7tCTyZ3dyJFywdh8RkiPnOEv0gj




---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



From sean at manybits.net  Sun Feb  3 20:00:11 2002
From: sean at manybits.net (Sean McGrath)
Date: Sun, 03 Feb 2002 17:00:11 -0800 (PST)
Subject: Unbreakable? (fwd)
Message-ID: <Pine.OSX.4.33.0202031659500.750-100000@allende.home>


---------- Forwarded message ----------
Date: Sun, 3 Feb 2002 15:49:51 -0500
From: R. A. Hettinga <rah at shipwright.com>
To: Digital Bearer Settlement List <dbs at philodox.com>, dcsb at ai.mit.edu
Subject: Unbreakable?

http://www.idg.net/crd_idgsearch_1.html?url=http://www.cio.com/archive/020102/et_development.html

UNDER DEVELOPMENT
Encryption
Unbreakable?

AS MYSTICS SEARCH for the lost island of Atlantis and UFO buffs seek out
alien spacecraft, cryptologists are continuing their own quest to create an
unbreakable code.

Michael Rabin, a Harvard University computer science professor, believes he
has moved cryptology a step closer to its Holy Grail by developing a code
that's undecipherable, even by those who have access to both the cypher
text and unlimited computing power.


Advertisers

Rabin's Hyper-Encryption technology, which uses a device that quickly
generates a deluge of random bits, relies on both time and money to thwart
even the most dedicated code breaker. A coded message would be hidden
within the bits "like raisins in a pudding," quips Rabin. While anyone can
read the random bits, the transmission rate is so high that storing all of
the stream for analysis would be either technically unfeasible or cost
prohibitive.

Hyper-Encryption has sparked the interest of several U.S. government
agencies, says Rabin. He also claims to have received inquiries from some
wealthy investors and at least one major venture capital fund. But Rabin
states he's not currently interested in the technology's commercial
potential. "Right now, commerce comes second to science," he says.

Hyper-Encryption, however, is not entirely trouble free. The chief concern
is cost, since the technology requires users to send continuous, intense
streams of high-speed data across already bandwidth-starved networks.
Rabin's solution is to create a dedicated global satellite system. "The
cost could be shared by its users," he says. In any case, Hyper-Encryption
is designed to safeguard highest-level government secrets, not routine
commercial and personal transmissions. "It's most appropriate for
protecting national interests and large sums of money," says Rabin.

Although Hyper-Encryption exists only on the blackboard, Rabin maintains
that the technology is ready for use. "There's mathematical proof the
Hyper-Encryption provides everlasting security, so there's nothing left to
do but implement it," he says.

-John Edwards

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'





---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



From rah at shipwright.com  Mon Feb  4 00:49:48 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Mon, 4 Feb 2002 00:49:48 -0500
Subject: FC: Int'v with Microsoft's Scott Charney on benefits of key escrow
Message-ID: <p05100300b883d1724be9@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Sun, 3 Feb 2002 19:06:49 -0800 (PST)
From: Declan McCullagh <declan at well.com>
To: politech at politechbot.com
Subject: FC: Int'v with Microsoft's Scott Charney on benefits of key escrow
Sender: owner-politech at politechbot.com
Reply-To: declan at well.com

Politech archive on Scott Charney:
http://www.politechbot.com/cgi-bin/politech.cgi?name=charney

---------- Forwarded message ----------
Date: Sat, 2 Feb 2002 22:47:41 -0500 (EST)
From: Charles Platt <cp at panix.com>
To: Declan McCullagh <declan at well.com>
Cc: cp at panix.com
Subject: More Charney

Declan, I believe that since I was offered an interview by a public
official, for subsequent publication, and since the magazine formally
rejected the feature and explicitly told me I could offer it elsewhere, I
have the (copy)right to offer you the following excerpts for distribution.

---

Below are a few excerpts from the interview that Scott
Charney granted when he was head of the computer crime
division of the Department of Justice. These quotes were
offered to me for publication in Wired magazine, but the
magazine chose not to use the feature. Subsequently, with Mr.
Charney's permission, I adapted some of the material for a
feature in the L. A. Times, and he made some additional
statements at that time, during a telephone interview.

I had the impression, while listening to Mr. Charney, that he
was speaking personally. I didn't get the sense that I was
receiving canned policy statements dictated via the Clinton
administration. However I must add that although Mr. Charney
saw his interview transcript shortly after the time I wrote
it (more than six years ago), he has not seen it since then,
and his personal views may have changed since then.

--Charles Platt

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

Charney on key escrow:

"if you look at the debate at cryptography, are we better off
with more privacy and less law enforcement? I think key
escrow makes a lot of sense for many reasons, not just law
enforcement reasons. We invade privacy under important
constraints such as the fourth amendement. But if a judge
says we can go into someone's home, this is to protect
society, which is a right for society at the expense of the
individual. Suppose you buy a bigger lock, we bring a bigger
sledgehammer. But cryptography is a lock so strong, society
cannot penetrate even if 1) everyone agrees it's very
important, 2) it will save many many lives, and 3) a court
has authorized it after a neutral judicial review. People
communicating about blowing up an airline--we can't
intercept, so 400 people die. There are those who say that's
the price of privacy, but you have to be able to live with
the choices you make, and I'd rather save the 400 people."

Charney on data monitoring:

"There's a concern about law enforcement engaging in illegal
wiretaps, and there's no doubt you can find cases in history
to justify that concern. But there's no evidence for
systematic abuse of that process. I'd rather think that if a
judge orders access to data and it satisfies the fourth
amendement test, it should be permitted."

Charney's computer background:

"I was programming in Cobol when I was eight. My father went
to MIT and got into computers in the vacuum tube days. Then
he worked for Seligman[?], mutual fund co on Wall Street, he
wrote one of the first programs for processing mutual fund
checks by computer. He had me writing flow charts, then do
the punch cards, go into the air conditioned room with a
Honeywell computer, we'd process the cards. So I had a long
informal history with computers."

"I had a PC relatively early on. The first machine was XT
class. And I program as a hobby, for the department, mostly
in FoxPro, dBASE IV. I've toyed with C but I don't have the
time."

Charney on influencing the evolution of net culture:

"It's fun to be a part of it and have some small impact on
what the future's going to look like and whether we're going
to like it. The players include civil libertarians,
academics, policy makers--and law enforcement is an important
part of that. You only have to look at the front cover of
Time magazine to wonder if criminal law is going to drive the
internet. The answer is, it should not. The goal is to
minimize harm but allow the benefits to be maximized."

"I think it's really important that we find ways to protect
children, but not paint with such a broad brush that we chill
the use of the net. Computer crime is a very important thing.
If people abuse the networks, that's trouble. But you don't
want networks in the next century to be driven by the
computer crime issue. There's so many social benefits in the
net, the democratizing factor, the free speech factor, we
need to preserve those benefits while minizing the harm."

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





-------------------------------------------------------------------------
POLITECH -- Declan McCullagh's politics and technology mailing list
You may redistribute this message freely if you include this notice.
Declan McCullagh's photographs are at http://www.mccullagh.org/
To subscribe to Politech: http://www.politechbot.com/info/subscribe.html
This message is archived at http://www.politechbot.com/
-------------------------------------------------------------------------
Events: Congreso Nacional de Periodismo Digital in Huesca, Spain from
Jan. 17-18 (http://www.congresoperiodismo.com) and the Second
International Conference on Web-Management in Diplomacy in Malta from
Feb. 1-3. (http://www.diplomacy.edu/Web/conference2/)
-------------------------------------------------------------------------

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ncb at pobox.com  Mon Feb  4 01:47:30 2002
From: ncb at pobox.com (Nicholas Brawn)
Date: Mon, 4 Feb 2002 17:47:30 +1100
Subject: Unbreakable? (fwd)
In-Reply-To: <Pine.OSX.4.33.0202031659500.750-100000@allende.home>
Message-ID: <0F550573-193B-11D6-9998-000393471DA8@pobox.com>

Correct me if I'm wrong, but isn't such a system feasible by:

1. Having the network infrastructure available to support the continuous 
traffic loads.
2. Having a suitable RNG source that can cope with the reseeding/etc 
requirements of encrypting bulk data.
3. Having a mechanism to insert genuine information into these massive 
streams of data.

I suppose the issue is communicating to the third party which part of 
the data contains the interesting stuff. From what Rabin is saying, it 
appears that the increased security is achieved by the third party not 
knowing what is important and what isn't. How you communicate this with 
your trusted third party is the problem. You can't simply send a 
transmission when a new section of interesting stuff is coming through, 
because then the evil folk can simply watch for the notification, then 
capture that section of the traffic.

Perhaps you could send a transmission that says "in x bytes time for the 
next x bytes, is the next message". That would include some latency that 
the evil third party can't reliably interperet. But does that work for 
frequent transmissions?

Seems interesting nevertheless.

Nick

--
Real friends help you move bodies.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Mon Feb  4 08:34:40 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Mon, 4 Feb 2002 08:34:40 -0500
Subject: [ISN] Microsoft taps former DOJ cybercop for top security slot
Message-ID: <p05100305b8843e64e49c@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Mon, 4 Feb 2002 00:29:30 -0600 (CST)
From: InfoSec News <isn at c4i.org>
To: isn at attrition.org
Subject: [ISN] Microsoft taps former DOJ cybercop for top security slot
Sender: owner-isn at attrition.org
Reply-To: InfoSec News <isn at c4i.org>

http://www.computerworld.com/storyba/0,4125,NAV47_STO67871,00.html

By Dan Verton and Deborah Radcliff
Jan. 31, 2002

Computerworld has learned that Microsoft Corp. plans to name Scott
Charney, the former chief of computer crime at the U.S. Department of
Justice (DOJ) and a partner at New York-based PricewaterhouseCoopers,
as its new chief security strategist. He replaces Howard Schmidt, who
left the company on Jan. 28 to join the Bush administration (see
story).

Charney confirmed his appointment in a telephone interview this
morning. He assumes his new position on April 1.

The change in title from chief security officer to chief security
strategist does not indicate a major shift in responsibilities, said
Charney. Rather, it's "actually a more accurate description of the
role Howard had been filling," he said. "I will be working to secure
products and services and developing domestic and international
polices that support a more secure infrastructure."

Microsoft officials declined to comment on the appointment this
morning.

Sources close to the interview process said that while they wouldn't
necessarily place Charney on the short list of top IT security experts
in the country, he landed the job because of his long career at the
DOJ, where he earned a reputation as a skilled and staunch
antihacking, cybercrime hardliner.

"I realized that [one Microsoft executive] in particular was looking
for someone with significant [government] ties and current contacts,"
said a source close to the selection process. Microsoft "saw Howard
[Schmidt] as unique and wanted to define the position around their
real needs and the strengths of the new [executive]."

Schmidt left Microsoft to become vice chairman of the President's
Critical Infrastructure Protection Board and is admired by many
throughout industry and government for having a rare combination of
technical and interpersonal skills, especially on Capitol Hill.

However, the job search for a new security strategist hasn't gone as
smoothly as the company would have liked, said a senior Microsoft
executive, speaking on condition of anonymity.

"It's hard to find somebody who knows the technology and has a little
bit of business sense and can talk to people on Capitol Hill," said
the executive. Senior officials at Microsoft viewed many of the
candidates that applied for Schmidt's position as being good at one
aspect of the job but not others, the executive said.

Eric Friedberg, a former computer crimes coordinator at the DOJ who
reported to Charney indirectly, called him one of the "shining lights"
in information security. "He's got national credibility," said
Friedberg, who credited Charney with developing the DOJ's computer
crime and intellectual property division. "He is responsible for
building the federal prosecutorial infrastructure for computer crimes
cases."

Alan Paller, research director at the SANS Institute in Bethesda, Md.,
said Charney is the best candidate to carry on Schmidt's Trusted
Computing initiative -- not because of his technical background but
because of his experience at the DOJ.

"Remember the job [Charney] has to do. He has to get marketing-driven
development people to delay, assess and correct their tools so they do
not cause harm to the outside world," Paller said. "[Charney] is
probably the best guy in the country to pull that off, because he
comes from the purest understanding of the damage that the bad guys
do. What a brilliant choice, because you have to prove to some very
strong-willed people that it's worth doing this right. And who better
than someone who's been in the heat of the battles of computer crime?"

An executive said that Microsoft founder Bill Gates and CEO Steve
Ballmer had considered restructuring the company's security
organization in the aftermath of Schmidt's departure. One option on
the table included hiring two executives to fill the slot, with one
individual focusing strictly on product architecture and the other
taking responsibility for business strategy as well as physical and
executive security.

According to the executive, Schmidt approached Gates and Ballmer last
year with a proposal to change the role of chief security officer from
one involving oversight of both product and physical security,
including executive protection, to strictly product development.
Although Ballmer initially balked at the idea, Gates eventually agreed
to the proposal and Schmidt shed his physical security
responsibilities, the executive said.

A source with ties to the interview process who asked that his name
not be disclosed confirmed that "the issue of placement and emphasis"
was a primary topic of discussion within Microsoft. However, there
were no indications, the source said, that Gates and Ballmer were in
disagreement.

Charney, who holds degrees in English and history, also considers
himself "more technical than your average lawyer for sure." However,
Charney, the son of a systems administrator who started programming in
Cobol when he was eight, acknowledges that he is "not a
Microsoft-level technologist."

On the technical side, Charney will be supported by a small but elite
team, Paller said. This team includes Eric Schultz, co-author of
Hacking Exposed, David LeBlanc, a Windows security expert formerly
with Internet Security Systems Inc., and Jasper Johansen, a former
SANS faculty member.



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo at attrition.org with 'unsubscribe isn' in the BODY
of the mail.

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From hoepman at cs.utwente.nl  Mon Feb  4 08:45:28 2002
From: hoepman at cs.utwente.nl (Jaap-Henk Hoepman)
Date: 04 Feb 2002 14:45:28 +0100
Subject: Welome to the Internet, here's your private key
In-Reply-To: <200202031409.DAA01058@ruru.cs.auckland.ac.nz>
References: <200202031409.DAA01058@ruru.cs.auckland.ac.nz>
Message-ID: <wuxt1htz.fsf@smtp.xs4all.nl>


It's worse: it's even accepted practice among certain security specialists. One
of them involved in the development of a CA service once told me that they
intended the CA to generate the key pair. After regaining consciousness I asked
him why he thought violating one of the main principles of public key
cryptography was a good idea. His answer basically ran as follows: if the CA is
going to be liable, they want to be sure the key is strong and not
compromised. He said that the PC platform of an ordinary user simply wasn't
secure/trusted enough to generate keys on. The system might not generate `good
enough' randomness, or might have been compromised by a trojan.

Jaap-Henk

On Sun, 3 Feb 2002 15:09:57 +0100  pgut001 at cs.auckland.ac.nz writes:
> It is accepted practice among security people that you generate your own
> private key.  It is also, unfortunately, accepted practice among non-security
> people that your CA generates your private key for you and then mails it to
> you as a PKCS #12 file (for bonus points the password is often included in
> the same or another email).  Requests to have the client generate the key
> themselves and submit the public portion for certification are met with
> bafflement, outright refusal, or at best grudging acceptance if they're big
> enough to have some clout.  This isn't a one-off exception, this is more or
> less the norm for private industry working with established (rather than
> internal, roll-your-own) CAs.  This isn't the outcome of pressure from
> shadowy government agencies, this is just how things are done.  Be afraid.
> 

-- 
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn your bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman at cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ptrei at rsasecurity.com  Mon Feb  4 11:00:27 2002
From: ptrei at rsasecurity.com (Trei, Peter)
Date: Mon, 4 Feb 2002 11:00:27 -0500 
Subject: Losing the Code War by Stephen Budiansky
Message-ID: <F504A8CEE925D411AF4A00508B8BE90A01E90C03@exna07.securitydynamics.com>

I read the article (in the dead tree edition), and despite it's
technical inaccuracies, thought it was generally 
pretty good.

Don't forget that the MITM attack (which Schneier claims
takes 2^(2n) = 2^112 time), also requires 2^56 blocks
of storage. That's a lot, and the attack ceases to be
parallelizable, unlike the straight brute-force attack.
In fact, it's utterly intractable at the moment. Here's
why:

2^56 bytes = 72 petabytes, and
I suspect you'd need 8 bytes per entry, or 
about 1/2 an exabyte. 

By contrast, all of morpheus is currently less than 
half of one petabyte. Google indexes about 3 billion
documents + 700 million usenet postings. At a
an estimated 100kb per item, that's roughly
the same as morpheus. 

I don't lose sleep over MITM attacks on 3DES.

Peter Trei

> ----------
> From: 	Ben Laurie[SMTP:ben at algroup.co.uk]
> Sent: 	Saturday, February 02, 2002 8:57 AM
> To: 	marius
> Cc: 	cryptography at wasabisystems.com
> Subject: 	Re: Losing the Code War by Stephen Budiansky
> 
> marius wrote:
> > 
> > "But there was an utterly trivial fix that DES users could employ if
> > they were worried
> > about security: they could simply encrypt each message twice, turning
> > 56-bit DES into 112-bit DES, and squaring the number of key sequences
> > that
> > a code breaker would have to try. Messages could even be encrypted
> > thrice;
> > and, indeed, many financial institutions at the time were already using
> > "Triple DES." "
> > 
> > Not quite true. Encrypting each message twice would not increase the
> > "effective" key size to 112 bits.
> > There is an attack named "meet in the middle" which will make the
> > effective key size to be just 63 bits.
> 
> ?? 56 bits "plus a little", surely.
> 
> Cheers,
> 
> Ben.
> 
> --
> http://www.apache-ssl.org/ben.html       http://www.thebunker.net/
> 
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
> 
> 
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
> majordomo at wasabisystems.com
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ptrei at rsasecurity.com  Mon Feb  4 11:13:10 2002
From: ptrei at rsasecurity.com (Trei, Peter)
Date: Mon, 4 Feb 2002 11:13:10 -0500 
Subject: Welome to the Internet, here's your private key
Message-ID: <F504A8CEE925D411AF4A00508B8BE90A01E90C05@exna07.securitydynamics.com>

One other scheme I've seen, and which, while it doesn't give me
warm fuzzies, seems reasonable, is to issue the
the enduser a smartcard with a keypair on it. The SC generates
the pair onboard, and exports only the public half. The private
half never leaves the SC (there is no function on the card to 
export it).

If you trust the above, then the only copy of the private key
is on the SC, despite it having been generated without the
end users participation.

Peter

> ----------
> From: 	Jaap-Henk Hoepman[SMTP:hoepman at cs.utwente.nl]
> Sent: 	Monday, February 04, 2002 8:45 AM
> To: 	cryptography at wasabisystems.com
> Subject: 	Re: Welome to the Internet, here's your private key
> 
> 
> It's worse: it's even accepted practice among certain security
> specialists. One
> of them involved in the development of a CA service once told me that they
> intended the CA to generate the key pair. After regaining consciousness I
> asked
> him why he thought violating one of the main principles of public key
> cryptography was a good idea. His answer basically ran as follows: if the
> CA is
> going to be liable, they want to be sure the key is strong and not
> compromised. He said that the PC platform of an ordinary user simply
> wasn't
> secure/trusted enough to generate keys on. The system might not generate
> `good
> enough' randomness, or might have been compromised by a trojan.
> 
> Jaap-Henk
> 
> On Sun, 3 Feb 2002 15:09:57 +0100  pgut001 at cs.auckland.ac.nz writes:
> > It is accepted practice among security people that you generate your own
> > private key.  It is also, unfortunately, accepted practice among
> non-security
> > people that your CA generates your private key for you and then mails it
> to
> > you as a PKCS #12 file (for bonus points the password is often included
> in
> > the same or another email).  Requests to have the client generate the
> key
> > themselves and submit the public portion for certification are met with
> > bafflement, outright refusal, or at best grudging acceptance if they're
> big
> > enough to have some clout.  This isn't a one-off exception, this is more
> or
> > less the norm for private industry working with established (rather than
> > internal, roll-your-own) CAs.  This isn't the outcome of pressure from
> > shadowy government agencies, this is just how things are done.  Be
> afraid.
> > 
> 
> -- 
> Jaap-Henk Hoepman             | Come sail your ships around me
> Dept. of Computer Science     | And burn your bridges down
> University of Twente          |       Nick Cave - "Ship Song"
> Email: hoepman at cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
> Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
> PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF
> 
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
> majordomo at wasabisystems.com
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From jeroen at vangelderen.org  Mon Feb  4 11:43:12 2002
From: jeroen at vangelderen.org (Jeroen C.van Gelderen)
Date: Mon, 4 Feb 2002 11:43:12 -0500
Subject: Welome to the Internet, here's your private key
In-Reply-To: <wuxt1htz.fsf@smtp.xs4all.nl>
Message-ID: <47C18322-198E-11D6-8F7A-00306580B1CA@vangelderen.org>


You sound surprised? I recently asked my bank[1] for a solvency 
statement on a personal account and they responded that they were not 
allowed to provide such statements. When pressed for an explanation I 
was told that handing out those statements caused them too much 
litigation. Apparently when the bank states that
   "Alice has been a customer since 23-01-1980 and as of
    12-12-1999 her account is in good standing."
they can (and have indeed been) be sued when Alice goes bankrupt in 
2002. This despite the fact that the statement obviously does not make 
any claim about Alice in 2002. Now, the bank may very well win the court 
case, or they may not. Whatever the outcome, it will cost them.

The moral of the story is: when the legal system allows for silly cases 
like this, alternative protective measures[2] will be put in place, such 
as not handing out solvency statements[3], or forcing a user to accept a 
CA-generated private key. The problem here is not with the technical 
competence of the CA but rather with the CA being held liable and being 
forced to mitigate the risk of losing lots of money.

Technically speaking, having the CA generate the private keys allows the 
user to repudiate signatures made with the key. After all, the CA (or 
one of its employees) could have leaked the key or have signed stuff 
with it.

Practically speaking this would probably be solved by passing an 
additional law that declares CAs trustworthy by definition. After all, 
if you don't pass such a law, the PKI cannot work in the current legal 
framework. And CAs are run by the good people, right? What is wrong with 
effective key escrow for signature keys!? ;-p

We do not even want to think about the conflicts of interest: what 
incentive is there for a CA to report that it lost a user's private key?

-J

[1]  ABN-AMRO.

[2]  Alternative because the legal system is supposed to protect the 
honest
      party here but obviously fails.

[3]  The bank does have provisions for providing solvency statements on
      business accounts. They have insurance and make you pay 
(indirectly).


On Monday, February 4, 2002, at 08:45 , Jaap-Henk Hoepman wrote:

>
> It's worse: it's even accepted practice among certain security 
> specialists. One
> of them involved in the development of a CA service once told me that 
> they
> intended the CA to generate the key pair. After regaining consciousness 
> I asked
> him why he thought violating one of the main principles of public key
> cryptography was a good idea. His answer basically ran as follows: if 
> the CA is
> going to be liable, they want to be sure the key is strong and not
> compromised. He said that the PC platform of an ordinary user simply 
> wasn't
> secure/trusted enough to generate keys on. The system might not 
> generate `good
> enough' randomness, or might have been compromised by a trojan.
>
> Jaap-Henk
>
> On Sun, 3 Feb 2002 15:09:57 +0100  pgut001 at cs.auckland.ac.nz writes:
>> It is accepted practice among security people that you generate your 
>> own
>> private key.  It is also, unfortunately, accepted practice among 
>> non-security
>> people that your CA generates your private key for you and then mails 
>> it to
>> you as a PKCS #12 file (for bonus points the password is often 
>> included in
>> the same or another email).  Requests to have the client generate the 
>> key
>> themselves and submit the public portion for certification are met with
>> bafflement, outright refusal, or at best grudging acceptance if 
>> they're big
>> enough to have some clout.  This isn't a one-off exception, this is 
>> more or
>> less the norm for private industry working with established (rather 
>> than
>> internal, roll-your-own) CAs.  This isn't the outcome of pressure from
>> shadowy government agencies, this is just how things are done.  Be 
>> afraid.
>>
>
> --
> Jaap-Henk Hoepman             | Come sail your ships around me
> Dept. of Computer Science     | And burn your bridges down
> University of Twente          |       Nick Cave - "Ship Song"
> Email: hoepman at cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
> Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
> PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 
> ABEF
>
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to 
> majordomo at wasabisystems.com
>
>
--
Jeroen C. van Gelderen - jeroen at vangelderen.org

"Economics is a theoretical science and as such abstains from any
judgement of value. It is not its task to tell people what ends
they should aim at. It is a science of the means to be applied for
attainment of ends chosen, not, to be sure, a science of the choosing
of ends. Ultimate decisions, the valuations and the choosing of ends,
are beyond the scope of any science. Science never tells a man how
he should act; it merely shows how a man must act if he wants to
attain definite ends." -- Ludwig von Mises


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From lynn.wheeler at firstdata.com  Mon Feb  4 11:53:52 2002
From: lynn.wheeler at firstdata.com (lynn.wheeler at firstdata.com)
Date: Mon, 4 Feb 2002 09:53:52 -0700
Subject: Welome to the Internet, here's your private key
Message-ID: <OF1401959B.9B765834-ON87256B56.005B6A5F@internet.ny.fdms.firstdata.com>


ignoring for the moment the question of why certificates would be needed at
all ....

then public/private key technology is currently being used for (at least)
two distinct & different business processes

1) authentication
2) encryption

The business process of human person authentication has some requirements
about impersonation ... leading to a business requirement that only the
person being authenticated should have access to the authentication
material (aka only the specific person can originate an authenticated
transaction). A hardware token that generates the key-pair inside the token
and the private key can never leave the token can satisfy unique person
authentication thru one-factor authentication "something you have". The
person is the only one with their specific token and that token is the only
container for their specific private key.

The business process for encryption can be totally different. The assets
being encrypted may be corporate assets, not the individuals. In the case
of using public/private key in conjunction with encryption of corporate
assets, the business requirements totally change. The corporation has a
valid requirement for recoverying valuable corporate assets under any
condition (failure/loss of token, person leaves the company, etc).

In the person authentication case, the impersonation issue typically is
viewed as outweighing the failure/loss of token issue. In the case of
encryption of corporate assets, the failure/loss of the token issue would
typically outweight any issues of guarenteeing absolutely that the key can
only occur in a single place not knonw by anybody.

The requirement for a private key only existing in a single place under
control of a single person isn't an attribute of the public/private key
technology .... it is an attribute of a specific business process and
associated business requirements related to that business process. However,
there are other business process applications for public/private key
technology than human person authentication which can have somewhat
different requirements.

aads chip strawman .... public/private key hardware token w/o any
certificates
http://www.garlic.com/~lynn/index.html#aads

random refs:
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk
Management and Information Security
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12 A PKI Question: PKCS11->
PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11->
PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12d A PKI Question: PKCS11->
PKCS12
http://www.garlic.com/~lynn/aadsm10.htm#diskcrypt Looking back ten years:
Another Cypherpunks failure (fwd)
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001n.html#54 The demise of compaq
http://www.garlic.com/~lynn/2002.html#7 The demise of compaq




ptrei at rsasecurity.com on 2/4/2002 9:13 am wrote:


One other scheme I've seen, and which, while it doesn't give me
warm fuzzies, seems reasonable, is to issue the
the enduser a smartcard with a keypair on it. The SC generates
the pair onboard, and exports only the public half. The private
half never leaves the SC (there is no function on the card to
export it).

If you trust the above, then the only copy of the private key
is on the SC, despite it having been generated without the
end users participation.

Peter





---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From iang at abraham.cs.berkeley.edu  Mon Feb  4 12:30:52 2002
From: iang at abraham.cs.berkeley.edu (Ian Goldberg)
Date: 4 Feb 2002 17:30:52 GMT
Subject: CFS vs. loopback encryption (was Re: [open-source] File encryption)
References: <Pine.OSF.4.10.10201300450160.5755-100000@alpha.hut.fi> <56A53A20-175F-11D6-9052-000393471DA8@pobox.com>
Message-ID: <a3mggc$9ke$1@abraham.cs.berkeley.edu>

In article <56A53A20-175F-11D6-9052-000393471DA8 at pobox.com>,
Nicholas Brawn  <ncb at pobox.com> wrote:
>What are people's thoughts on CFS vs. loopback encryption? I've used CFS 
>in the past and found it quite useful, though as Matt said - a little 
>long in the tooth. Never really looked into loopback encryption (which 
>I'm aware is not something present across the majority of Unixes).

I use loopback encryption on Linux (loop-aes.sourceforge.net).
I'm very happy with it.  I have it encrypting data with a passphrase
and swap with a random key.

   - Ian

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From josh at untruth.org  Mon Feb  4 12:38:16 2002
From: josh at untruth.org (Joshua Hill)
Date: Mon, 4 Feb 2002 09:38:16 -0800
Subject: Losing the Code War by Stephen Budiansky
In-Reply-To: <F504A8CEE925D411AF4A00508B8BE90A01E90C03@exna07.securitydynamics.com>; from ptrei@rsasecurity.com on Mon, Feb 04, 2002 at 11:00:27AM -0500
References: <F504A8CEE925D411AF4A00508B8BE90A01E90C03@exna07.securitydynamics.com>
Message-ID: <20020204093816.A12537@delusion.private.untruth.org>

marius wrote:
> Not quite true. Encrypting each message twice would not increase the
> "effective" key size to 112 bits.
> There is an attack named "meet in the middle" which will make the
> effective key size to be just 63 bits.

Peter Trei wrote:
> Don't forget that the MITM attack (which Schneier claims
> takes 2^(2n) = 2^112 time), also requires 2^56 blocks
> of storage.
[...]
> I don't lose sleep over MITM attacks on 3DES.

Unless I'm mistaken, the 2^63 operation MITM attack referenced in the
original message referred to Double-DES, not Triple-DES.  The original
cited value of 2^63 is incorrect; the Double-DES MITM attack (as proposed
by Merkle and Hellman) is a known plaintext attack that takes 2^57
operations, with 2^56 blocks of storage.

Your provided values are correct for attacking Triple-DES, but I don't
think that's what the original author was referring to.

				Josh

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ptrei at rsasecurity.com  Mon Feb  4 12:50:43 2002
From: ptrei at rsasecurity.com (Trei, Peter)
Date: Mon, 4 Feb 2002 12:50:43 -0500 
Subject: Losing the Code War by Stephen Budiansky
Message-ID: <F504A8CEE925D411AF4A00508B8BE90A01E90C07@exna07.securitydynamics.com>

> Joshua Hill[SMTP:josh at untruth.org] wrote:
> 
> 
> marius wrote:
> > Not quite true. Encrypting each message twice would not increase the
> > "effective" key size to 112 bits.
> > There is an attack named "meet in the middle" which will make the
> > effective key size to be just 63 bits.
> 
> Peter Trei wrote:
> > Don't forget that the MITM attack (which Schneier claims
> > takes 2^(2n) = 2^112 time), also requires 2^56 blocks
> > of storage.
> [...]
> > I don't lose sleep over MITM attacks on 3DES.
> 
> Unless I'm mistaken, the 2^63 operation MITM attack referenced in the
> original message referred to Double-DES, not Triple-DES.  The original
> cited value of 2^63 is incorrect; the Double-DES MITM attack (as proposed
> by Merkle and Hellman) is a known plaintext attack that takes 2^57
> operations, with 2^56 blocks of storage.
> 
> Your provided values are correct for attacking Triple-DES, but I don't
> think that's what the original author was referring to.
> 
> 				Josh
> 
Either way, my point stands: any attack which requires 2^56 blocks
of storage is probably intractable for the time being, imho. 10 years
from now, I'm not so sure.

Peter Trei


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From jim at acm.org  Mon Feb  4 13:02:58 2002
From: jim at acm.org (Jim Gillogly)
Date: Mon, 04 Feb 2002 10:02:58 -0800
Subject: Losing the Code War by Stephen Budiansky
References: <F504A8CEE925D411AF4A00508B8BE90A01E90C03@exna07.securitydynamics.com> <20020204093816.A12537@delusion.private.untruth.org>
Message-ID: <3C5ECCD2.95E81B8D@acm.org>

Joshua Hill wrote:
> 
> marius wrote:
> > Not quite true. Encrypting each message twice would not increase the
> > "effective" key size to 112 bits.
> > There is an attack named "meet in the middle" which will make the
> > effective key size to be just 63 bits.
> 
> Peter Trei wrote:
> > Don't forget that the MITM attack (which Schneier claims
> > takes 2^(2n) = 2^112 time), also requires 2^56 blocks
> > of storage.
> [...]
> > I don't lose sleep over MITM attacks on 3DES.
> 
> Unless I'm mistaken, the 2^63 operation MITM attack referenced in the
> original message referred to Double-DES, not Triple-DES.  The original
> cited value of 2^63 is incorrect; the Double-DES MITM attack (as proposed
> by Merkle and Hellman) is a known plaintext attack that takes 2^57
> operations, with 2^56 blocks of storage.
> 
> Your provided values are correct for attacking Triple-DES, but I don't
> think that's what the original author was referring to.

Since 2^56 blocks of storage is borderline ridiculous, van Oorschot and
Wiener did a nice paper in Journal of Cryptology in 1999 that shows how
to do the time-memory tradeoff.  For 2^40 blocks of storage it takes about
2^72 operations for 2DES.  The equivalent 3DES attack costs closer to 2^175
with reasonable storage requirements.
-- 
	Jim Gillogly
	14 Solmath S.R. 2002, 17:59
	12.19.8.17.5, 7 Chicchan 3 Pax, Third Lord of Night

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ptrei at rsasecurity.com  Mon Feb  4 13:16:35 2002
From: ptrei at rsasecurity.com (Trei, Peter)
Date: Mon, 4 Feb 2002 13:16:35 -0500 
Subject: Unbreakable? (fwd)
Message-ID: <F504A8CEE925D411AF4A00508B8BE90A01E90C08@exna07.securitydynamics.com>

There are plenty of 'thought experiment' crypto systems which
are utterly infeasible in practice. Rabin's is one.

It does have perfect forward secrecy in that if Eve doesn't know 
ahead of transmission time what part of the keystream to grab,
she can't later decrypt the message.

But, as Nicholas points out, it doesn't solve the key distribution problem,
merely shifts it. Alice and Bob still have find some way to securely
coordinate beforehand what part of the 'random' bitstream they will
use as their OTP.

There are many other problems:

* The HW needed to generate cryptographically sound random data 
at the required rate is extremely expensive, if it exists at all. 

* The HW needed to recieve data at that rate is very expensive. 

* Since accuracy is required, error correcting codes will have to
be included, increasing the data rate still further.

*putting up a constellation of satellites is also very expensive - 
where's the revenue to do all this coming from?

...and the big one:

Could you *trust* the 'randomness' of a bitstream handed you
from a source you cannot check?

Sorry, folks, this one is a non-starter.

Peter Trei



> ----------
> From: 	Nicholas Brawn[SMTP:ncb at pobox.com]
> Sent: 	Monday, February 04, 2002 1:47 AM
> To: 	Sean McGrath
> Cc: 	cryptography at wasabisystems.com
> Subject: 	Re: Unbreakable? (fwd)
> 
> Correct me if I'm wrong, but isn't such a system feasible by:
> 
> 1. Having the network infrastructure available to support the continuous 
> traffic loads.
> 2. Having a suitable RNG source that can cope with the reseeding/etc 
> requirements of encrypting bulk data.
> 3. Having a mechanism to insert genuine information into these massive 
> streams of data.
> 
> I suppose the issue is communicating to the third party which part of 
> the data contains the interesting stuff. From what Rabin is saying, it 
> appears that the increased security is achieved by the third party not 
> knowing what is important and what isn't. How you communicate this with 
> your trusted third party is the problem. You can't simply send a 
> transmission when a new section of interesting stuff is coming through, 
> because then the evil folk can simply watch for the notification, then 
> capture that section of the traffic.
> 
> Perhaps you could send a transmission that says "in x bytes time for the 
> next x bytes, is the next message". That would include some latency that 
> the evil third party can't reliably interperet. But does that work for 
> frequent transmissions?
> 
> Seems interesting nevertheless.
> 
> Nick
> 
> --
> Real friends help you move bodies.
> 
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
> majordomo at wasabisystems.com
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From bill.stewart at pobox.com  Mon Feb  4 13:20:58 2002
From: bill.stewart at pobox.com (Bill Stewart)
Date: Mon, 04 Feb 2002 10:20:58 -0800
Subject: Welome to the Internet, here's your private key
In-Reply-To: <F504A8CEE925D411AF4A00508B8BE90A01E90C05@exna07.securitydy
 namics.com>
Message-ID: <5.0.2.1.1.20020204100214.030b6280@idiom.com>

 > From: 	Jaap-Henk Hoepman[SMTP:hoepman at cs.utwente.nl]
 >
 > It's worse: it's even accepted practice among certain security
 > specialists. One of them involved in the development of a CA service
 > once told me that they intended the CA to generate the key pair.
 > After regaining consciousness I asked him why he thought
 > violating one of the main principles of public key
 > cryptography was a good idea. His answer basically ran as follows:
 > if the CA is going to be liable, they want to be sure the key is strong
 > and not compromised. He said that the PC platform of an ordinary user
 > simply wasn't secure/trusted enough to generate keys on.
 > The system might not generate `good enough' randomness,
 > or might have been compromised by a trojan.

If the system is compromised by a trojan, then the user is
already toast, and storing the private key on the machine
is just as dangerous as generating it there.
Giving the user a smartcard to run everything on,
as Peter Trei suggested, is a partial fix, though a sufficiently
targeted trojan may be able to trick the smartcard into
signing or decrypting things that it shouldn't.

Randomness quality could be a genuine issue.  The solution to that
is not to give the user the key - it's to give the user a string
of officially strong random numbers and have them type that in
to the key generator along with waving their mouse and
other randomness generation techniques, and the risks from
compromise if somebody eavesdrops on the transmission of the
random number are much less serious than eavesdropping on the key.

There are special cases where the user's machine doesn't have
the CPU horsepower to generate a key - PCs are fine,
but perhaps Palm Pilots and similar handhelds are too slow
(though a typical slow 33MHz 68000 or Dragonball is faster
than the 8086/80286 MSDOS machines that PGP originally ran on.)
Cash machines may be too slow, but they normally run symmetric crypto.
A smartcard-only system probably _is_ too limited to generate keys,
but that's the only realistic case I see.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ben at algroup.co.uk  Mon Feb  4 13:23:10 2002
From: ben at algroup.co.uk (Ben Laurie)
Date: Mon, 04 Feb 2002 18:23:10 +0000
Subject: Unbreakable? (fwd)
References: <Pine.OSX.4.33.0202031659500.750-100000@allende.home>
Message-ID: <3C5ED18E.400260A8@algroup.co.uk>

This suffers from the same flaw as the last proposal: the security lies
in the idea that you can't store the data for long enough to be able to
decrypt the message that says where in the bitstream your data is.
However, this is defeatable by a delay line of sufficient length, just
like the last idea (where, if you remember, the keying material was in
the fast random stream instead).

Cheers,

Ben.

Sean McGrath wrote:
> 
> ---------- Forwarded message ----------
> Date: Sun, 3 Feb 2002 15:49:51 -0500
> From: R. A. Hettinga <rah at shipwright.com>
> To: Digital Bearer Settlement List <dbs at philodox.com>, dcsb at ai.mit.edu
> Subject: Unbreakable?
> 
> http://www.idg.net/crd_idgsearch_1.html?url=http://www.cio.com/archive/020102/et_development.html
> 
> UNDER DEVELOPMENT
> Encryption
> Unbreakable?
> 
> AS MYSTICS SEARCH for the lost island of Atlantis and UFO buffs seek out
> alien spacecraft, cryptologists are continuing their own quest to create an
> unbreakable code.
> 
> Michael Rabin, a Harvard University computer science professor, believes he
> has moved cryptology a step closer to its Holy Grail by developing a code
> that's undecipherable, even by those who have access to both the cypher
> text and unlimited computing power.
> 
> Advertisers
> 
> Rabin's Hyper-Encryption technology, which uses a device that quickly
> generates a deluge of random bits, relies on both time and money to thwart
> even the most dedicated code breaker. A coded message would be hidden
> within the bits "like raisins in a pudding," quips Rabin. While anyone can
> read the random bits, the transmission rate is so high that storing all of
> the stream for analysis would be either technically unfeasible or cost
> prohibitive.
> 
> Hyper-Encryption has sparked the interest of several U.S. government
> agencies, says Rabin. He also claims to have received inquiries from some
> wealthy investors and at least one major venture capital fund. But Rabin
> states he's not currently interested in the technology's commercial
> potential. "Right now, commerce comes second to science," he says.
> 
> Hyper-Encryption, however, is not entirely trouble free. The chief concern
> is cost, since the technology requires users to send continuous, intense
> streams of high-speed data across already bandwidth-starved networks.
> Rabin's solution is to create a dedicated global satellite system. "The
> cost could be shared by its users," he says. In any case, Hyper-Encryption
> is designed to safeguard highest-level government secrets, not routine
> commercial and personal transmissions. "It's most appropriate for
> protecting national interests and large sums of money," says Rabin.
> 
> Although Hyper-Encryption exists only on the blackboard, Rabin maintains
> that the technology is ready for use. "There's mathematical proof the
> Hyper-Encryption provides everlasting security, so there's nothing left to
> do but implement it," he says.
> 
> -John Edwards
> 
> --
> -----------------
> R. A. Hettinga <mailto: rah at ibuc.com>
> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
> 44 Farquhar Street, Boston, MA 02131 USA
> "... however it may deserve respect for its usefulness and antiquity,
> [predicting the end of the world] has not been found agreeable to
> experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com

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

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From frantz at pwpconsult.com  Mon Feb  4 15:41:43 2002
From: frantz at pwpconsult.com (Bill Frantz)
Date: Mon, 4 Feb 2002 12:41:43 -0800
Subject: Welome to the Internet, here's your private key
In-Reply-To: <5.0.2.1.1.20020204100214.030b6280@idiom.com>
References: <F504A8CEE925D411AF4A00508B8BE90A01E90C05@exna07.securitydy
 namics.com>
Message-ID: <v0311070fb884a20d47ce@[209.86.1.241]>

At 10:20 AM -0800 2/4/02, Bill Stewart wrote:
>There are special cases where the user's machine doesn't have
>the CPU horsepower to generate a key - PCs are fine,
>but perhaps Palm Pilots and similar handhelds are too slow
>(though a typical slow 33MHz 68000 or Dragonball is faster
>than the 8086/80286 MSDOS machines that PGP originally ran on.)
>Cash machines may be too slow, but they normally run symmetric crypto.
>A smartcard-only system probably _is_ too limited to generate keys,
>but that's the only realistic case I see.

It may depend on the public key system you are using.  Where you have to
search for numbers which have certain mathematical properties (like with
RSA), then you can indeed use a bunch of CPU.  For systems like DSA, where
the private key is in essence a random number, there is not searching, and
key generation is a lot faster.

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz           | The principal effect of| Periwinkle -- Consulting
(408)356-8506         | DMCA/SDMI is to prevent| 16345 Englewood Ave.
frantz at pwpconsult.com | fair use.              | Los Gatos, CA 95032, USA



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From SGuthery at mobile-mind.com  Mon Feb  4 16:17:30 2002
From: SGuthery at mobile-mind.com (Scott Guthery)
Date: Mon, 4 Feb 2002 16:17:30 -0500 
Subject: Welome to the Internet, here's your private key
Message-ID: <177EEB93DEA5D4119B4800508BE753D2157F2E@FS1>

An 8-bit 1/2 MIP smart card can generate 1024 bit RSA key
pair in about 20 seconds and 512 bit key pair in less
than 5 seconds.

Since this isn't typically done in the checkout lane 
this is certainly an acceptable time/security trade-off 
by many lights.  A device that can't generate a key pair
probably has other more compelling shortcomings as a
security token.

Cheers, Scott  

-----Original Message-----
From: Bill Frantz [mailto:frantz at pwpconsult.com]
Sent: Monday, February 04, 2002 3:42 PM
To: Bill Stewart; cryptography at wasabisystems.com
Subject: RE: Welome to the Internet, here's your private key


At 10:20 AM -0800 2/4/02, Bill Stewart wrote:
>There are special cases where the user's machine doesn't have
>the CPU horsepower to generate a key - PCs are fine,
>but perhaps Palm Pilots and similar handhelds are too slow
>(though a typical slow 33MHz 68000 or Dragonball is faster
>than the 8086/80286 MSDOS machines that PGP originally ran on.)
>Cash machines may be too slow, but they normally run symmetric crypto.
>A smartcard-only system probably _is_ too limited to generate keys,
>but that's the only realistic case I see.

It may depend on the public key system you are using.  Where you have to
search for numbers which have certain mathematical properties (like with
RSA), then you can indeed use a bunch of CPU.  For systems like DSA, where
the private key is in essence a random number, there is not searching, and
key generation is a lot faster.

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz           | The principal effect of| Periwinkle -- Consulting
(408)356-8506         | DMCA/SDMI is to prevent| 16345 Englewood Ave.
frantz at pwpconsult.com | fair use.              | Los Gatos, CA 95032, USA



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to
majordomo at wasabisystems.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ptrei at rsasecurity.com  Mon Feb  4 16:51:13 2002
From: ptrei at rsasecurity.com (Trei, Peter)
Date: Mon, 4 Feb 2002 16:51:13 -0500 
Subject: Welome to the Internet, here's your private key
Message-ID: <F504A8CEE925D411AF4A00508B8BE90A01E90C0D@exna07.securitydynamics.com>

I'm not the local expert on this, but there are SCs with
built-in crypto accelerators. They are designed for the 
use I described:
 
* Generate an RSA key pair on board, 
* export the public key,
* re-import the certificate, 
* wrap/unwrap a data block 
  (typically a session key or hash for signing) 
  using the onboard key pair without ever
  exporting the secret half of the key pair.

While they typically only use a PIN or passphrase
for protection, they usually will commit electronic 
seppuku if too many (typically 3) bad PINs or
passphrases are entered.

With these, you can let your CA admin run the
SW to create the keys and sign the public key,
and still have reasonable assurance that he has
not snagged a copy of the private key.

Peter Trei

> ----------
> From: 	Bill Frantz[SMTP:frantz at pwpconsult.com]
> Sent: 	Monday, February 04, 2002 3:41 PM
> To: 	Bill Stewart; cryptography at wasabisystems.com
> Subject: 	RE: Welome to the Internet, here's your private key
> 
> At 10:20 AM -0800 2/4/02, Bill Stewart wrote:
> >There are special cases where the user's machine doesn't have
> >the CPU horsepower to generate a key - PCs are fine,
> >but perhaps Palm Pilots and similar handhelds are too slow
> >(though a typical slow 33MHz 68000 or Dragonball is faster
> >than the 8086/80286 MSDOS machines that PGP originally ran on.)
> >Cash machines may be too slow, but they normally run symmetric crypto.
> >A smartcard-only system probably _is_ too limited to generate keys,
> >but that's the only realistic case I see.
> 
> It may depend on the public key system you are using.  Where you have to
> search for numbers which have certain mathematical properties (like with
> RSA), then you can indeed use a bunch of CPU.  For systems like DSA, where
> the private key is in essence a random number, there is not searching, and
> key generation is a lot faster.
> 
> Cheers - Bill
> 
> 
> -------------------------------------------------------------------------
> Bill Frantz           | The principal effect of| Periwinkle -- Consulting
> (408)356-8506         | DMCA/SDMI is to prevent| 16345 Englewood Ave.
> frantz at pwpconsult.com | fair use.              | Los Gatos, CA 95032, USA
> 
> 
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
> majordomo at wasabisystems.com
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From lynn.wheeler at firstdata.com  Mon Feb  4 17:09:18 2002
From: lynn.wheeler at firstdata.com (lynn.wheeler at firstdata.com)
Date: Mon, 4 Feb 2002 15:09:18 -0700
Subject: Welome to the Internet, here's your private key
Message-ID: <OF9F3F6BF7.0C0BA6F1-ON87256B56.00784692@internet.ny.fdms.firstdata.com>


One could claim that one of the reasons for using RSA digital signatures
with smart cards rather than DSA or EC/DSA is the DSA & EC/DSA requirement
for quality random number generation as part of the signature process.

A lot of the RSA digital signatures have the infrastructure that creates
the message to be signed to also generate and include a large random number
(nonce) in the message. This was acceptable to a large class of smartcards
that didn't have quality random number generation (either for the purposes
of ken-gen and/or signatures). Effective because of the short-comings of
the random number generation ... they had external source doing the key-gen
and injecting the key ... along with no requirement for (on-card) random
number during the signing process (typically a requirement that the
external source include a random nonce in the body of the message).

1) A typical message would have a 20-byte nonce random number, which
computed to a 20-byte SHA1 and then encrypted with RSA resulting in 20-byte
signature (basic message plus 40-byte infrastructure overhead, signature
plus nonce).

2) It is possible to compute a 20-byte SHA1 against the basic message, and
then do a DSA signature resulting in 40-byte signature (basic message plus
40-byte infrastructure overhead).

The difference between #1 and #2 is that a smartcard has eliminated any
dependency in number #1 on the infrastructure providing the message with a
random number.


Cards with quality random numbers ... can

1) do on card key-gen
2) use DSA or EC/DSA
3) remove dependency on external source to include random number in message
to be signed.

DSA & EC/DSA because they have a random number as parting of the signing
process precludes duplicate signatures on the same message ... multiple
messages with the same content & same exact signature is a replay. DSA &
EC/DSA doing multiple signings of the same content will always result in a
different signature value.

I've heard numbers on many of the 8bit smartcards ... power-cycle the card
each time it is asked to generate a random number .... do random number
generation 65,000 times and look at results. For some significant
percentage of 8bit cards it isn't unusual to find 30 percent of the random
numbers duplicated.



sguthery at mobile-mind.com on 2/4/2002 2:17 pm wrote:


An 8-bit 1/2 MIP smart card can generate 1024 bit RSA key
pair in about 20 seconds and 512 bit key pair in less
than 5 seconds.

Since this isn't typically done in the checkout lane
this is certainly an acceptable time/security trade-off
by many lights.  A device that can't generate a key pair
probably has other more compelling shortcomings as a
security token.

Cheers, Scott





---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From jon at jonsimon.com  Mon Feb  4 17:55:23 2002
From: jon at jonsimon.com (Jon Simon)
Date: Mon, 4 Feb 2002 14:55:23 -0800
Subject: Losing the Code War by Stephen Budiansky
In-Reply-To:  <F504A8CEE925D411AF4A00508B8BE90A01E90C03@exna07.securitydynamics.com>
References:  <F504A8CEE925D411AF4A00508B8BE90A01E90C03@exna07.securitydynamics.com>
Message-ID: <p05101203b88496e797cb@[207.172.166.129]>

At 11:00 AM -0500 2/4/02, Trei, Peter wrote:
>Don't forget that the MITM attack (which Schneier claims
>takes 2^(2n) = 2^112 time), also requires 2^56 blocks
>of storage. That's a lot, and the attack ceases to be
>parallelizable, unlike the straight brute-force attack.
>In fact, it's utterly intractable at the moment. Here's
>why:
>
>2^56 bytes = 72 petabytes, and
>I suspect you'd need 8 bytes per entry, or
>about 1/2 an exabyte.

With 120GB drives starting at about $200, the storage requirements 
can be met today, albeit not cheaply.  In four years or so, when we 
have 1TB drives, it will just be that much easier.  But I'm not 
losing any sleep either.
-Jon Simon
-- 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From frantz at pwpconsult.com  Mon Feb  4 19:24:30 2002
From: frantz at pwpconsult.com (Bill Frantz)
Date: Mon, 4 Feb 2002 16:24:30 -0800
Subject: Welome to the Internet, here's your private key
In-Reply-To:  <OF9F3F6BF7.0C0BA6F1-ON87256B56.00784692@internet.ny.fdms.firstdata.com>
Message-ID: <v03110712b884d337d526@[209.86.1.241]>

At 2:09 PM -0800 2/4/02, lynn.wheeler at firstdata.com wrote:
>One could claim that one of the reasons for using RSA digital signatures
>with smart cards rather than DSA or EC/DSA is the DSA & EC/DSA requirement
>for quality random number generation as part of the signature process.
>
>A lot of the RSA digital signatures have the infrastructure that creates
>the message to be signed to also generate and include a large random number
>(nonce) in the message. This was acceptable to a large class of smartcards
>that didn't have quality random number generation (either for the purposes
>of ken-gen and/or signatures). Effective because of the short-comings of
>the random number generation ... they had external source doing the key-gen
>and injecting the key ... along with no requirement for (on-card) random
>number during the signing process (typically a requirement that the
>external source include a random nonce in the body of the message).
>
>1) A typical message would have a 20-byte nonce random number, which
>computed to a 20-byte SHA1 and then encrypted with RSA resulting in 20-byte
>signature (basic message plus 40-byte infrastructure overhead, signature
>plus nonce).
>
>2) It is possible to compute a 20-byte SHA1 against the basic message, and
>then do a DSA signature resulting in 40-byte signature (basic message plus
>40-byte infrastructure overhead).
>
>The difference between #1 and #2 is that a smartcard has eliminated any
>dependency in number #1 on the infrastructure providing the message with a
>random number.

The quality of random numbers available to a smart card is a very important
point.  Unless you can trust the external source of random numbers, DSA
signatures (and elliptic curve DSA) don't strike me as very secure.  In
Applied Cryptography II, Schneier says, "If Eve ever recovers a K that
Alice used to sign a message, perhaps by exploiting some properties of the
random-number generator that generated K, she can recover Alice's private
key, X.  If Eve ever gets two messages signed using the same K, even if she
doesn't know what it is, she can recover X."  I can easily imagine a POS
terminal hacked to record both the random number, and the signature, as
part of a card cloning scam.

On the other hand, building a good source of random numbers into the card
doesn't strike me as being that difficult.  (Although running a FIPS-140
test every time a signature is generated (card is powered up), might be a
performance problem.)

It is probably worth examining the protocols for bad random number attacks
on the nonces.

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz           | The principal effect of| Periwinkle -- Consulting
(408)356-8506         | DMCA/SDMI is to prevent| 16345 Englewood Ave.
frantz at pwpconsult.com | fair use.              | Los Gatos, CA 95032, USA



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ncb at pobox.com  Mon Feb  4 21:36:32 2002
From: ncb at pobox.com (Nicholas Brawn)
Date: Tue, 5 Feb 2002 13:36:32 +1100
Subject: Unbreakable? (fwd)
In-Reply-To: <Pine.OSX.4.33.0202031659500.750-100000@allende.home>
Message-ID: <2A6033EC-19E1-11D6-AE4F-000393471DA8@pobox.com>

With regards to the storage requirements in order to capture the massive 
amounts of data in Rabin's system, has anyone correlated the growth rate 
in mass storage devices against the network bandwidth speeds available? 
Ie, is there a point at which we'll have cheap enough storage to make 
such a system pointless (ie, we'll be able to capture all data and 
analyse at leisure)? Are we already at or close to that point today?

Nick

--
Real friends help you move bodies.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ggr at qualcomm.com  Mon Feb  4 22:17:24 2002
From: ggr at qualcomm.com (Greg Rose)
Date: Tue, 05 Feb 2002 14:17:24 +1100
Subject: Welome to the Internet, here's your private key
In-Reply-To: <v03110712b884d337d526@[209.86.1.241]>
References: < <OF9F3F6BF7.0C0BA6F1-ON87256B56.00784692@internet.ny.fdms.firstdata.com>
Message-ID: <4.3.1.2.20020205125907.01e043f8@127.0.0.1>

At 04:24 PM 2/4/2002 -0800, Bill Frantz wrote:
>At 2:09 PM -0800 2/4/02, lynn.wheeler at firstdata.com wrote:
> >1) A typical message would have a 20-byte nonce random number, which
> >computed to a 20-byte SHA1 and then encrypted with RSA resulting in 20-byte
> >signature (basic message plus 40-byte infrastructure overhead, signature
> >plus nonce).

I think an RSA signature can be no smaller than the key modulus, so an RSA 
sig with a 1024-bit key is going to be 128 bytes plus some overhead, no 
matter what. I think you (Lynn) meant DSA here. Or maybe you did mean RSA, 
given that you then go on to DSA... I don't know.

>On the other hand, building a good source of random numbers into the card
>doesn't strike me as being that difficult.  (Although running a FIPS-140
>test every time a signature is generated (card is powered up), might be a
>performance problem.)

This forced me to instrument my FIPS-140 code to measure it. It takes 1.42 
ms to run a test on a Sun Ultra at 250MHz (I know, this is an ancient 
machine). It's all integer arithmetic, on short integers at that, except 
for the chi-square poker test, which (currently) does some floating point 
but could easily be recoded to do scaled, 32-bit integer (16 x 16 -> 32 bit 
multiplies, 16 of them, would be the bottleneck). Anyway, on a 0.5 MHz 
smarcard, it's probably fair to assume this would take 0.5 seconds or so 
(my C code is meant for clarity, not speed). This is probably less than the 
time required for an RSA or DSA signature (taking into account the 
precomputation) without hardware acceleration.

The scariest thing, though... at first I put in an unkeyed RC4 generator 
for the self-test data, but accidentally ran the FIPS test on a straight 
counter output... and it passed (even version 1)! I'd always assumed that 
something in the regularity of a counter would trigger it. Running through 
the buffer, XORing consecutive bytes, makes it fail quite handily, but 
might also have the undesirable effect of hiding a bias in the data, if 
there was one. I'm thinking of suggesting to NIST that a stronger test 
would be to run the test on the raw data, and then on the data after XORing 
consecutive bytes... if it's really random stuff it should pass both, and 
in the meantime this would catch all sorts of failures. Any comments?

Anyway, if anyone wants it, the new fips140.c (with self-test and timing 
loop support, but no other changes) is on my web page.

Greg.

Greg Rose                                       INTERNET: ggr at qualcomm.com
Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,                http://people.qualcomm.com/ggr/
Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From povey at dstc.qut.edu.au  Mon Feb  4 22:34:21 2002
From: povey at dstc.qut.edu.au (Dean Povey)
Date: Tue, 05 Feb 2002 13:34:21 +1000
Subject: Welome to the Internet, here's your private key 
In-Reply-To: Message from Greg Rose <ggr@qualcomm.com> 
   of "Tue, 05 Feb 2002 14:17:24 +1100." <4.3.1.2.20020205125907.01e043f8@127.0.0.1> 
Message-ID: <200202050334.g153YL220597@thunder.dstc.qut.edu.au>

>At 04:24 PM 2/4/2002 -0800, Bill Frantz wrote:
>>At 2:09 PM -0800 2/4/02, lynn.wheeler at firstdata.com wrote:
>> >1) A typical message would have a 20-byte nonce random number, which
>> >computed to a 20-byte SHA1 and then encrypted with RSA resulting in 20-byte
>> >signature (basic message plus 40-byte infrastructure overhead, signature
>> >plus nonce).
>
>I think an RSA signature can be no smaller than the key modulus, so an RSA 
                                    ^^^^^^^ larger
>sig with a 1024-bit key is going to be 128 bytes plus some overhead, no 
>matter what. I think you (Lynn) meant DSA here. Or maybe you did mean RSA, 
>given that you then go on to DSA... I don't know.

But the analysis still holds of course, the modulus is just an upper 
bound, and  this is just me being pedantic.

-- 
Dean Povey,              |em: dpovey at wedgetail.com|  JCSI: Java security toolkit
Senior S/W Developer     |ph:  +61 7 3864 5120    | uPKI: Embedded/C PKI toolkit
Wedgetail Communications |fax: +61 7 3864 1282    |       uASN.1: ASN.1 Compiler
Brisbane, Australia      |www: www.wedgetail.com  | XML Security: XML Signatures 



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Mon Feb  4 22:52:32 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Mon, 4 Feb 2002 22:52:32 -0500
Subject: [Mojonation-devel] Re: mojonation?
Message-ID: <p05100330b88507782173@[10.0.1.2]>


--- begin forwarded text


Status:  U
From: "Myers W. Carpenter" <myers at fil.org>
To: mojonation <mojonation-devel at lists.sourceforge.net>,
	mojonation-users at lists.sourceforge.net
Subject: [Mojonation-devel] Re: mojonation?
Sender: mojonation-devel-admin at lists.sourceforge.net
List-Help: <mailto:mojonation-devel-request at lists.sourceforge.net?subject=help>
List-Post: <mailto:mojonation-devel at lists.sourceforge.net>
List-Subscribe:
<https://lists.sourceforge.net/lists/listinfo/mojonation-devel>,
	<mailto:mojonation-devel-request at lists.sourceforge.net?subject=subscribe>
List-Id: For developers hacking Mojo Nation code
<mojonation-devel.lists.sourceforge.net>
List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=mojonation-devel>
Date: 04 Feb 2002 21:04:41 -0500

On Mon, 2002-02-04 at 16:29, Oscar Haeger wrote:
> Hello.
> I'm just curious about what's happened to mojonation. The webpage seems to
> be down, I can't contact any relay-servers or any of the mojonation central
> servers. There is no action on either the forum or any of the lists. It's
> like the whole mojonation devel-team along with most of the active users
> just vanished. Anyone care to tell me and/or the list what's going on?

Here's the story as much as I know:

Evil Genius for a Better Tommorrow who created Mojo Nation, as a company
is in hibernation after running out of funding.  All the developers were
let go.

Zooko, one of those developers, has been working on MN by himself for
the last few months.  He is currently having some net connectivity
problems and hasn't been seen on IRC for about a week.

I wrote a GUI for Mojo Nation that works under windows and linux (and
maybe Mac OS X too).

Zooko is planning on creating a fork called MNet (I think it needs a
better name).  The plan was to make use of the Mojo Nation servers that
were up.

I don't have any idea what's going on with the server hosting
mojonation.net, or the metatrackers.  They are run by EGBT, as well as
the Token server. If they are down, we'll probably put new metatrackers
up but we can't replace the Token server (never have had the source for
it.)  Mojonation will work without the Token server.

myers



_______________________________________________
Mojonation-devel mailing list
Mojonation-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mojonation-devel

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From Eugene.Leitl at lrz.uni-muenchen.de  Tue Feb  5 05:25:16 2002
From: Eugene.Leitl at lrz.uni-muenchen.de (Eugene Leitl)
Date: Tue, 5 Feb 2002 11:25:16 +0100 (MET)
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
Message-ID: <Pine.SOL.4.33.0202051125100.3453-100000@sun3.lrz-muenchen.de>



-- Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBMTO: N48 04'14.8'' E11 36'41.2'' http://www.leitl.org
57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3

---------- Forwarded message ----------
Date: Tue,  5 Feb 2002 11:10:49 +0100 (CET)
From: Robert Harley <harley at argote.ch>
To: fork at xent.com
Subject: Re: Cringely Gives KnowNow Some Unbelievable Free Press...

Eugene Leitl wrote:
>If you want to see EC used you need to describe a specific algorithm
>which has the following three properties:
>
>(1) widely agreed to be unencumbered, [...]

No problem.  Use a random secure curve over a binary field with a
polynomial basis (or over a random prime field).  Do it in software
using standard text-book algorithms.  Use a protocol that is
in the clear such as plain Diffie-Hellman key exchange.

That is what we do e.g., sharing a symmetric key for
encryption/decryption using Rijndael.  The only patent that is
relevant for us is our own one (pending) on a fast method for
generating random secure curves.


EL:
>(2) significantly better than RSA (this generally means faster)

This seems a little bit simplistic...  Whatever way you cut it, RSA
will beat ECC on public key ops (encryption, signature verification...)
whereas ECC will beat RSA on private key ones (decryption, signing...)

The speed argument can be compelling or not depending on what you want
to do.  On standard PCs doing occasional crypto operations, both ECC
and RSA are plenty fast.  The speed issue is on small devices like
hand-helds or mobile phones, and on heavily loaded servers.

For instance with signatures, people might want to sign on slow client
devices which take 1 second with ECC but many seconds with RSA; and
then verify the signatures on servers fast enough for thousands per
second.  It is easier to upgrade your servers if needed than to
upgrade the users who aren't using your service because it is too slow.

One hears of crazy stuff like network setups which time out when you
try to do DH with 1024-bit RSA on some slow hand-helds, but work fine
when doing equivalent DH with 163-bit ECC.

In our work with Mailwatcher, servers talk to each other doing equal
numbers of encryptions and decryptions for many users.  Even according
to RSA Security's own numbers, ECC wins easily in this case!



EL:
>(3) has seen a significant amount of analysis so that we can have
>some reasonable confidence it's secure.

The FUD campaign on this point has been too successful.

Serious study of factoring and related stuff dates from the early 19th
century with people like Gauss.  Serious study of elliptic curves and
related stuff dates from... umm... the early 19th century with people
like... umm... Gauss.

Modern study of discrete-log based cryptosystems dates from the
invention of public-key systems in 1976.  Modern study of factoring
based cryptosystems dates from the invention of RSA in 1977.  ECC is
in the former family, although it dates from 1985.

The relative paucity of results on ECC is a good thing.  There has
been no progress on breaking ECC with properly chosen curves.  On the
contrary there is a negative result that discrete logs using generic
group operations do take exponential time.  The problem in this
area is with some people sailing too close to the wind and picking
curves with tonnes of useful properties to speed up their
cryptosystems (and, unfortunately, attacks on some of them).


For RSA, it was claimed in 1977 that factoring a certain 426-bit
number would take quadrillions of years.  This in spite of the fact
that a sub-exponential algorithm for factoring was already known.
Knowledge was pretty fuzzy about its runtime and practicality.  Some
widely-deployed big-budget systems were designed using RSA as low as
320 bits.  That's easily broken.

During the 1980's, the research community perfected the early
sub-exponential methods and the 426-bit number was broken in 1994 by a
team led by Arjen Lenstra (I was in it...)

There was also a new faster algorithm, the NFS.  Knowledge was pretty
fuzzy about its runtime and practicality.  During the 1990's, the
research community perfected it.  Then recently 512 bits was broken.

The current record, as of a few days ago, is 524 bits attained by Jens
Franke et al. when completing the factorization of 2^953+1 (there were
three other factors previously found by Paul Zimmerman, Torbjorn
Granlund and myself).  It would be feasible to break 600 bits or more
with some effort.


Things have been quiet on the "new algorithms" front for a few years.
But at Crypto last August, Dan Bernstein announced a new design for a
machine dedicated to NFS using asymptotically fast algorithms and
optimising memory, CPU power and amount of parallelism to minimize
asymptotic cost.  His conclusion, recently detailed in a paper, should
be a bombshell, but apparently everyone is asleep:

DB:
>This reduction of total cost [...] means that a [approx 3d-digit]
>factorization with the new machine has the same cost as a d-digit
>factorization with previous machines.

Knowledge is pretty fuzzy about its runtime and practicality, but it
means that it may well be much easier than previously believed to
break 1024 bits.  You may need, say, 3000 bits to be safe.

Meanwhile ECC is still fine with 163 bits.


EL:
>Until someone does that, the cost of information in choosing an EC
>algorithm is simply too high to justify replacing RSA in most
>applications.

Personally, I no longer trust RSA for long term security.

This is public-key crypto, not symmetric, so a break of your RSA key
means that all your encrypted traffic becomes readable rather than
just one message.  E.g., if a few years ago you used 512-bit RSA to
encrypt a will that was not to be read by anybody until you die,
that's tough because it could be read today.  Doesn't matter that you
moved to 768 bits and then 1024 in the meantime.

All that secured info that was supposed to be absolutely positively
definitely safe for 50 years may not be after all but, hey, you just
have to increase your key size again and people won't be able to read
your stuff anymore "this time it's really true, promise!"


BTW, at the ECC conference last October, an NSA speaker said that they
were transitioning sensitive data to ECC.

Wall.  Writing.  Etc.



Bye,
  Rob.
     .-.                    Robert.Harley at argote.ch                    .-.
    /   \           .-.      Software Development       .-.           /   \
   /     \         /   \       .-.     _     .-.       /   \         /     \
  /       \       /     \     /   \   / \   /   \     /     \       /       \
 /         \     /       \   /     `-'   `-'     \   /       \     /         \
            \   /         `-'       ArgoTech      `-'         \   /
             `-'                http://argote.ch/              `-'


http://xent.com/mailman/listinfo/fork


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From reinhold at world.std.com  Tue Feb  5 09:37:45 2002
From: reinhold at world.std.com (Arnold G. Reinhold)
Date: Tue, 5 Feb 2002 09:37:45 -0500
Subject: Welome to the Internet, here's your private key
In-Reply-To:  <OF9F3F6BF7.0C0BA6F1-ON87256B56.00784692@internet.ny.fdms.firstdata.com>
References:  <OF9F3F6BF7.0C0BA6F1-ON87256B56.00784692@internet.ny.fdms.firstdata.com>
Message-ID: <v04210104b885962c8c6e@[192.168.0.2]>

I'd argue that the RSA and DSA situations can be made equivalent if 
the card has some persistent memory. Some high quality randomness is 
needed at RSA key generation.  For the DSA case, use 256 bits of 
randomness at initialization to seed a PRNG using AES, say. Output 
from the PRNG could be then used to provide the nonces for DSA.  For 
extra credit, PRNG seed could be xor'd periodically with whatever 
randomness is available on chip.

The resulting DSA system requires about the same randomness at 
initialization as RSA. The additional vulnerability introduced 
requires breaking AES to exploit, even if no further randomness is 
available.  All things considered, I'd trust an AES PRNG more than a 
smart card RNG whose long term quality I cannot assess. Better to use 
both, of course.

Arnold Reinhold



At 3:09 PM -0700 2/4/02, lynn.wheeler at firstdata.com wrote:
>One could claim that one of the reasons for using RSA digital signatures
>with smart cards rather than DSA or EC/DSA is the DSA & EC/DSA requirement
>for quality random number generation as part of the signature process.

...

>
>Cards with quality random numbers ... can
>
>1) do on card key-gen
>2) use DSA or EC/DSA
>3) remove dependency on external source to include random number in message
>to be signed.
>
>DSA & EC/DSA because they have a random number as parting of the signing
>process precludes duplicate signatures on the same message ... multiple
>messages with the same content & same exact signature is a replay. DSA &
>EC/DSA doing multiple signings of the same content will always result in a
>different signature value.
>
>I've heard numbers on many of the 8bit smartcards ... power-cycle the card
>each time it is asked to generate a random number .... do random number
>generation 65,000 times and look at results. For some significant
>percentage of 8bit cards it isn't unusual to find 30 percent of the random
>numbers duplicated.
>

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Tue Feb  5 09:15:26 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 5 Feb 2002 09:15:26 -0500
Subject: [Mojonation-users] MojoNation public network shutting down   (fwd)
Message-ID: <p05100338b88599666ad1@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Tue, 5 Feb 2002 10:51:25 +0100 (MET)
From: Eugene Leitl <Eugene.Leitl at lrz.uni-muenchen.de>
To: <transhumantech at yahoogroups.com>
cc: <cpunx-news at yahoogroups.com>, <cypherpunks at einstein.ssz.com>,
   forkit! <fork at xent.com>, <cryptography at mail.lrz-muenchen.de>
Subject: [Mojonation-users] MojoNation public network shutting down
  (fwd)
Sender: owner-cypherpunks at lne.com

-- Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBMTO: N48 04'14.8'' E11 36'41.2'' http://www.leitl.org
57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3

---------- Forwarded message ----------
Date: Mon, 04 Feb 2002 14:52:06 -0800
From: Jim McCoy <mccoy at mad-scientist.com>
To: mojonation-users at lists.sourceforge.net
Subject: [Mojonation-users] MojoNation public network shutting down

After more than a year of testing the public prototype for the MojoNation
technology platform we are shutting down the public network.  The MojoNation
technology will continue to be available via the soon to be announced Mnnet
project, of which more information will be made available at the CodeCon
conference.

It is expected that MNnet will remove several of the remaining centralized
features of the MojoNation technology and result in a somewhat simplified
version of the current system along with native Uis and other fun features.

More info will be made available over the next couple of weeks as details
are worked out.


-Jim




_______________________________________________
Mojonation-users mailing list
Mojonation-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mojonation-users

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From povey at dstc.qut.edu.au  Mon Feb  4 22:34:21 2002
From: povey at dstc.qut.edu.au (Dean Povey)
Date: Tue, 5 Feb 2002 03:34:21 +0000
Subject: Welome to the Internet, here's your private key 
Message-ID: <C1256B57.00558EE8.00@>






>At 04:24 PM 2/4/2002 -0800, Bill Frantz wrote:
>>At 2:09 PM -0800 2/4/02, lynn.wheeler at firstdata.com wrote:
>> >1) A typical message would have a 20-byte nonce random number, which
>> >computed to a 20-byte SHA1 and then encrypted with RSA resulting in 20-byte
>> >signature (basic message plus 40-byte infrastructure overhead, signature
>> >plus nonce).
>
>I think an RSA signature can be no smaller than the key modulus, so an RSA
                                    ^^^^^^^ larger
>sig with a 1024-bit key is going to be 128 bytes plus some overhead, no
>matter what. I think you (Lynn) meant DSA here. Or maybe you did mean RSA,
>given that you then go on to DSA... I don't know.

But the analysis still holds of course, the modulus is just an upper
bound, and  this is just me being pedantic.

--
Dean Povey,              |em: dpovey at wedgetail.com|  JCSI: Java security toolkit
Senior S/W Developer     |ph:  +61 7 3864 5120    | uPKI: Embedded/C PKI toolkit
Wedgetail Communications |fax: +61 7 3864 1282    |       uASN.1: ASN.1 Compiler
Brisbane, Australia      |www: www.wedgetail.com  | XML Security: XML Signatures



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com

Esperamos su visita en:

Web corporativa: http://www.telefonica-data.es
Revista Pulso On Line: http://www.telefonica-data.es/pulso
T.I.C: http://www.tdatacenter.com/es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
informacion privilegiada o confidencial cuya divulgacion esta prohibida en
virtud de la legislacion vigente. Si ha recibido este mensaje por error, le
rogamos que nos lo comunique inmediatamente por esta misma via y proceda a su
destruccion.



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From Eugene.Leitl at lrz.uni-muenchen.de  Tue Feb  5 05:25:16 2002
From: Eugene.Leitl at lrz.uni-muenchen.de (Eugene Leitl)
Date: Tue, 5 Feb 2002 10:25:16 +0000
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
Message-ID: <C1256B57.0055C706.00@>








-- Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBMTO: N48 04'14.8'' E11 36'41.2'' http://www.leitl.org
57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3

---------- Forwarded message ----------
Date: Tue,  5 Feb 2002 11:10:49 +0100 (CET)
From: Robert Harley <harley at argote.ch>
To: fork at xent.com
Subject: Re: Cringely Gives KnowNow Some Unbelievable Free Press...

Eugene Leitl wrote:
>If you want to see EC used you need to describe a specific algorithm
>which has the following three properties:
>
>(1) widely agreed to be unencumbered, [...]

No problem.  Use a random secure curve over a binary field with a
polynomial basis (or over a random prime field).  Do it in software
using standard text-book algorithms.  Use a protocol that is
in the clear such as plain Diffie-Hellman key exchange.

That is what we do e.g., sharing a symmetric key for
encryption/decryption using Rijndael.  The only patent that is
relevant for us is our own one (pending) on a fast method for
generating random secure curves.


EL:
>(2) significantly better than RSA (this generally means faster)

This seems a little bit simplistic...  Whatever way you cut it, RSA
will beat ECC on public key ops (encryption, signature verification...)
whereas ECC will beat RSA on private key ones (decryption, signing...)

The speed argument can be compelling or not depending on what you want
to do.  On standard PCs doing occasional crypto operations, both ECC
and RSA are plenty fast.  The speed issue is on small devices like
hand-helds or mobile phones, and on heavily loaded servers.

For instance with signatures, people might want to sign on slow client
devices which take 1 second with ECC but many seconds with RSA; and
then verify the signatures on servers fast enough for thousands per
second.  It is easier to upgrade your servers if needed than to
upgrade the users who aren't using your service because it is too slow.

One hears of crazy stuff like network setups which time out when you
try to do DH with 1024-bit RSA on some slow hand-helds, but work fine
when doing equivalent DH with 163-bit ECC.

In our work with Mailwatcher, servers talk to each other doing equal
numbers of encryptions and decryptions for many users.  Even according
to RSA Security's own numbers, ECC wins easily in this case!



EL:
>(3) has seen a significant amount of analysis so that we can have
>some reasonable confidence it's secure.

The FUD campaign on this point has been too successful.

Serious study of factoring and related stuff dates from the early 19th
century with people like Gauss.  Serious study of elliptic curves and
related stuff dates from... umm... the early 19th century with people
like... umm... Gauss.

Modern study of discrete-log based cryptosystems dates from the
invention of public-key systems in 1976.  Modern study of factoring
based cryptosystems dates from the invention of RSA in 1977.  ECC is
in the former family, although it dates from 1985.

The relative paucity of results on ECC is a good thing.  There has
been no progress on breaking ECC with properly chosen curves.  On the
contrary there is a negative result that discrete logs using generic
group operations do take exponential time.  The problem in this
area is with some people sailing too close to the wind and picking
curves with tonnes of useful properties to speed up their
cryptosystems (and, unfortunately, attacks on some of them).


For RSA, it was claimed in 1977 that factoring a certain 426-bit
number would take quadrillions of years.  This in spite of the fact
that a sub-exponential algorithm for factoring was already known.
Knowledge was pretty fuzzy about its runtime and practicality.  Some
widely-deployed big-budget systems were designed using RSA as low as
320 bits.  That's easily broken.

During the 1980's, the research community perfected the early
sub-exponential methods and the 426-bit number was broken in 1994 by a
team led by Arjen Lenstra (I was in it...)

There was also a new faster algorithm, the NFS.  Knowledge was pretty
fuzzy about its runtime and practicality.  During the 1990's, the
research community perfected it.  Then recently 512 bits was broken.

The current record, as of a few days ago, is 524 bits attained by Jens
Franke et al. when completing the factorization of 2^953+1 (there were
three other factors previously found by Paul Zimmerman, Torbjorn
Granlund and myself).  It would be feasible to break 600 bits or more
with some effort.


Things have been quiet on the "new algorithms" front for a few years.
But at Crypto last August, Dan Bernstein announced a new design for a
machine dedicated to NFS using asymptotically fast algorithms and
optimising memory, CPU power and amount of parallelism to minimize
asymptotic cost.  His conclusion, recently detailed in a paper, should
be a bombshell, but apparently everyone is asleep:

DB:
>This reduction of total cost [...] means that a [approx 3d-digit]
>factorization with the new machine has the same cost as a d-digit
>factorization with previous machines.

Knowledge is pretty fuzzy about its runtime and practicality, but it
means that it may well be much easier than previously believed to
break 1024 bits.  You may need, say, 3000 bits to be safe.

Meanwhile ECC is still fine with 163 bits.


EL:
>Until someone does that, the cost of information in choosing an EC
>algorithm is simply too high to justify replacing RSA in most
>applications.

Personally, I no longer trust RSA for long term security.

This is public-key crypto, not symmetric, so a break of your RSA key
means that all your encrypted traffic becomes readable rather than
just one message.  E.g., if a few years ago you used 512-bit RSA to
encrypt a will that was not to be read by anybody until you die,
that's tough because it could be read today.  Doesn't matter that you
moved to 768 bits and then 1024 in the meantime.

All that secured info that was supposed to be absolutely positively
definitely safe for 50 years may not be after all but, hey, you just
have to increase your key size again and people won't be able to read
your stuff anymore "this time it's really true, promise!"


BTW, at the ECC conference last October, an NSA speaker said that they
were transitioning sensitive data to ECC.

Wall.  Writing.  Etc.



Bye,
  Rob.
     .-.                    Robert.Harley at argote.ch                    .-.
    /   \           .-.      Software Development       .-.           /   \
   /     \         /   \       .-.     _     .-.       /   \         /     \
  /       \       /     \     /   \   / \   /   \     /     \       /       \
 /         \     /       \   /     `-'   `-'     \   /       \     /         \
            \   /         `-'       ArgoTech      `-'         \   /
             `-'                http://argote.ch/              `-'


http://xent.com/mailman/listinfo/fork


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com

Esperamos su visita en:

Web corporativa: http://www.telefonica-data.es
Revista Pulso On Line: http://www.telefonica-data.es/pulso
T.I.C: http://www.tdatacenter.com/es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
informacion privilegiada o confidencial cuya divulgacion esta prohibida en
virtud de la legislacion vigente. Si ha recibido este mensaje por error, le
rogamos que nos lo comunique inmediatamente por esta misma via y proceda a su
destruccion.



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ekr at rtfm.com  Tue Feb  5 11:11:19 2002
From: ekr at rtfm.com (Eric Rescorla)
Date: 05 Feb 2002 08:11:19 -0800
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
In-Reply-To: Eugene Leitl's message of "Tue, 5 Feb 2002 11:25:16 +0100 (MET)"
References: <Pine.SOL.4.33.0202051125100.3453-100000@sun3.lrz-muenchen.de>
Message-ID: <kjit9bhpso.fsf@romeo.rtfm.com>

Although the headers and quoting have gotten munged, this
appears to be a reply to my message.

Eugene Leitl <Eugene.Leitl at lrz.uni-muenchen.de> writes:

> -- Eugen* Leitl <a href="http://leitl.org">leitl</a>
> ______________________________________________________________
> ICBMTO: N48 04'14.8'' E11 36'41.2'' http://www.leitl.org
> 57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3
> 
> ---------- Forwarded message ----------
> Date: Tue,  5 Feb 2002 11:10:49 +0100 (CET)
> From: Robert Harley <harley at argote.ch>
> To: fork at xent.com
> Subject: Re: Cringely Gives KnowNow Some Unbelievable Free Press...
> 
> Eugene Leitl wrote:
> >If you want to see EC used you need to describe a specific algorithm
> >which has the following three properties:
> >
> >(1) widely agreed to be unencumbered, [...]
> 
> No problem.  Use a random secure curve over a binary field with a
> polynomial basis (or over a random prime field).  Do it in software
> using standard text-book algorithms.  Use a protocol that is
> in the clear such as plain Diffie-Hellman key exchange.
And this is how fast?

> EL:
> >(2) significantly better than RSA (this generally means faster)
> 
> This seems a little bit simplistic...  Whatever way you cut it, RSA
> will beat ECC on public key ops (encryption, signature verification...)
> whereas ECC will beat RSA on private key ones (decryption, signing...)
> 
> The speed argument can be compelling or not depending on what you want
> to do.
It's the only real argument that ECC's got going for it. RSA can
be made arbitrarily fast by making it arbitrarily slow.

> EL:
> >Until someone does that, the cost of information in choosing an EC
> >algorithm is simply too high to justify replacing RSA in most
> >applications.
> 
> Personally, I no longer trust RSA for long term security.
> 
> This is public-key crypto, not symmetric, so a break of your RSA key
> means that all your encrypted traffic becomes readable rather than
> just one message.  E.g., if a few years ago you used 512-bit RSA to
> encrypt a will that was not to be read by anybody until you die,
> that's tough because it could be read today.  Doesn't matter that you
> moved to 768 bits and then 1024 in the meantime.
If you care about Perfect Forward Secrecy, you shouldn't be using
RSA at all. You should be using DH with a fresh key for each
exchange. The probability that in the next 50 years your key will
be compromised in some other way than factoring is sufficiently
high to motivate this tactic. (In my view, it's vastly higher
than that of your key being broken by factoring).


This message actually makes my point quite nicely.  I frequently see
long detailed arguments by ECC proponents about how wonderful ECC is
and how it should replace RSA. This is one such argument. That's not
what's needed.

For ECC to take off, someone will have to actually write it into
protocols. This requires someone to identify a specific ECC algorithm
that meets the properties that I laid out, and document those
properties with literature citations, performance numbers, securtiy
estimates, etc. That's what's needed before the COMSEC people will
feel comfortable adding ECC to their systems.

Until someone's willing to step up to the plate on that, we're not
going to see ECC deployment in standard protocols.

-Ekr

-- 
[Eric Rescorla                                   ekr at rtfm.com]
                http://www.rtfm.com/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ggr at qualcomm.com  Tue Feb  5 14:15:54 2002
From: ggr at qualcomm.com (Greg Rose)
Date: Wed, 06 Feb 2002 06:15:54 +1100
Subject: URL for fips140.c
In-Reply-To: <v04210105b885a07ff958@[192.168.0.2]>
References: <4.3.1.2.20020205125907.01e043f8@127.0.0.1>
 < <OF9F3F6BF7.0C0BA6F1-ON87256B56.00784692@internet.ny.fdms.firstdata.com>
 <4.3.1.2.20020205125907.01e043f8@127.0.0.1>
Message-ID: <4.3.1.2.20020206061425.01e26988@127.0.0.1>

At 09:46 AM 2/5/2002 -0500, Arnold G. Reinhold wrote:
>I couldn't find it. Give me a hint?

Sorry, I should have been more specific:

http://people.qualcomm.com/ggr/QC/fips140.c goes straight to it.

Greg.

Greg Rose                                       INTERNET: ggr at qualcomm.com
Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,                http://people.qualcomm.com/ggr/
Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From frantz at pwpconsult.com  Tue Feb  5 14:16:40 2002
From: frantz at pwpconsult.com (Bill Frantz)
Date: Tue, 5 Feb 2002 11:16:40 -0800
Subject: Welome to the Internet, here's your private key
In-Reply-To: <v04210104b885962c8c6e@[192.168.0.2]>
References:   <OF9F3F6BF7.0C0BA6F1-ON87256B56.00784692@internet.ny.fdms.firstdata.com>
  <OF9F3F6BF7.0C0BA6F1-ON87256B56.00784692@internet.ny.fdms.firstdata.com>
Message-ID: <v03110714b885de3590d1@[209.86.1.241]>

At 6:37 AM -0800 2/5/02, Arnold G. Reinhold wrote:
>I'd argue that the RSA and DSA situations can be made equivalent if
>the card has some persistent memory.

I expect you could initialize the random data in that memory during
manufacture with little loss of real security.  (If you are concerned about
the card's manufacturer, then you have bigger problems.  If anyone does,
the manufacturer has the necessary equipment to extract data from secret
parts of the card, install Trojans etc.)

Note that if the card generates its own keys, it needs the same kind of
memory to store the keys as it needs to store a random seed.

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz           | The principal effect of| Periwinkle -- Consulting
(408)356-8506         | DMCA/SDMI is to prevent| 16345 Englewood Ave.
frantz at pwpconsult.com | fair use.              | Los Gatos, CA 95032, USA



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From frantz at pwpconsult.com  Tue Feb  5 14:25:09 2002
From: frantz at pwpconsult.com (Bill Frantz)
Date: Tue, 5 Feb 2002 11:25:09 -0800
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
In-Reply-To: <Pine.SOL.4.33.0202051125100.3453-100000@sun3.lrz-muenchen.de>
Message-ID: <v03110715b885e0e33209@[209.86.1.241]>

At 2:25 AM -0800 2/5/02, Eugene Leitl wrote:
>-- Eugen* Leitl <a href="http://leitl.org">leitl</a>
>______________________________________________________________
>ICBMTO: N48 04'14.8'' E11 36'41.2'' http://www.leitl.org
>57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3
>
>---------- Forwarded message ----------
>Date: Tue,  5 Feb 2002 11:10:49 +0100 (CET)
>From: Robert Harley <harley at argote.ch>
>
>...
>
>This is public-key crypto, not symmetric, so a break of your RSA key
>means that all your encrypted traffic becomes readable rather than
>just one message.

IMHO, interactive protocols (e.g. certain modes of SSL/TLS) which are
subject to this attack should be retired.  Non-interactive protocols (e.g.
PGP email), are much more difficult to fix.

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz           | The principal effect of| Periwinkle -- Consulting
(408)356-8506         | DMCA/SDMI is to prevent| 16345 Englewood Ave.
frantz at pwpconsult.com | fair use.              | Los Gatos, CA 95032, USA



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From yeoh at cs.wisc.edu  Tue Feb  5 16:48:08 2002
From: yeoh at cs.wisc.edu (Kim-Ee Yeoh)
Date: Tue, 5 Feb 2002 15:48:08 -0600 (CST)
Subject: Welome to the Internet, here's your private key
In-Reply-To: <4.3.1.2.20020205125907.01e043f8@127.0.0.1>
Message-ID: <Pine.LNX.3.96L.1020205152424.3122B-100000@tux08.cs.wisc.edu>

On Tue, 5 Feb 2002, Greg Rose wrote:

> This forced me to instrument my FIPS-140 code to measure it. It takes 1.42 
> ms to run a test on a Sun Ultra at 250MHz (I know, this is an ancient 
> machine). It's all integer arithmetic, on short integers at that, except 
> for the chi-square poker test, which (currently) does some floating point 
> but could easily be recoded to do scaled, 32-bit integer (16 x 16 -> 32 bit 
> multiplies, 16 of them, would be the bottleneck).

I took a brief look at your code, and one optimization you could do is to
make a single pass for both the monobit and poker tests.  If c_0, c_1,
..., c_15 are the frequency counts of nibbles, then the monobit count is
just the sum over all i's of c_i * w(i), where w(i) is the Hamming weight
of i.

Also the chi-square for the poker test could easily be done in pure
integer arithmetic by clearing out the denominator of 5000.  (Of course,
it helps when your embedded system, such as the one I work with, has a
machine word size of 32 bits.  Your mileage on specific smartcards may
vary.)


> The scariest thing, though... at first I put in an unkeyed RC4 generator 
> for the self-test data, but accidentally ran the FIPS test on a straight 
> counter output... and it passed (even version 1)! I'd always assumed that 
> something in the regularity of a counter would trigger it. Running through 
> the buffer, XORing consecutive bytes, makes it fail quite handily, but 
> might also have the undesirable effect of hiding a bias in the data, if 
> there was one. I'm thinking of suggesting to NIST that a stronger test 
> would be to run the test on the raw data, and then on the data after XORing 
> consecutive bytes... if it's really random stuff it should pass both, and 
> in the meantime this would catch all sorts of failures. Any comments?

Could you clarify what you mean by "counter output"?  Are we talking about
a sequence of consecutive 8-, 16-, or 32-bit numbers?  If so, FIPS will
detect and flunk such sequences.  I'm almost as certain that a
maximal-period LFSR would be similarly detected.  A runs test, especially,
isn't fooled so easily.

As it stands, the FIPS-140 RNG testsuite is a good compromise between
speed and validation efficacy.  FIPS-140 is a standard for crypto-module
validation, and so long as your tests for the RNG component of your
crypto-module are comparable or exceed those specified in the standard,
you're doing fine.  You are quite at liberty to perform the additional
tests you've suggested.


Kim-Ee


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From bear at sonic.net  Tue Feb  5 17:47:27 2002
From: bear at sonic.net (bear)
Date: Tue, 5 Feb 2002 14:47:27 -0800 (PST)
Subject: biometrics
In-Reply-To: <v03110709b87cb2b1859c@[165.247.214.234]>
Message-ID: <Pine.LNX.4.40.0202051439510.8144-100000@newbolt.sonic.net>



On Tue, 29 Jan 2002, Bill Frantz wrote:

>What would be really nice is to be able to have the same PIN/password for
>everything.  With frequent use, forgetting it would be less of a problem,
>as would the temptation to write it down.  However, such a system would
>require that the PIN/password be kept secret from the verifier (including
>possibly untrusted hardware/software used to enter it.


You could, I suppose, create an algorithm that takes as inputs
your "single" PIN/password and the name of the entity you're
dealing with, and produces a "daily use" PIN/password for you
to use with that entity.

It wouldn't help much in the daily use arena -- you'd still
have to carry all the daily use PINs around in your head -
but in the scenario where you forget one, it could be used to
recreate it, and it would be a bit more secure than carrying
around the sheet of paper where your 20 PINs are all written
down.

				Bear


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ggr at qualcomm.com  Tue Feb  5 18:06:46 2002
From: ggr at qualcomm.com (Greg Rose)
Date: Wed, 06 Feb 2002 10:06:46 +1100
Subject: Welome to the Internet, here's your private key
In-Reply-To: <Pine.LNX.3.96L.1020205152424.3122B-100000@tux08.cs.wisc.ed
 u>
References: <4.3.1.2.20020205125907.01e043f8@127.0.0.1>
Message-ID: <4.3.1.2.20020206092333.01d3fdc0@127.0.0.1>

At 03:48 PM 2/5/2002 -0600, Kim-Ee Yeoh wrote:
>I took a brief look at your code, and one optimization you could do is to
>make a single pass for both the monobit and poker tests.  If c_0, c_1,
>..., c_15 are the frequency counts of nibbles, then the monobit count is
>just the sum over all i's of c_i * w(i), where w(i) is the Hamming weight
>of i.

Yep, that's a small and useful optimisation.

>Also the chi-square for the poker test could easily be done in pure
>integer arithmetic by clearing out the denominator of 5000.  (Of course,
>it helps when your embedded system, such as the one I work with, has a
>machine word size of 32 bits.  Your mileage on specific smartcards may
>vary.)

I recognise this too.

My goal when I wrote the code was to cleanly implement the FIPS as it 
described the tests... which I think I did. Anyone who *truly* cares about 
optimising it for a smartcard for example, won't use C code to do it. As I 
said, the only nasty things that would remain at that point are the 16 
multiplies (16x16->32 bit integers), calculating the squares of the poker 
values... these are pretty much unavoidable. Given that, I don't understand 
why the FIPS specified the tests using floating point... *they* should have 
made this optimisation (as they did for the bounds on the runs test, which 
they initially got wrong anyway...)

> > The scariest thing, though... at first I put in an unkeyed RC4 generator
> > for the self-test data, but accidentally ran the FIPS test on a straight
> > counter output... and it passed (even version 1)! I'd always assumed that
> > something in the regularity of a counter would trigger it. Running through
> > the buffer, XORing consecutive bytes, makes it fail quite handily, but
> > might also have the undesirable effect of hiding a bias in the data, if
> > there was one. I'm thinking of suggesting to NIST that a stronger test
> > would be to run the test on the raw data, and then on the data after 
> XORing
> > consecutive bytes... if it's really random stuff it should pass both, and
> > in the meantime this would catch all sorts of failures. Any comments?
>
>Could you clarify what you mean by "counter output"?  Are we talking about
>a sequence of consecutive 8-, 16-, or 32-bit numbers?  If so, FIPS will
>detect and flunk such sequences.

While priming the RC4 table, I accidentally filled the data buffer instead 
(D'oh!) with consecutive byte values 0x00, 0x01, ... 0xFF, 0x00, ...

This very much passes the FIPS 140 tests for randomness, despite being 
nothing like it:
9932 ones
Poker test: 317 0x0s
Poker test: 317 0x1s
Poker test: 317 0x2s
Poker test: 317 0x3s
Poker test: 316 0x4s
Poker test: 316 0x5s
Poker test: 316 0x6s
Poker test: 316 0x7s
Poker test: 316 0x8s
Poker test: 316 0x9s
Poker test: 316 0xAs
Poker test: 316 0xBs
Poker test: 304 0xCs
Poker test: 300 0xDs
Poker test: 300 0xEs
Poker test: 300 0xFs
Poker test ChiSquared parameter = 2.304
2497 runs of 1 0s
2529 runs of 1 1s
1252 runs of 2 0s
1255 runs of 2 1s
628 runs of 3 0s
621 runs of 3 1s
317 runs of 4 0s
307 runs of 4 1s
159 runs of 5 0s
152 runs of 5 1s
160 runs of 6 0s
149 runs of 6 1s

I, like you, thought it would flunk, but it doesn't.

>I'm almost as certain that a
>maximal-period LFSR would be similarly detected.  A runs test, especially,
>isn't fooled so easily.

An interesting question. One of the utilities I have lying around happens 
to do LFSRs... so I can answer this.

Up to LFSR length 8, there are too few runs of length 6 or greater, so they 
must fail. LFSR Length 9 fails the low end of the chi-squared test... too 
evenly distributed. (Note that the counter above only passes this because 
it cuts off in the middle of a byte count, and so skews away from the 
one-heavy end of the spectrum). Hmmm... a table is required. (I'm using the 
first polynomial specified in Schneier of each length, impulse sequence:
$ lfsr -n 20000 16 5 3 2 | binbin | fips140)

Poly Length     Description of failure
-----------     ------------------
9               Poker test too regular
10              Poker test too regular
11              Poker test too regular
12              Passes test! (12, 6, 4, 1, 0)
13              Passes test! (13, 4, 3, 1, 0)
14              Passes test! (14, 5, 3, 1, 0)
15              multiple runs test failures (byte alignment too good?),
                 but passes poker test
16              Passes test! (16, 5, 3, 2, 0)
17              Passes test! (17, 3, 0)

At this point I am detecting a pattern... So, I'm afraid it isn't true that 
it will pick up even these simple linear sequences. (An LFSR of length 12 
only generates 4095 bits, repeated about 5 times!) I find this less 
surprising, actually. LFSR output "looks" random in some more fundamental 
sense.

>As it stands, the FIPS-140 RNG testsuite is a good compromise between
>speed and validation efficacy.  FIPS-140 is a standard for crypto-module
>validation, and so long as your tests for the RNG component of your
>crypto-module are comparable or exceed those specified in the standard,
>you're doing fine.  You are quite at liberty to perform the additional
>tests you've suggested.

I was surprised that these simple software bad-generators managed to pass 
the test, although the point of the test is more to check out hardware 
failure-modes, like biases or stuck bits. Still. Interesting.

Greg.

Greg Rose                                       INTERNET: ggr at qualcomm.com
Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,                http://people.qualcomm.com/ggr/
Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From mcbride at countersiege.com  Tue Feb  5 18:18:35 2002
From: mcbride at countersiege.com (Ryan McBride)
Date: Tue, 5 Feb 2002 18:18:35 -0500
Subject: Welome to the Internet, here's your private key
In-Reply-To: <v03110714b885de3590d1@[209.86.1.241]>
References: <OF9F3F6BF7.0C0BA6F1-ON87256B56.00784692@internet.ny.fdms.firstdata.com> <OF9F3F6BF7.0C0BA6F1-ON87256B56.00784692@internet.ny.fdms.firstdata.com> <v03110714b885de3590d1@[209.86.1.241]>
Message-ID: <20020205231835.GD31861@countersiege.com>

On Tue, Feb 05, 2002 at 11:16:40AM -0800, Bill Frantz wrote:
> I expect you could initialize the random data in that memory during
> manufacture with little loss of real security.  (If you are concerned about
> the card's manufacturer, then you have bigger problems.  If anyone does,
> the manufacturer has the necessary equipment to extract data from secret
> parts of the card, install Trojans etc.)

"They say a secret is something you tell one other person"
  -- U2, "The Fly"

While it is true that most users of smartcards will choose to simply
trust the manufacturer, paranoid users could use a n choose m type of
approach to achieve a certain level of assurance. In most cases
verifying that a card is trojan free is a destructive process, so the
user would test a relatively low percentage of cards and make the
penalty for cheating high enough to ensure that the manufacturer stays
honest.

Having the manufacturer provide the random data changes the burden of
proof drastically - there is no way for to _prove_ that they did not
retain a copy of the random data, while it can be proved that they did
not try to cheat simply by testing all the cards.

Additionally, if the manufacturer is providing the secrets on the card
it appers that one weakens the non-repudiation property of signatures
derived from this secret. 

All in all, it seems like manufacturer provided secrets are not a Good
Thing(tm). The whole idea with smartcards is that _nobody_ knows the
secrets, right? 

-Ryan

-- 
Ryan T. McBride, CISSP - mcbride at countersiege.com
Countersiege Systems Corporation - http://www.countersiege.com
PGP key fingerprint = 645D 30F3 6A3A A4FD 2B95  3EF3 10AD D8C8 834B 6CEE

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From josh at untruth.org  Tue Feb  5 19:37:54 2002
From: josh at untruth.org (Joshua Hill)
Date: Tue, 5 Feb 2002 16:37:54 -0800
Subject: Welome to the Internet, here's your private key
In-Reply-To: <4.3.1.2.20020206092333.01d3fdc0@127.0.0.1>; from ggr@qualcomm.com on Wed, Feb 06, 2002 at 10:06:46AM +1100
References: <4.3.1.2.20020205125907.01e043f8@127.0.0.1> <Pine.LNX.3.96L.1020205152424.3122B-100000@tux08.cs.wisc.ed u> <4.3.1.2.20020206092333.01d3fdc0@127.0.0.1>
Message-ID: <20020205163754.A18976@delusion.private.untruth.org>

On Wed, Feb 06, 2002 at 10:06:46AM +1100, Greg Rose wrote:
> At this point I am detecting a pattern... So, I'm afraid it isn't true that 
> it will pick up even these simple linear sequences. (An LFSR of length 12 
> only generates 4095 bits, repeated about 5 times!) I find this less 
> surprising, actually. LFSR output "looks" random in some more fundamental 
> sense.

The FIPS 140 statistical tests are not designed to be used to test the
'goodness' of a design.  (That is not what the self-tests in a FIPS
module are there for, in general)  It is assumed that the implemented
PRNG (Deterministic RNG in FIPS 140-2 parlance) has been evaluated to
verify that it is one of the approved algorithms.  These algorithms
have already undergone extensive design analysis, including extensive
statistical analysis.

In a FIPS module, the statistical random number generator tests
are present to verify that nothing has gone horribly, horribly awry.
Think of it as one step better than the continuous random number generator
conditional test (which, BTW, will pass outputs that simply alternate
between two values).

Ok, so what about _true_ RNGs? (Non-Deterministic RNGs, in FIPS 140-2
parlance)  Well, you're only allowed to use "approved" designs to produce
keys and provide inputs to key exchange/agreement protocols.  (Note that
the _design_ analysis has to occur as a separate process leading up to
the design's approval). At the moment, there aren't any approved designs.
(Ok, in truth, there just aren't any publicly available.  You are allowed
to use any Non-Deterministic RNG approved for Classified use)

If you're trying to do a _design_ analysis, you need to use a set of
tests considerably more extensive than the FIPS 140 Statistical tests.
If you're just testing to see if your particular piece of hardware has
failed, it works reasonably well.

				Josh

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From geer at world.std.com  Tue Feb  5 20:59:08 2002
From: geer at world.std.com (Dan Geer)
Date: Tue, 05 Feb 2002 20:59:08 -0500
Subject: biometrics 
In-Reply-To: Your message of "Sun, 27 Jan 2002 13:56:13 EST."
             <4.3.1.2.20020127134743.01dae6c8@127.0.0.1> 
Message-ID: <200202060159.UAA23494@world.std.com>


|    At 07:59 PM 1/26/2002 -0500, Scott Guthery wrote:
|    >(A test GSM authentication algorithm, COMP128, was attacked
|    >but it is not used in any large GSM networks.  And it
|    >was the algorithm not the SIM that was attacked.)
|    
|    and at "Sun, 27 Jan 2002 13:56:13 EST." Greg Rose answered:
|    There are two problems with this statement. The first is that while
|    COMP128 was a "demonstration" (not "test") algorithm, it turns out
|    that well over half of the deployed GSM systems do in fact use it.
|    And there is a very interesting paper coming soon to a conference
|    but the program hasn't yet been announced, so I can't yet say any
|    more, but it attacks the SIM. Ross Anderson and Markus Kuhn and
|    their group at Cambridge have done some very impressive work on
|    getting secrets out of SIMs and smartcards in general.

The "if you knew what I knew" thing always encourages me to,
shall we say, write, but notwithstanding that, Ross and Markus,
as much as I admire them, are not exactly scalable as attack
tools.  Perhaps it is because of my workaday preoccupation with
helping the user community spend economically rational amounts
of money for economically rational amounts of security, but
unless someone is about to can Ross_&_Markus in a script and
put that on IRC for our everlasting global amusement, I'd score
Round One for Scott.

Best,

--dan


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From bram at gawth.com  Tue Feb  5 23:33:40 2002
From: bram at gawth.com (Bram Cohen)
Date: Tue, 5 Feb 2002 20:33:40 -0800 (PST)
Subject: CodeCon schedule announced, deadline for preregistration approaching
Message-ID: <Pine.LNX.4.21.0202052033250.4864-100000@ultra.gawth.com>

CodeCon's schedule has now been announced, see
http://codecon.org/schedule.html

Registration is $50 online before Feb. 7th. A $15 late fee will be charged
at the door. CodeCon will be held Feb 15-17, Noon-5pm at DNA Lounge in San
Francisco.

There will be a PGP key signing which requires some advance preparation
for participation, see http://codecon.org/program.html#keys

Presentations will include -

    * Peek-A-Booty - a distributed anti-censorship application
    * Invisible IRC Project - secure, anonymous client/server networks
    * Idel - lightweight mobile code for p2p cpu sharing
    * Reptile - a distributed but uniform content exchange mechanism
    * MNet - a universal shared filestore
    * Alpine - a social discovery mechanism which can handle high churn
        rates, malicious peers, and limited bandwidth
    * Eikon - an image search engine
    * CryptoMail - encrypted email for all
    * libfreenet - a case study in horrors incomprehensible to the mind of
        man, and other secure protocol design mistakes
    * BitTorrent - hosting large, popular files cheaply


-Bram Cohen

"Markets can remain irrational longer than you can remain solvent"
                                        -- John Maynard Keynes



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From geer at world.std.com  Wed Feb  6 00:16:09 2002
From: geer at world.std.com (Dan Geer)
Date: Wed, 06 Feb 2002 00:16:09 -0500
Subject: biometrics 
In-Reply-To: Your message of "Tue, 29 Jan 2002 15:12:20 EST."
             <OF600202B2.670E3EBB-ON87256B50.007958F4@internet.ny.fdms.firstdata.com> 
Message-ID: <200202060516.AAA26191@world.std.com>


    
>   In the article they repeat the recommendation that you never
>   use/register the same shared-secret in different domains ... for
>   every environment you are involved with ... you have to choose a
>   different shared-secret. One of the issues of biometrics as a
>   "shared-secret password" (as opposed to the interface between you
>   and your chipcard) is that you could very quickly run out of
>   different, unique body parts.

Compare and contrast, please, with the market's overwhelming
desire for single-sign-on (SSO).  Put differently, would the
actual emergence of an actual SSO signal a market failure by
the above analysis?

--dan


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From cme at acm.org  Wed Feb  6 00:19:53 2002
From: cme at acm.org (Carl Ellison)
Date: Tue, 05 Feb 2002 21:19:53 -0800
Subject: Welome to the Internet, here's your private key
In-Reply-To: <wuxt1htz.fsf@smtp.xs4all.nl>
References: <200202031409.DAA01058@ruru.cs.auckland.ac.nz>
 <200202031409.DAA01058@ruru.cs.auckland.ac.nz>
Message-ID: <3.0.5.32.20020205211953.01c4d920@localhost>

At 02:45 PM 2/4/2002 +0100, Jaap-Henk Hoepman wrote:
>
>It's worse: it's even accepted practice among certain security
>specialists. One of them involved in the development of a CA service
>once told me that they intended the CA to generate the key pair.
>After regaining consciousness I asked him why he thought violating
>one of the main principles of public key cryptography was a good
>idea. His answer basically ran as follows: if the CA is going to be
>liable, they want to be sure the key is strong and not
>compromised. He said that the PC platform of an ordinary user simply
>wasn't secure/trusted enough to generate keys on. The system might
>not generate `good enough' randomness, or might have been
>compromised by a trojan.

That's such wonderful logic.  For people like that, I offer

	http://world.std.com/~cme/html/padlock.html

 - Carl



+------------------------------------------------------------------+
|Carl M. Ellison         cme at acm.org     http://world.std.com/~cme |
|    PGP: 08FF BA05 599B 49D2  23C6 6FFD 36BA D342                 |
+--Officer, officer, arrest that man. He's whistling a dirty song.-+

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From wouter at yourcreativesolutions.nl  Wed Feb  6 02:10:49 2002
From: wouter at yourcreativesolutions.nl (Wouter Slegers)
Date: Wed, 6 Feb 2002 08:10:49 +0100
Subject: Welome to the Internet, here's your private key
In-Reply-To: <20020205231835.GD31861@countersiege.com>; from mcbride@countersiege.com on Tue, Feb 05, 2002 at 06:18:35PM -0500
References: <OF9F3F6BF7.0C0BA6F1-ON87256B56.00784692@internet.ny.fdms.firstdata.com> <OF9F3F6BF7.0C0BA6F1-ON87256B56.00784692@internet.ny.fdms.firstdata.com> <v03110714b885de3590d1@[209.86.1.241]> <20020205231835.GD31861@countersiege.com>
Message-ID: <20020206081049.B27462@tornado-openbsd.internal.yourcreativesolutions.nl>

On Tue, Feb 05, 2002 at 06:18:35PM -0500, Ryan McBride wrote:
> Having the manufacturer provide the random data changes the burden of
> proof drastically - there is no way for to _prove_ that they did not
> retain a copy of the random data, while it can be proved that they did
> not try to cheat simply by testing all the cards.
If all of the random data is provided by the manufacturer, this is a
good point. However you can use such random data to strengthen the
security if the card contains no, or an untrustworthy, random generator
by using the manufaturers randomness as a seed or encryption key for the
generator part (in Yarrow style random generators). 
If done correctly, this makes the output at least as random (or more
specificly: unpredictable) as the minimum of the sources. With
non-random seeding data (e.g. manufacturing fault or foul play) the
security of such a scheme against attacks by the manufacturer is as low
as it was before, but against others still high.
Of course, if you can keep some random pool on the chip, you can keep
mixing in randomness from sessions, which will make an attack on the
random generator much less interesting. A backdoor is then more
interesting for a rogue manufacturer.

> Additionally, if the manufacturer is providing the secrets on the card
> it appers that one weakens the non-repudiation property of signatures
> derived from this secret. 
> 
> All in all, it seems like manufacturer provided secrets are not a Good
> Thing(tm).
Only if they are the _only_ randoms provided. For seeding the random
generater I think they are a Good Thing(tm)

> The whole idea with smartcards is that _nobody_ knows the secrets,
> right? 
For non-repudiation, nobody must be able to duplicate the secrets, with
or without seeing it. A secure cloning operation (such as many of the
HSM SSL-cards provide) is also not allowed.

With kind regards,
Wouter Slegers

-- 
Wouter Slegers
Your Creative Solutions
"Security solutions you can trust and verify."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20020206/05967ffa/attachment.pgp>

From pgut001 at cs.auckland.ac.nz  Wed Feb  6 10:41:11 2002
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Thu, 7 Feb 2002 04:41:11 +1300 (NZDT)
Subject: Welome to the Internet, here's your private key
Message-ID: <200202061541.EAA85130@ruru.cs.auckland.ac.nz>

Jaap-Henk Hoepman <hoepman at cs.utwente.nl> writes:

>It's worse: it's even accepted practice among certain security specialists.
>One of them involved in the development of a CA service once told me that they
>intended the CA to generate the key pair. After regaining consciousness I
>asked him why he thought violating one of the main principles of public key
>cryptography was a good idea. His answer basically ran as follows: if the CA
>is going to be liable, they want to be sure the key is strong and not
>compromised. He said that the PC platform of an ordinary user simply wasn't
>secure/trusted enough to generate keys on. The system might not generate `good
>enough' randomness, or might have been compromised by a trojan.

I've seen similar things.  The CAs are so worried about key security that they
insist on generating the things themselves, but then hand them over in PKCS #12
format from which they're shared by, and easily accessible to, every single app
running on the machine, are copied across other machines (because it's valuable
enough that you don't want to have to get a new one for each machine), etc etc
(again, I go into this in some detail in my paper in the section titled
"Private keys aren't").

Some of the, uh, logic applied by CAs for cert management can lead to really
bizarre situations.  For example there's a public CA which password-protects
access to its CRLs, using the reasoning that anyone who can get access to a CRL
can determine which keys have been compromised, and that's a bad thing (isn't
that what a CRL is for?).  As a result, anyone can get access to the certs the
CA issues, but only a tiny, select few can check whether they've been revoked
or not (given that most apps just ignore revocation checking, this probably
isn't as serious as it sounds).  There's a list of silliness as long as a very
long thing when it comes to working with certs...

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From pgut001 at cs.auckland.ac.nz  Wed Feb  6 11:15:18 2002
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Thu, 7 Feb 2002 05:15:18 +1300 (NZDT)
Subject: Welome to the Internet, here's your private key
Message-ID: <200202061615.FAA85774@ruru.cs.auckland.ac.nz>

Greg Rose <ggr at qualcomm.com> writes:

>The scariest thing, though... at first I put in an unkeyed RC4 generator for
>the self-test data, but accidentally ran the FIPS test on a straight counter
>output... and it passed (even version 1)! I'd always assumed that something in
>the regularity of a counter would trigger it. Running through the buffer,
>XORing consecutive bytes, makes it fail quite handily, but might also have the
>undesirable effect of hiding a bias in the data, if there was one. I'm thinking
>of suggesting to NIST that a stronger test would be to run the test on the raw
>data, and then on the data after XORing consecutive bytes... if it's really
>random stuff it should pass both, and in the meantime this would catch all
>sorts of failures. Any comments?

General-purpose data compressors (which make rather nice entropy estimators)
also have problems with counting events.  The Calgary compression corpus (the
Dhrystone of the compression world) includes a file geo in which every fourth
byte is a zero.  No standard compressor will pick this up, so that while they
all realise that zeroes occur with ~25% probability, they don't realise that
they always occur at every fourth byte (alongside a few others in between).
There will always be data patterns which appear obvious to a human but aren't
easily picked up by automated tests, so I don't know how far it's worth chasing
this thing.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From pgut001 at cs.auckland.ac.nz  Wed Feb  6 10:54:00 2002
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Thu, 7 Feb 2002 04:54:00 +1300 (NZDT)
Subject: Welome to the Internet, here's your private key
Message-ID: <200202061554.EAA85223@ruru.cs.auckland.ac.nz>

"Trei, Peter" <ptrei at rsasecurity.com> writes:

>One other scheme I've seen, and which, while it doesn't give me warm fuzzies,
>seems reasonable, is to issue the the enduser a smartcard with a keypair on
>it. The SC generates the pair onboard, and exports only the public half. The
>private half never leaves the SC (there is no function on the card to export
>it).
>
>If you trust the above, then the only copy of the private key is on the SC,
>despite it having been generated without the end users participation.

This also causes problems, because it's really, really hard to spread the key
around if the only copy is on the card.  Solutions I've seen are to multiplex a
single card + reader across multiple machines, or (more commonly) to generate
the key in software and then load it onto the card, with copies kept active on
the host PC.  This combines the benefits of smart card security and the
flexibility of software crypto keys which can be copied and distributed as
required.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ptrei at rsasecurity.com  Wed Feb  6 11:12:20 2002
From: ptrei at rsasecurity.com (Trei, Peter)
Date: Wed, 6 Feb 2002 11:12:20 -0500 
Subject: Welome to the Internet, here's your private key
Message-ID: <F504A8CEE925D411AF4A00508B8BE90A01E90C16@exna07.securitydynamics.com>

> pgut001 at cs.auckland.ac.nz[SMTP:pgut001 at cs.auckland.ac.nz]
> 
> 
> "Trei, Peter" <ptrei at rsasecurity.com> writes:
> 
> >One other scheme I've seen, and which, while it doesn't give me warm
> fuzzies,
> >seems reasonable, is to issue the the enduser a smartcard with a keypair
> on
> >it. The SC generates the pair onboard, and exports only the public half.
> The
> >private half never leaves the SC (there is no function on the card to
> export
> >it).
> >
> >If you trust the above, then the only copy of the private key is on the
> SC,
> >despite it having been generated without the end users participation.
> 
> This also causes problems, because it's really, really hard to spread the
> key
> around if the only copy is on the card.  Solutions I've seen are to
> multiplex a
> single card + reader across multiple machines, or (more commonly) to
> generate
> the key in software and then load it onto the card, with copies kept
> active on
> the host PC.  This combines the benefits of smart card security and the
> flexibility of software crypto keys which can be copied and distributed as
> required.
> 
> Peter.
> 
We're generally talking about a 'is a person' or an 'is an employee' key, in
an enterprise situation. Having a single copy of the private key is usually
acceptable. If it's lost/destroyed then a new one can be issued. Since it's
so closely bound to a single person (typically for access/ email or Single 
Signon applications), having a private key that can't operate without the
presence
of the owner (and the card) is usually a feature, not a bug.

Peter T


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From jya at pipeline.com  Wed Feb  6 14:25:16 2002
From: jya at pipeline.com (John Young)
Date: Wed, 06 Feb 2002 11:25:16 -0800
Subject: Conversation: Siva Vaidhyanathan -- Life in a Distributed Age
Message-ID: <E16YV0Y-00059c-00@granger.mail.mindspring.net>

http://www.law.nyu.edu/ili/events.html

Conversation: Siva Vaidhyanathan -- Life in a Distributed Age

Wednesday, February 6, 2002
5:30 PM
room: 210
Vanderbilt Hall
40 Washington Square South
New York, NY 10012

The Information Law Institute presents a lecture by Siva Vaidhyanathan, 
author of "Copyrights and Copywrongs: The Rise of Intellectual Property 
and How It Threatens Creativity." The talk will examine a series of conflicts
between models of distributed information and centralized information 
regulation. The Napster battle serves as the first case study. It then 
considers a series of seemingly disparate examples of similar tensions 
and clashes, including encryption, secrecy, privacy, and security. The 
talk argues that we must take a systemic view of such conflicts and 
discuss ways to preserve democratic processes that depend on 
relatively open information systems. The presentation will be followed 
by a discussion with Helen Nissenbaum and members of the
audience.
_____

Cryptome/Cartome will cover this event. If you attend hit us up for free
drink and food afterward.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From amir at beesites.co.il  Wed Feb  6 10:34:42 2002
From: amir at beesites.co.il (Amir Herzberg)
Date: Wed, 6 Feb 2002 17:34:42 +0200
Subject: Cringely ...or- long-lasting encryption - motivation for ECC? 
In-Reply-To: <kjit9bhpso.fsf@romeo.rtfm.com>
Message-ID: <000001c1af23$d432cde0$323cfea9@newgenpay>

Eric Rescola [ER] replied to Eugene Leitl [EL]: 
...
> > EL:
> > Personally, I no longer trust RSA for long term security.
> >
> > This is public-key crypto, not symmetric, so a break of your RSA key
> > means that all your encrypted traffic becomes readable rather than
> > just one message.  E.g., if a few years ago you used 512-bit RSA to
> > encrypt a will that was not to be read by anybody until you die,
> > that's tough because it could be read today.  Doesn't matter that
you
> > moved to 768 bits and then 1024 in the meantime.
> If you care about Perfect Forward Secrecy, you shouldn't be using
> RSA at all. You should be using DH with a fresh key for each
> exchange. The probability that in the next 50 years your key will
> be compromised in some other way than factoring is sufficiently
> high to motivate this tactic. (In my view, it's vastly higher
> than that of your key being broken by factoring).

Correct... and furthermore - this only dealt with transmitting the
encrypted (and signed?) will, presumably to a trusted lawyer (or other
trusted party). I would also be more concerned about the risk that the
lawyer/party will be  corrupted (by software or otherwise...) within the
50 years. Again the solution has nothing to do with ECC vs. RSA... 

This is a bit besides the original debate but let me quickly recall the
three main techniques I know of protecting such a long-lasting secret
data:

-- Tamper-resistant hardware
-- Splitting the data (or a strong symmetric key with which the data is
encrypted) among several secure storage units (secret sharing)
-- The same, but proactively re-hashing the shares periodically, so that
an attacker must collect all shares during the same period (proactive
secret sharing). 
 
Regards, 

Amir Herzberg
See http://amir.beesites.co.il/book.html for lectures and draft-chapters
from `secure communication and commerce using cryptography`; feedback
welcome!


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From pgut001 at cs.auckland.ac.nz  Wed Feb  6 11:55:27 2002
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Thu, 7 Feb 2002 05:55:27 +1300 (NZDT)
Subject: Welome to the Internet, here's your private key
Message-ID: <200202061655.FAA86528@ruru.cs.auckland.ac.nz>

Greg Rose <ggr at qualcomm.com> writes:

>While priming the RC4 table, I accidentally filled the data buffer instead
>(D'oh!) with consecutive byte values 0x00, 0x01, ... 0xFF, 0x00, ...
>
>This very much passes the FIPS 140 tests for randomness, despite being nothing
>like it:

A generic order-0 entropy estimator (think Huffman coder) will pass this,
because each symbol occurs with equal probability.  The reason this is a
problem is because any introductory information theory text will give the
standard formula for entropy estimation (H = -sum(prob(x) * log( prob(x)))) and
users will either stop reading there or the text won't go any further.  I've
seen a (fielded) crypto RNG which uses this sort of estimator, which won't
catch a whole pile of failure modes which the FIPS tests would get.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Wed Feb  6 12:11:02 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 6 Feb 2002 12:11:02 -0500
Subject: "One Card to Rule Them All..." Not?
Message-ID: <p05100318b88713d78e0b@[10.0.1.2]>

http://www.usatoday.com/life/cyber/tech/review/2002/2/06/smartcard.htm




02/05/2002 - Updated 08:53 PM ET


One smart card for all your debts

By Edward C. Baig, USA TODAY

The annual Demo conference that kicks off in Phoenix next week may be the
most influential high-tech gabfest you've probably never heard of. But Demo
is very much on the radar screen of technology luminaries across the
spectrum - executives, financial analysts, venture capitalists and the
press.

No wonder. Demo has been the launching pad for everything from E*Trade to
the PalmPilot. And though most of the 66 new products and services are
being kept under wraps until the conference opens Sunday, this year's event
will flaunt advances in battery technology and computer displays, along
with new features for Microsoft's Tablet PC. I'll elaborate on the
goings-on at Demo in next week's column.

But for now, here's a sneak peek at one new technology that will surely
appeal to anyone whose wallet bulges from carrying too many credit cards: A
San Francisco company called PrivaSys will demonstrate a battery-powered
electronic credit card with an internal chip capable of holding, say, an
American Express, MasterCard and Visa - plus your debit cards, gas cards
and all other accounts - on a single piece of plastic identical in size and
shape to your other cards. Of course, PrivaSys is quick to point out that a
whole lot of complicated industry association issues must be dealt with
before each of the various financial institutions could appear on such a
card. (PrivaSys has struck a deal with First Data, the largest credit card
processor.) Merchants, by the way, need not change point-of-sale magnetic
stripe terminals.

For security purposes, whenever a consumer wants to conduct a transaction,
he or she punches in a PIN directly on the card's built-in keypad,
generating a code unique to the sale. The plastic includes a 10- to
16-digit readout for displaying credit card information and to let folks
select the appropriate charge account to use at the store - you push arrow
keys on the keypad to scroll through the list of accounts held on the card.
The cards also will be able to store "loyalty" account info, allowing
instant coupons and other rewards, perhaps a free soft drink in a fast-food
restaurant or an upgrade to first class when seats are available. An icon
on the card's readout may light up when you earn such an award.


Front Page News Money Sports Life Tech Weather Shop
Terms of service Privacy Policy How to advertise About us
? Copyright 2002 USA TODAY, a division of Gannett Co. Inc.

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From reinhold at world.std.com  Wed Feb  6 09:37:06 2002
From: reinhold at world.std.com (Arnold G. Reinhold)
Date: Wed, 6 Feb 2002 09:37:06 -0500
Subject: Welome to the Internet, here's your private key
In-Reply-To: <20020205231835.GD31861@countersiege.com>
References:  <OF9F3F6BF7.0C0BA6F1-ON87256B56.00784692@internet.ny.fdms.firstdata.com>
 <OF9F3F6BF7.0C0BA6F1-ON87256B56.00784692@internet.ny.fdms.firstdata.com>
 <v03110714b885de3590d1@[209.86.1.241]>
 <20020205231835.GD31861@countersiege.com>
Message-ID: <v0421010cb886eb980130@[192.168.0.2]>

At 6:18 PM -0500 2/5/02, Ryan McBride wrote:
>On Tue, Feb 05, 2002 at 11:16:40AM -0800, Bill Frantz wrote:
>> I expect you could initialize the random data in that memory during
>> manufacture with little loss of real security.  (If you are concerned about
>> the card's manufacturer, then you have bigger problems.  If anyone does,
>> the manufacturer has the necessary equipment to extract data from secret
>> parts of the card, install Trojans etc.)
>
>"They say a secret is something you tell one other person"
>  -- U2, "The Fly"
>
>While it is true that most users of smartcards will choose to simply
>trust the manufacturer, paranoid users could use a n choose m type of
>approach to achieve a certain level of assurance. In most cases
>verifying that a card is trojan free is a destructive process, so the
>user would test a relatively low percentage of cards and make the
>penalty for cheating high enough to ensure that the manufacturer stays
>honest.

One criteria for a cryptographic system that is rarely mentioned is 
auditability. To the maximum extent possible users should be able to 
verify every component of the system that affects security. We have 
gotten too used to systems so bloated that they no one can know 
what's in them. There are historic reasons for this but that is no 
excuse. Finding out how to simplify systems is far more important 
today than designing the next great cipher.  A great virtue of doing 
all crypto on a smart card is that they can be verified, at least 
with some effort.


>Having the manufacturer provide the random data changes the burden of
>proof drastically - there is no way for to _prove_ that they did not
>retain a copy of the random data, while it can be proved that they did
>not try to cheat simply by testing all the cards.

And creates a potential legal liability  for the smart card 
manufacturer. This gets to the original question of this thread. I 
wonder why the CA's lawyers let them generate private keys 
themselves. If it ever came out that private keys were misused by CA 
employees or even someone who penetrated their security, they would 
be legally defenseless, all the gobbledygook in their practice 
statements not withstanding. There is no good business reason for a 
CA to generate private keys and very powerful business reasons for 
them not to.


Arnold Reinhold

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ben at algroup.co.uk  Wed Feb  6 14:29:21 2002
From: ben at algroup.co.uk (Ben Laurie)
Date: Wed, 06 Feb 2002 19:29:21 +0000
Subject: biometrics
References: <200202060516.AAA26191@world.std.com>
Message-ID: <3C618411.B4B58750@algroup.co.uk>

Dan Geer wrote:
> 
> 
> >   In the article they repeat the recommendation that you never
> >   use/register the same shared-secret in different domains ... for
> >   every environment you are involved with ... you have to choose a
> >   different shared-secret. One of the issues of biometrics as a
> >   "shared-secret password" (as opposed to the interface between you
> >   and your chipcard) is that you could very quickly run out of
> >   different, unique body parts.
> 
> Compare and contrast, please, with the market's overwhelming
> desire for single-sign-on (SSO).  Put differently, would the
> actual emergence of an actual SSO signal a market failure by
> the above analysis?

Surely the point about (good) SSO is that you control the domain you
share secrets with and that domain then certifies you to other domains -
thus avoiding the problem of sharing your secrets across domains.

Cheers,

Ben.

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

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ggr at qualcomm.com  Wed Feb  6 14:56:36 2002
From: ggr at qualcomm.com (Greg Rose)
Date: Thu, 07 Feb 2002 06:56:36 +1100
Subject: Welome to the Internet, here's your private key
In-Reply-To: <200202061655.FAA86528@ruru.cs.auckland.ac.nz>
Message-ID: <4.3.1.2.20020207065358.01e5a9f8@127.0.0.1>

At 05:55 AM 2/7/2002 +1300, Peter Gutmann wrote:
>Greg Rose <ggr at qualcomm.com> writes:
>
> >While priming the RC4 table, I accidentally filled the data buffer instead
> >(D'oh!) with consecutive byte values 0x00, 0x01, ... 0xFF, 0x00, ...
> >
> >This very much passes the FIPS 140 tests for randomness, despite being 
> nothing
> >like it:
>
>A generic order-0 entropy estimator (think Huffman coder) will pass this,
>because each symbol occurs with equal probability.  The reason this is a
>problem is because any introductory information theory text will give the
>standard formula for entropy estimation (H = -sum(prob(x) * log( 
>prob(x)))) and
>users will either stop reading there or the text won't go any further.

But it is interesting that, had the FIPS test worked on a multiple of 256 
bytes, it would have caught it, because it uses a two-sided ChiSquare test. 
In other words, perfect frequency distribution (of nybbles) is also 
something it will reject... but it wasn't perfect because a sequence 
stopped early.

Greg.

Greg Rose                                       INTERNET: ggr at qualcomm.com
Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,                http://people.qualcomm.com/ggr/
Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From hh at hackhawk.net  Wed Feb  6 17:14:55 2002
From: hh at hackhawk.net (Hack Hawk)
Date: Wed, 06 Feb 2002 14:14:55 -0800
Subject: Government, Industry Claim DMCA Not a Threat to Science?  HUH?
Message-ID: <5.0.2.1.0.20020206141213.02f328d0@localhost>

Huh?  Take their word for it?  What are they talking about?  Looks like the 
DMCA will remain with us even longer now.  Why aren't the big cases being 
tried all the way to the Supreme Court?!  Damn the recording industry!

http://www.eff.org/IP/DMCA/Felten_v_RIAA/20020206_eff_felten_pr.html

- hawk


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rick_smith at securecomputing.com  Wed Feb  6 17:37:28 2002
From: rick_smith at securecomputing.com (Rick Smith at Secure Computing)
Date: Wed, 06 Feb 2002 16:37:28 -0600
Subject: Welome to the Internet, here's your private key
In-Reply-To: <5.0.2.1.1.20020204100214.030b6280@idiom.com>
References: <F504A8CEE925D411AF4A00508B8BE90A01E90C05@exna07.securitydy namics.com>
Message-ID: <5.1.0.14.0.20020206163055.01f3efd0@[192.168.12.25]>

At 12:20 PM 2/4/2002, Bill Stewart wrote:

>A smartcard-only system probably _is_ too limited to generate keys,
>but that's the only realistic case I see.

Here are some manufacturer claims for the DataKey 330 smart card: average 
of 23 seconds to generate a 1,024-bit RSA key, average of 3 minutes to 
generate a 2,048-bit RSA key.

In practice this becomes one of those "installing something new" delays on 
your computer. You stick the smart card into the reader and watch the watch 
dial spin or the hourglass or whatever. Once it's done, the thing is 
"installed" and you're ready to go. Unsophisticated users may worry that 
they'll face the same delay the next time it's plugged in, but presumably 
people will learn from experience.

Of course, you don't want to use such a key to protect a set of closely 
held encryption keys that protect critical data, since you'll lose the data 
if the smart card gets damaged or breaks down.


Rick.
smith at securecomputing.com            roseville, minnesota
"Authentication" in bookstores http://www.visi.com/crypto/


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From marius.corbu at analog.com  Wed Feb  6 19:36:49 2002
From: marius.corbu at analog.com (marius)
Date: Wed, 06 Feb 2002 16:36:49 -0800
Subject: Losing the Code War by Stephen Budiansky
References: <F504A8CEE925D411AF4A00508B8BE90A01E90C03@exna07.securitydynamics.com> <20020204093816.A12537@delusion.private.untruth.org>
Message-ID: <3C61CC21.D515A99@analog.com>

Joshua Hill wrote:
> 
> marius wrote:
> > Not quite true. Encrypting each message twice would not increase the
> > "effective" key size to 112 bits.
> > There is an attack named "meet in the middle" which will make the
> > effective key size to be just 63 bits.
> 
> Peter Trei wrote:
> > Don't forget that the MITM attack (which Schneier claims
> > takes 2^(2n) = 2^112 time), also requires 2^56 blocks
> > of storage.
> [...]
> > I don't lose sleep over MITM attacks on 3DES.
> 
> Unless I'm mistaken, the 2^63 operation MITM attack referenced in the
> original message referred to Double-DES, not Triple-DES.  The original
> cited value of 2^63 is incorrect; the Double-DES MITM attack (as proposed
> by Merkle and Hellman) is a known plaintext attack that takes 2^57
> operations, with 2^56 blocks of storage.
> 
> Your provided values are correct for attacking Triple-DES, but I don't
> think that's what the original author was referring to.
> 
>                                 Josh

2^57 operations, with 2^56 blocks of storage manipulation can be
approximated to: 2^56 * log(2^56) + 2^56 * log(2^56) = 2^62 + 2^62 =
2^63

Betting on storage as a show stopper is not a good idea, regardless of
sleep pattern.

Marius

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From yeoh at cs.wisc.edu  Wed Feb  6 20:29:04 2002
From: yeoh at cs.wisc.edu (Kim-Ee Yeoh)
Date: Wed, 6 Feb 2002 19:29:04 -0600 (CST)
Subject: Welome to the Internet, here's your private key
In-Reply-To: <4.3.1.2.20020206092333.01d3fdc0@127.0.0.1>
Message-ID: <Pine.LNX.3.96L.1020206145143.3566C-100000@tux08.cs.wisc.edu>

On Wed, 6 Feb 2002, Greg Rose wrote:

> At 03:48 PM 2/5/2002 -0600, Kim-Ee Yeoh wrote:
>
> >Could you clarify what you mean by "counter output"?  Are we talking about
> >a sequence of consecutive 8-, 16-, or 32-bit numbers?  If so, FIPS will
> >detect and flunk such sequences.
> 
> While priming the RC4 table, I accidentally filled the data buffer instead 
> (D'oh!) with consecutive byte values 0x00, 0x01, ... 0xFF, 0x00, ...
> 
> This very much passes the FIPS 140 tests for randomness, despite being 
> nothing like it:
>	<statistics snipped>

For 16-bit or 32-bit sequences of consecutive numbers starting with 0,
FIPS easily flunks them because there are too many gaps (consecutive runs
of zeroes). 

And if the runs test in FIPS were slightly extended, your sequence of
consecutive 8-bit numbers would have been easily caught too.  Here's the
full spectrum of runs for your sequence:

	Run-length	# of gaps	# of blocks
	==========	=========	===========
	1		2497		2529
	2		1252    	1255
	3		 628    	 621
	4		 317    	 307
	5		 159    	 152
	6		  80    	  75
	7		  70    	   0
	8		   0    	  74
	9-14		   0    	   0
	15		  10    	   0
	16 and up	   0    	   0

That there are 70 gaps of length exactly 7 but no blocks at all of the
same length is extremely anomalous behavior for the output of a putative
RNG.  Extending the runs test from 6 to 8 categories, i.e. counting blocks
and gaps for run-lengths of exactly 1 to 7 and for run-lengths of 8 and
greater, would easily have caught this.

I will even go further as to quantify what I mean by "extremely anomalous
behavior."  The expected number of blocks (or gaps) of length exactly p in
a uniformly random n-bit sequence is e(n,p) = (n-p+3)/2^(p+2) with a
variance of v(n,p) = (3*p^2-2*n*p-8*p+n-3)/2^(2*p+4) + e(n,p), a result
that can be shown without too much difficulty.  As n tends toward
infinity, the distribution in the limit is Gaussian (see Knuth V2 3E p69).
The probability that a uniformly random 20000-bit sequence has no blocks
of length 7 is no more than 2.1 * 10^(-10), several orders of magnitude
lower than the one-in-a-million threshold at which the FIPS tests are
calibrated.

> Up to LFSR length 8, there are too few runs of length 6 or greater, so they 
> must fail. LFSR Length 9 fails the low end of the chi-squared test... too 
> evenly distributed. (Note that the counter above only passes this because 
> it cuts off in the middle of a byte count, and so skews away from the 
> one-heavy end of the spectrum). Hmmm... a table is required. (I'm using the 
> first polynomial specified in Schneier of each length, impulse sequence:
> $ lfsr -n 20000 16 5 3 2 | binbin | fips140)

As you have noted, simple LFSRs are easily detected by FIPS.  LFSRs of
longer period can be detected by using both a larger sample and analyzing
the full, rather than the truncated, runs spectrum.  Alternatively, if you
simply want to eliminate any possibility of an LFSR, just apply
Berlekamp-Massey. 

> Poly Length     Description of failure
> -----------     ------------------
> 9               Poker test too regular
> 10              Poker test too regular
> 11              Poker test too regular
> 12              Passes test! (12, 6, 4, 1, 0)
> 13              Passes test! (13, 4, 3, 1, 0)
> 14              Passes test! (14, 5, 3, 1, 0)
> 15              multiple runs test failures (byte alignment too good?),
>                  but passes poker test

You want to recheck your last result.  The primitive binary polynomial
x^15+x+1 with a starting seed of 1 produces a sequence that starts with a
length-14 gap followed by a length-15 block.  The FIPS runs spectrum is:

	Run-length	# of gaps	# of blocks
	==========	=========	===========
	 1		2536    	2514
 	 2		1284    	1250
	 3		 633    	 650
	 4		 310    	 322
	 5		 153    	 157
	 6 and up	 131		 154

FIPS passes the sequence.



Kim-Ee


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ggr at qualcomm.com  Wed Feb  6 22:10:54 2002
From: ggr at qualcomm.com (Greg Rose)
Date: Thu, 07 Feb 2002 14:10:54 +1100
Subject: Welome to the Internet, here's your private key
In-Reply-To: <Pine.LNX.3.96L.1020206145143.3566C-100000@tux08.cs.wisc.ed
 u>
References: <4.3.1.2.20020206092333.01d3fdc0@127.0.0.1>
Message-ID: <4.3.1.2.20020207134341.07880aa0@127.0.0.1>


>And if the runs test in FIPS were slightly extended, your sequence of
>consecutive 8-bit numbers would have been easily caught too.  Here's the
>full spectrum of runs for your sequence:
>
>         Run-length      # of gaps       # of blocks
>         ==========      =========       ===========
>         1               2497            2529
>         2               1252            1255
>         3               628     621
>         4               317     307
>         5               159     152
>         6                 80              75
>         7                 70               0
>         8                  0              74
>         9-14               0               0
>         15                10               0
>         16 and up          0               0
>
>That there are 70 gaps of length exactly 7 but no blocks at all of the
>same length is extremely anomalous behavior for the output of a putative
>RNG.  Extending the runs test from 6 to 8 categories, i.e. counting blocks
>and gaps for run-lengths of exactly 1 to 7 and for run-lengths of 8 and
>greater, would easily have caught this.

Yes, I agree, but it isn't my test, it's just my code for the FIPS test.

>As you have noted, simple LFSRs are easily detected by FIPS.  LFSRs of
>longer period can be detected by using both a larger sample and analyzing
>the full, rather than the truncated, runs spectrum.  Alternatively, if you
>simply want to eliminate any possibility of an LFSR, just apply
>Berlekamp-Massey.

B-M is not something I'd normally recommend to run in power-up tests...

> > 15              multiple runs test failures (byte alignment too good?),
> >                  but passes poker test
>
>You want to recheck your last result.[...]
>FIPS passes the sequence.

Correct, thank you. I've delayed releasing a bunch of my utilities for 
stuff like this because I hadn't yet had time to clean them all up and make 
them consistent... and it turned around and bit me. The "LFSR" program 
outputs ascii 0 or 1... I then used "binbin" to turn it into packed bytes, 
and this program was putting bits into bytes lsb-first. But the FIPS test 
(which originally did lsb-first too, but I was then convinced msb-first was 
"more conventional") didn't agree. It's interesting (but not worth 
pursuing) that simply reversing the bits in the bytes makes it fail the 
test. Anyway, now that I've changed this convention, my results agree with 
yours.

We've probably worn out everyone's interest with this, now. I'm happy to go 
offline with it though.

regards,
Greg.

Greg Rose                                       INTERNET: ggr at qualcomm.com
Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,                http://people.qualcomm.com/ggr/
Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Thu Feb  7 09:04:14 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 7 Feb 2002 09:04:14 -0500
Subject: [ISN] Hacker costs CryptoLogic US$1.3M charge
Message-ID: <p05100333b88839af95fb@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Thu, 7 Feb 2002 01:02:16 -0600 (CST)
From: InfoSec News <isn at c4i.org>
To: isn at attrition.org
Subject: [ISN] Hacker costs CryptoLogic US$1.3M charge
Sender: owner-isn at attrition.org
Reply-To: InfoSec News <isn at c4i.org>

http://www.canada.com/news/story.asp?id={9BAF2BB1-87C1-4725-AF77-9881D5B89E1D}

[This has to be one of the first times I have seen a corporation
listing a hacker attack as a loss on their financial statement.
$1.3 million is no chump change today, all the managers on this list
looking for additional $$$ in their infosec budget should be pointing
this article out when the powers that be think that something like
this will never happen to their company, and that the V.P's really
should have new Herman Miller chairs instead.  - WK]


Paul Vieira
National Post
Tuesday, February 05, 2002

CryptoLogic Inc., a gambling software maker, saw its fourth-quarter
profit drop 10%, largely because it took a charge related to a hacker
attack last August that saw 140 online gamblers pocket winnings of
about US$1.9-million.

The company, in a conference call with analysts yesterday, said it
hopes to recover a good chunk of the illicit gains through an
insurance claim. Nevertheless, it is taking a US$1.3-million charge.
"A prudent approach was necessary," said Jean Nolting, CryptoLogic's
chief executive.

In the span of a couple of hours, a computer hacker broke into
CryptoLogic's Web servers and reprogrammed slot machines and a craps
table at two Web-based casinos that use the company's software.

Slot machine and craps players at the casinos won each time they
played.

The charge pulled down profit for the three-month period ended Dec. 31
to US$3.7-million, or US28? a share, from US$4.1-million (US29?).
Meanwhile, revenue for the quarter increased 15%, to US$11.2-million
from $9.7-million.

Despite the fourth-quarter charge, the company posted higher profit in
2001. For the full fiscal year, CryptoLogic earned US$18.1-million
(US$1.33) on revenue of US$43.5-million, compared with $15.5-million
(US$1.18) on sales of US$34.4-million.

Excluding the writeoff, profit would have been US$4.2-million for the
fourth quarter and US$18.6-million for the year, the company said.

Also, the Toronto firm said it posted profit margin of 45% and has
US$60-million in cash as of the end of 2001.

During its call with analysts, Mr. Nolting said 2002 had the makings
of a "profitable year, with solidly upside potential," especially in
the second half.

For this fiscal year, the company forecasts revenue of US$45-million
to US$50-million and profit between US$17-million and US$20-million.

It expects to hit the "bottom" of the growth curve in the first
quarter.

However, CryptoLogic said U.S. banks' refusal to accept credit card
charges from online gambling sites could hinder growth prospects in
North America. Credit card rejections in the United States jumped 25%
in December as anti-terrorism efforts and the uncertain legality of
online gambling in North America cast a chill over U.S. banks.

Therefore, the company said, it will be examining offshore markets.
"Europe and Asia -- those will be our key areas," Mr. Nolting said.

By the end of the year, it wants half of its revenue to come from
Europe and Asia, the rest from North America. About 65% of its sales
now come from North America.

A key part of its foreign focus will be an online casino to be
operated by Littlewoods, a British-based gambling operator. However,
the launch of Littlewoods.com has been delayed as regulators in the
Isle of Man, where the online casino will be incorporated, want more
information about the software.

But Mr. Nolting said he expected Littlewoods to be in operation by the
end of the first quarter, and to generate up to 10% of total revenue.

Growth in 2002 will also be aided by the release of online versions of
bingo and poker that the company has been developing.



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo at attrition.org with 'unsubscribe isn' in the BODY
of the mail.

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Thu Feb  7 10:01:50 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 7 Feb 2002 10:01:50 -0500
Subject: CertCo Patent Suit Delays PayPal IPO
Message-ID: <p0510033eb88846d9adf6@[10.0.1.2]>

http://www0.mercurycenter.com/business/top/024186.htm

Suit delays eagerly awaited IPO

Posted at 7:05 p.m. PST Wednesday, Feb. 6, 2002
BY DEBORAH LOHSE

Mercury News


PayPal's hotly anticipated initial public offering was delayed this week
after the online payment company was sued over alleged patent infringement.

New York online risk-management company CertCo claimed in a lawsuit filed
Monday in federal court in Delaware that PayPal was violating CertCo's
patent covering electronic payments.

Palo Alto-based PayPal was slated Wednesday night to set a pre-trading
price for 5.4 million shares of its stock, or about 9 percent of the
company's outstanding shares. The expected price range was $12 to $14 a
share. The stock would have begun trading today on the Nasdaq stock market,
using the symbol PYPL.

Despite having racked up $277 million in losses over two years, PayPal had
been generating a great deal of buzz among investors due to its rapid
growth in customers and revenue. Investors had been expected to
significantly bid up shares of PayPal, perhaps making it the first time a
profitless Internet company has popped since the Internet bubble burst in
2000 and burned many investors.

But bankers and PayPal management made the decision Wednesday to hold the
deal, possibly to allow PayPal time to amend its securities documents to
fully disclose the lawsuit to potential investors. A new date for the IPO
hasn't been set.

The lawsuit alleges that the payment and transaction system PayPal uses to
enable customers to send and receive payments electronically violates a
Feb. 2000 patent secured by CertCo, a privately held company.

PayPal's spokesman, Vincent Sollitto, said he couldn't comment on the
lawsuit because of a ``quiet period'' imposed by the Securities and
Exchange Commission on comments before or after an IPO.

Dale Lazar, a lawyer with Pillsbury Winthrop in McLean, Va., who represents
CertCo, said the patent entails a CertCo technology using certain
electronic signals to represent a payment request. ``Our patent covers the
heart of the PayPal payment system,'' he said.

PayPal's SEC IPO document says the company believes it has unique
technology for ``transferring value'' among customers; for detecting fraud,
and for obtaining alternate funding sources if a primary source isn't
available. The company is seeking five patents covering such proprietary
technology, it said.

But the boilerplate risk language in the prospectus reveals the potential
for lawsuits like CertCo's. ``We cannot assure you that our product
features do not infringe on patents held by others or that they will not in
the future.''


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From marcnarc at rsasecurity.com  Thu Feb  7 13:56:09 2002
From: marcnarc at rsasecurity.com (Marc Branchaud)
Date: Thu, 07 Feb 2002 10:56:09 -0800
Subject: SSO (was Re: biometrics)
References: <200202060516.AAA26191@world.std.com>
Message-ID: <3C62CDC9.995DD2F7@rsasecurity.com>


Dan Geer wrote:
> 
> 
> >   In the article they repeat the recommendation that you never
> >   use/register the same shared-secret in different domains
> 
> Compare and contrast, please, with the market's overwhelming
> desire for single-sign-on (SSO).  Put differently, would the
> actual emergence of an actual SSO signal a market failure by
> the above analysis?

In most SSO schemes, the password is only used to authenticate to a single
domain, and (a token attesting to) the fact that the authentication succeded
is passed around to other domains.  The authenticating domain is typically
akin to the user's "home" domain (as opposed to the user just logging into
some arbitrary domain) so the password isn't widely shared.  Most of these
schemes are web-based, and users that first surf to a non-home domain are
redirected (as tranparently as possible) to their local domain for
authentication, and something like an authentication "ticket" is encoded in a
cookie or in a return-redirecting URL.

		M.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From kelm at secorvo.de  Fri Feb  8 03:25:08 2002
From: kelm at secorvo.de (Stefan Kelm)
Date: Fri, 8 Feb 2002 09:25:08 +0100
Subject: (Fwd) Key server patent
Message-ID: <200202080829.JAA04489@rom.antech.de>

FYI, there's more information at:

<http://patft.uspto.gov/netacgi/nph-
Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=
'6336186'.WKU.>

------- Forwarded message follows -------
Date sent:      	Wed, 6 Feb 2002 20:44:44 -0800 (PST)
From:           	Len Sassaman <rabbi at quickie.net>
To:             	<pgp-keyserver-folk at flame.org>
Subject:        	Key server patent.

FYI, NAI's newly granted key server policy patent:

http://www.delphion.com/details?pn=US06336186__

------- End of forwarded message -------


A cryptosystem having a Certificate (Key) Server for storing and
maintaining certificate or key information in a certificate database is
described. The Certificate Server allows clients to submit and
retrieve keys from a database based on a set of policy constraints
which are set for one's particular site (e.g., company). Access to the
Certificate Server is maintained by a Certificate Policy Agent, which
makes sure that the policy is enforced for a given site based on the
information supplied during the configuration. During operation, the
Certificate Server responds to client requests to add, search for,
and retrieve certificates. The server accepts or rejects certificates
based on configurable parameters enforced by a Certificate Policy
Agent. When a certificate is submitted to the server, the Certificate
Policy Agent checks to see if it meets the criteria for a given site
based on the settings specified during the configuration. Exemplary
types of checks that the Certificate Policy Agent can enforce include
checking to see if the key has been signed by the appropriate
entities and checking to see if the signatures or User IDs
associated with a key are approved for submission. If the
submission criteria established during the configuration are met, the
key is accepted by the server. If the key being submitted does not
pass the policy requirements, it is rejected and (optionally) a copy is
placed in a "pending bucket" where the key can subsequently be
examined by the system administrator to determine if the key should
be allowed on the server. 



-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-461, Fax +49 721 6105-455
E-Mail kelm at secorvo.de, http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Fri Feb  8 08:41:51 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Fri, 8 Feb 2002 08:41:51 -0500
Subject: New York State Files Suit Against Network Associates
Message-ID: <p0510039eb88985eaa4ac@[10.0.1.2]>

http://www.nytimes.com/2002/02/08/technology/08VIRU.html?todaysheadlines=&pagewanted=print




February 8, 2002

New York State Files Suit Against Maker of Software

By MATT RICHTEL

he State of New York said yesterday that it had sued Network Associates
(news/quote), a maker of antivirus software, accusing the company of
restricting free speech by forcing consumers and journalists to get
permission before publishing reviews of its products.

The lawsuit, filed in State Supreme Court in Manhattan, takes issue with an
admonition that Network Associates printed on its Web site and on software
disks. It warned: "The customer will not publish reviews of this product
without prior consent from Network Associates Inc."

The lawsuit says the warning appeared on Web pages along with downloadable
versions of software and on hundreds of thousands of disks from Network
Associates, a public company based in Santa Clara, Calif., whose products
include McAfee Virus Scan.

Eliot L. Spitzer, the attorney general of New York, said the clause
constituted an effort by the company to censor consumers and to "inhibit
itself from criticism and commentary that is the essence of the free
market."

The lawsuit seeks financial penalties, though Mr. Spitzer said what he
really wanted was to see the practice stopped. He also wants to send a
message that such "censorship clauses" violate the First Amendment and are
unfriendly to consumers, he said.

"Imagine if Ford had these clauses," Mr. Spitzer said. "Nobody would have
been able to criticize the Pinto."

Kent Roberts, the general counsel for Network Associates, said yesterday
that he planned to fight the lawsuit, and he said "the company has not done
anything wrong." The terms of use are a matter between the consumer and the
company, Mr. Roberts said, and the firm had "the right to set the terms of
its license."

But Mr. Roberts said that the company did not intend to prevent consumers
from writing reviews. Rather, he said, the company sought to prevent
customers from writing reviews of outdated versions of the product and to
encourage them to get the latest releases before publishing a review.

The company routinely improves its software and updates it so it can
recognize new viruses.

In the last two months, Mr. Roberts said, the wording of the warning has
been changed.

New releases now tell customers not to publish "tests regarding this
product without first verifying with Network Associates that you possess
the correct product for the test." The statement goes on to warn that a
failure to do so could constitute "misrepresentation or deceptive practice."

But Mr. Spitzer said the company did in fact seek to inhibit reviews. His
office has obtained e-mail exchanges from 1999 sent between Network
Associates and a reviewer for Network World, an online trade journal that
reviews software, and the lawsuit contends that in the e-mail exchanges,
Network Associates sought to have a "retraction/correction" to a review of
its Gauntlet firewall software on the basis of what Mr. Spitzer termed the
"censorship clause."

Mr. Spitzer said the lawsuit underscored a larger issue. His office is
investigating the user agreements published by several other companies, Mr.
Spitzer said, though he declined to say which. He said that if officials
did not act, "other companies will shortly follow suit" and include similar
restrictions.

James A. Guest, president of Consumers Union, a nonprofit group that
publishes Consumer Reports magazine, said editors there could recall
several similar examples of such user agreements issued by companies. But
he could not remember the names of the companies or recall any attempts
made by companies to use the agreements to censor reviews.

But Mr. Guest said the lawsuit against Network Associates would be
extremely important in preventing more companies from adopting such
clauses, which he said could be a "real loss for consumers."

Shares of Network Associates were down $1.53, or nearly 6 percent, to $25.14.



-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From hoepman at cs.utwente.nl  Fri Feb  8 11:12:45 2002
From: hoepman at cs.utwente.nl (Jaap-Henk Hoepman)
Date: 08 Feb 2002 17:12:45 +0100
Subject: Welome to the Internet, here's your private key
In-Reply-To: <v0421010cb886eb980130@[192.168.0.2]>
References: <v0421010cb886eb980130@[192.168.0.2]>
Message-ID: <lme4pcpz.fsf@smtp.xs4all.nl>


I think there _are_ good business reasons for them not wanting the users to
generate the keys all by themselves. Weak keys, and subsequent compromises, may
give the CA really bad press and resulting loss of reputation (and this 
business is built on reputation anyway). So: there are good reasons not to
let the CA generate the private key, but also good reasons to not let the user
generate the keys all by himself. 

So the question is: are there key generation protocols for mutually distrustful
parties, that would give the CA the assurance that the key is generated using
some good randomness (coming from the CA) and would give the user the guarantee
that his private key is truly private. Also, the CA should be able to verify
later that the random data he supplied was actually used, but this should not
give him (too much) advantage to find the private key.

A smartcard based system might be useful here (as suggested by other
subscribers here). But a software only solution is preferred because it would
maker the application area much broader (because the user does not have to be
supplied with special hardware - terminals + smartcards).

Jaap-Henk

On Wed, 6 Feb 2002 15:37:06 +0100  "Arnold G. Reinhold" <reinhold at world.std.com> writes:
> And creates a potential legal liability  for the smart card 
> manufacturer. This gets to the original question of this thread. I 
> wonder why the CA's lawyers let them generate private keys 
> themselves. If it ever came out that private keys were misused by CA 
> employees or even someone who penetrated their security, they would 
> be legally defenseless, all the gobbledygook in their practice 
> statements not withstanding. There is no good business reason for a 
> CA to generate private keys and very powerful business reasons for 
> them not to.

-- 
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn your bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman at cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From lynn.wheeler at firstdata.com  Fri Feb  8 12:14:50 2002
From: lynn.wheeler at firstdata.com (lynn.wheeler at firstdata.com)
Date: Fri, 8 Feb 2002 10:14:50 -0700
Subject: Welome to the Internet, here's your private key
Message-ID: <OFE645457B.96B6455D-ON87256B5A.005D9BAD@internet.ny.fdms.firstdata.com>


There are very good reasons for having hardware tokens as part of 2/3
factor authentication ... i.e. the hardware token is a "something you have"
.... and very good reason for such hardware tokens to become ubiquitous.
Now if there is USB plub&play for things like PC/SC  ... there is much
lower dependency on what the form factor that hardware token needs to take
(modulo some of the EU finread standards issues) that it would be
transparent to software whether it is talking USB to dongle hardware token
or usb reader+card.

As mentioned previously .... the issue regarding divulging the private key
is a business issue. Using public/private key in an authentication business
scenario has a real requirement that the private key not be known to
minimize impersonation issue. However, public/private key in encryption
business scenario involving valuable corporate assets could lead to "loss"
of those assets of there is a token/private-key  failure/loss/stollen.
Where private key is being used in business scenario involving protection
of valuable corporate assets .... there is real requirement for high level
of redundancy ... and the "impersonation" scenario doesn't apply as it does
in the authentication business scenario; aka while the technology may be
the same ... the different requirements are driven from the business needs
& applications.

it is possible to establish business practices and audit procedures to
significantly increase confidence in the operation of hardware tokens. ...
misc. aads chip strawman discussions
http://www.garlic.com/~lynn/index.html#aads

impresonation refs:
http://www.garlic.com/~lynn/aadsm10.htm#keygen Welome to the Internet,
here's your private key
http://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
http://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?)

misc. eu finread discussions
http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel
Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities?
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip
Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip
Market

1/2/3 factor authentication
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about
Digital Signatures
http://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose13 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose14 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose15 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital
Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities?
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the
wall?
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001g.html#1 distributed authentication
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean
Anything?
http://www.garlic.com/~lynn/2001j.html#49 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
http://www.garlic.com/~lynn/2001k.html#61 I-net banking security




jaap-henk hoepman <hopeman at cs.utwente.nl on 2/8/2002 9:12 am wrote:


I think there _are_ good business reasons for them not wanting the users to
generate the keys all by themselves. Weak keys, and subsequent compromises,
may give the CA really bad press and resulting loss of reputation (and this
business is built on reputation anyway). So: there are good reasons not to
let the CA generate the private key, but also good reasons to not let the
user generate the keys all by himself.

So the question is: are there key generation protocols for mutually
distrustful parties, that would give the CA the assurance that the key is
generated using some good randomness (coming from the CA) and would give
the user the guarantee that his private key is truly private. Also, the CA
should be able to verify later that the random data he supplied was
actually used, but this should not give him (too much) advantage to find
the private key.

A smartcard based system might be useful here (as suggested by other
subscribers here). But a software only solution is preferred because it
would maker the application area much broader (because the user does not
have to be supplied with special hardware - terminals + smartcards).

Jaap-Henk


--
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn your bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman at cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF







---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From reinhold at world.std.com  Fri Feb  8 16:11:37 2002
From: reinhold at world.std.com (Arnold G. Reinhold)
Date: Fri, 8 Feb 2002 16:11:37 -0500
Subject: Welome to the Internet, here's your private key
In-Reply-To: <lme4pcpz.fsf@smtp.xs4all.nl>
References: <v0421010cb886eb980130@[192.168.0.2]>
 <lme4pcpz.fsf@smtp.xs4all.nl>
Message-ID: <v04210103b889e9933566@[192.168.0.2]>

At 5:12 PM +0100 2/8/02, Jaap-Henk Hoepman wrote:
>I think there _are_ good business reasons for them not wanting the users to
>generate the keys all by themselves. Weak keys, and subsequent 
>compromises, may
>give the CA really bad press and resulting loss of reputation (and this
>business is built on reputation anyway).

If the CA has nothing to do with key generation in the first place, 
I'm not sure how weak keys would affect the CA's reputation. "We had 
nothing to do with making that key, we just signed it" is a concept 
even the general public can understand. And the risk of weak keys 
seems small compared to the myriad ways a user's private key can be 
compromised.  If the CA has any access to private keys, any 
compromise can be blamed on the CA and diminish their reputation.

>So: there are good reasons not to
>let the CA generate the private key, but also good reasons to not let the user
>generate the keys all by himself.
>
>So the question is: are there key generation protocols for mutually 
>distrustful
>parties, that would give the CA the assurance that the key is generated using
>some good randomness (coming from the CA) and would give the user 
>the guarantee
>that his private key is truly private. Also, the CA should be able to verify
>later that the random data he supplied was actually used, but this should not
>give him (too much) advantage to find the private key.

It's hard to see how to establish a secure protocol between the 
user's machine and the CA without a good source of randomness on the 
user's machine in the first place.  You can't presume there's a 
shared secret.

Simply providing an applet or plug-in to generate keys would seem 
sufficient.  The CA could maintain a list of approved smart cards 
based on inspecting their source code.  They might even let approved 
smart card vendors embed a signing key in the smart card to let the 
CA know that the user key had been generated by an approved device. 
Such a system could be defeated but it's not clear why anyone would 
have the motivation to do so. If someone wants to create a 
compromised key incident, they merely have to leak a key.


Arnold Reinhold

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From nelson at crynwr.com  Sat Feb  9 15:02:54 2002
From: nelson at crynwr.com (Russell Nelson)
Date: Sat,  9 Feb 2002 15:02:54 -0500 (EST)
Subject: PGP & GPG compatibility
In-Reply-To: <87zo3885kj.fsf@alberti.gnupg.de>
References: <200201210230.SAA12233@toad.com>
	<sjmr8oka0ac.fsf@kikki.mit.edu>
	<87zo3885kj.fsf@alberti.gnupg.de>
Message-ID: <15461.31454.838758.348624@desk.crynwr.com>

Werner Koch writes:
 > Things would get much better if a PGP 2 version with support for CAST5
 > would get more into use.  [ etc. ]

I know that you're working hard, Werner, but I believe that the recent 
few years have destroyed the PGP brandname.  I think the only
worthwhile way forward is to create a cryptographic email standard de
novo, which is free of export, trademark, and patent problems.

Date: Tue, 28 Nov 2000 21:22:18 -0500 (EST)
To: cryptography at c2.net
Subject: Is PGP broken?

-- 
-russ nelson              http://russnelson.com | Crypto without a threat
Crynwr sells support for free software  | PGPok | model is like cookies
521 Pleasant Valley Rd. | +1 315 268 1925 voice | without milk.
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From shamrock at cypherpunks.to  Sat Feb  9 16:36:39 2002
From: shamrock at cypherpunks.to (Lucky Green)
Date: Sat, 9 Feb 2002 22:36:39 +0100 (CET)
Subject: PGP & GPG compatibility
In-Reply-To: <15461.31454.838758.348624@desk.crynwr.com>
Message-ID: <20020209223304.B17753-100000@pakastelohi.cypherpunks.to>

On Sat, 9 Feb 2002, Russell Nelson wrote:

>
> X-UID: 139934
>
> Werner Koch writes:
>  > Things would get much better if a PGP 2 version with support for CAST5
>  > would get more into use.  [ etc. ]
>
> I know that you're working hard, Werner, but I believe that the recent
> few years have destroyed the PGP brandname.  I think the only
> worthwhile way forward is to create a cryptographic email standard de
> novo, which is free of export, trademark, and patent problems.

I believe such a standard already exists. It is called S/MIME. Best of
all, this email encryption standard is supported out-of-the-box by the
overwhelming majority of deployed MUA's in the world.

-- Lucky Green <shamrock at cypherpunks.to>


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From jamesd at echeque.com  Sat Feb  9 17:13:26 2002
From: jamesd at echeque.com (jamesd at echeque.com)
Date: Sat, 9 Feb 2002 14:13:26 -0800
Subject: PGP & GPG compatibility
In-Reply-To: <20020209223304.B17753-100000@pakastelohi.cypherpunks.to>
References: <15461.31454.838758.348624@desk.crynwr.com>
Message-ID: <3C652E86.24668.14B6AEF@localhost>

    --
Werner Koch writes:
> >  > Things would get much better if a PGP 2 version with 
> >  > support for CAST5 would get more into use.  [ etc. ]

On Sat, 9 Feb 2002, Russell Nelson wrote:
> > I know that you're working hard, Werner, but I believe 
> > that the recent few years have destroyed the PGP 
> > brandname.  I think the only worthwhile way forward is to 
> > create a cryptographic email standard de novo, which is 
> > free of export, trademark, and patent problems.

On 9 Feb 2002, at 22:36, Lucky Green wrote:
> I believe such a standard already exists. It is called 
> S/MIME. Best of all, this email encryption standard is 
> supported out-of-the-box by the overwhelming majority of 
> deployed MUA's in the world.

However, to make it work, everyone needs to get officially 
blessed keys, and manage those keys.  The authorized central 
authorities not oppressive.  One is free to get a 
pseudonymous certificate that merely testifies to one's 
control of an email address, for example 
jamesd50 at hushmail.com

But, alas, I have never encountered a non engineer 
successfully doing that, even though the interface is 
designed for idiots and attempts to hide what is going on. 
The hiding, however, merely makes things harder, not easier, 
and idiots somehow always fail, even if they are the kind of 
idiot who gets to be Chairman of the Board, who usually
display a fair bit of intelligence in other matters. 

    --digsig
         James A. Donald
     6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
     JookN8yKLh3sJeIJIvdMGKG+ThURka7fVNj1bCnj
     4v4v8BJBaV13nPC/qC6tGXZiLR5NPjE1thes5z/Bp


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From jas at extundo.com  Sat Feb  9 17:52:19 2002
From: jas at extundo.com (Simon Josefsson)
Date: Sat, 09 Feb 2002 23:52:19 +0100
Subject: PGP & GPG compatibility
In-Reply-To: <3C652E86.24668.14B6AEF@localhost> (jamesd@echeque.com's
 message of "Sat, 9 Feb 2002 14:13:26 -0800")
References: <15461.31454.838758.348624@desk.crynwr.com>
	<3C652E86.24668.14B6AEF@localhost>
Message-ID: <ilupu3emfoc.fsf@dhcp133.extundo.com>

jamesd at echeque.com writes:

>> >  > Things would get much better if a PGP 2 version with 
>> >  > support for CAST5 would get more into use.  [ etc. ]
>
> On Sat, 9 Feb 2002, Russell Nelson wrote:
>> > I know that you're working hard, Werner, but I believe 
>> > that the recent few years have destroyed the PGP 
>> > brandname.  I think the only worthwhile way forward is to 
>> > create a cryptographic email standard de novo, which is 
>> > free of export, trademark, and patent problems.
>
> On 9 Feb 2002, at 22:36, Lucky Green wrote:
>> I believe such a standard already exists. It is called 
>> S/MIME. Best of all, this email encryption standard is 
>> supported out-of-the-box by the overwhelming majority of 
>> deployed MUA's in the world.
>
> However, to make it work, everyone needs to get officially 
> blessed keys, and manage those keys.

I believe it would be fruitful to separate the secure email message
formats (S/MIME vs PGP/MIME, or perhaps CMS vs OpenPGP) from the key
trust mechanism (PKI CA vs PGP web of trust).  In theory I cannot see
why one decision need to affect the other, they could be orthogonal
issues.  Perhaps by reading the relevant standards creatively, a
mailer sending S/MIME messages but uses a OpenPGP implementation
locally is already possible.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From bill.stewart at pobox.com  Sat Feb  9 21:52:40 2002
From: bill.stewart at pobox.com (Bill Stewart)
Date: Sat, 09 Feb 2002 18:52:40 -0800
Subject: Welome to the Internet, here's your private key
In-Reply-To: <lme4pcpz.fsf@smtp.xs4all.nl>
References: <v0421010cb886eb980130@[192.168.0.2]>
 <v0421010cb886eb980130@[192.168.0.2]>
Message-ID: <5.0.2.1.1.20020209160635.035e27d0@idiom.com>

At 05:12 PM 02/08/2002 +0100, Jaap-Henk Hoepman wrote:
>I think there _are_ good business reasons for them not wanting the users to
>generate the keys all by themselves. Weak keys, and subsequent 
>compromises, may
>give the CA really bad press and resulting loss of reputation (and this
>business is built on reputation anyway). So: there are good reasons not to
>let the CA generate the private key, but also good reasons to not let the user
>generate the keys all by himself.
>
>So the question is: are there key generation protocols for mutually 
>distrustful
>parties, that would give the CA the assurance that the key is generated using
>some good randomness (coming from the CA) and would give the user the 
>guarantee
>that his private key is truly private. Also, the CA should be able to verify
>later that the random data he supplied was actually used, but this should not
>give him (too much) advantage to find the private key.

There are three different cases
- Active malicious tampering by the user
- Inadequate key generation capabilities on the user's machine,
         e.g. weak randomness, too little memory, too slow CPU
- User's machine is compromised by some untrustable third party.

In the third case, you were toast anyway.
In the first case, what can malice accomplish that's different for a
         user-generated key as opposed to a CA-generated key?
         The malicious user could already give away his private key,
         and giving the CA a key generated by someone else to certify
         is pretty much equivalent to giving away the key.

The second case appears to be the interesting one.  There may be limited
         environments where the user's system doesn't have enough CPU or RAM
         (though someone else replied that even smartcards are often smart 
enough),
         but certainly for anything as smart as a Palm3,
         it's basically just a one-time startup delay.

         The way to fix inadequate randomness is not to have the CA 
generate the key,
         it's to have the CA generate a bunch of randomness and
         send it to the user's system to input it in the key generation 
program.
         If you're worried that the user might not bother to enter the
         randomness into the CA-supplied key generation program,
         have the program check that the user entered enough characters,
         or even use a checksum on the user-entered characters.

         If you're worried about Man In The Middle attacks on the
         CA-supplied randomness, you could digitally sign it, though
         that's a bit long-winded for user-typed strings
         unless you use Elliptic Curves or some similar short-signature
         method or use an HMAC or something.

Are there any other cases in which the CA needs to generate the key
for legitimate reasons, as opposed to because the CA wants access to
the user's private key for later purposes?


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Sun Feb 10 19:05:24 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Sun, 10 Feb 2002 19:05:24 -0500
Subject: Where's the smart money?
Message-ID: <p05100307b88cb93655c7@[10.0.1.2]>

http://www.economist.com/printedition/displayStory.cfm?Story_ID=975746&CFID=301055&CFTOKEN=47471685


Where's the smart money?

Feb 7th 2002
>From The Economist print edition


Money of the future may almost literally talk


AMERICAN banknotes bear the motto "In God we trust". A humorous extension
to this phrase-ascribed, unofficially, to the National Security Agency-is
"All Others, we monitor". That joke, though, may soon pale into reality,
for such a phrase might well be a suitable slogan for the cash of the
future.

Radio-frequency identification tags (RFIDs) are widgets that are used all
over the world for granting access to secure areas. They are also used to
track anything from books to pallets to cattle to Prada handbags. Their
advantage is that each tag (and therefore each object) can be identified
uniquely. That makes them different from, say, bar codes, which merely
identify classes of object. Also unlike bar codes, RFIDS can be read
remotely without having to be in the line of sight of the reader. In recent
years, their manufacturers have been drooling over the possibility of
tagging banknotes. The advantages envisaged are a combination of
authentication, anti-counterfeiting and tracking.


In the money

The guts of a typical RFID tag are a microchip and an antenna (often a coil
of wire). These may be sandwiched inside an encapsulating plastic. There is
no battery. When a tag is "interrogated" by a reading machine operating at
the right radio frequency, the antenna picks up a small amount of
electromagnetic energy that it uses to power the chip. The tag then
broadcasts data in the chip back to the reader.

A new generation of RFID tags produced by companies such as Texas
Instruments in America, Hitachi in Japan and Infineon Technologies in
Germany, has broken through barriers of size (less than 1mm across and
1?2mm thick), cost, flexibility and durability, to a point where such tags
can be embedded inside sheets of paper, such as banknotes.

The distance from which tagged banknotes could be read would depend on the
exact specifications of the chips that were used. It would probably be
somewhere between 10cm and a metre. One form of the technology can read 30
notes a second, although the tags have to be separated from each other by a
distance of at least 2cm to reduce interference. Initially, therefore,
bundles of notes could not be read; but notes being issued from cash
machines, or passing from customers to tills, could.

The technology remains relatively expensive (20-30 cents a chip), and there
is still work to be done hammering out what people want in the way of
security standards, durability and the amount of information that can be
stored. But Infineon says that these problems could be ironed out within 30
months, and possibly much faster than that. Critics sound a warning,
however, that long delays are likely in reaching an international agreement
on a cryptographic security standard.

One bank, at least, seems interested in the idea. Late last year,
Electronic Engineering Times reported that the European Central Bank (ECB)
was working with "technology partners" to embed the tags into euro notes by
2005-as a means of foiling counterfeiters. The ECB will only say of the
project, "we don't want to talk about this." Nevertheless, two chip
manufacturers, Philips and Infineon, admit to having signed confidentiality
agreements with some firms in the industry. Hitachi says it has been
discussing the issue with European banknote makers.

Obviously, such tags would make counterfeiters' lives far more difficult.
But according to De La Rue, a British firm that is one of the world's
leading "security" printers and paper makers, the ECB is already aware of
many new anti-counterfeiting technologies that would be just as robust as,
and less expensive than, RFID. If this is the case, the additional benefits
of RFID banknotes-such as the greater ease with which cash could be
tracked-are the likeliest explanation for why the technology is now
attracting serious consideration.

RFID-tagged notes mean that it would be possible to gather "real-time"
inventories of notes within banks. And, if cash registers were equipped
with authorised readers (tags can also interrogate reading machines to
establish a reader's "authority" to ask particular questions), details of
the transaction and the notes involved could be collated in a central
database.

Accurate knowledge, and monitoring, of the population of banknotes could be
a powerful tool. The mining of data on how different banknotes move through
the economy would make it easy to spot suspicious transactions-for example,
a large deposit of notes that had been out of circulation for a long time.

There are further possibilities. Known notes could be slipped into the
"informal" economy by law-enforcement agencies that wanted to find out
where they turned up. Kidnappers could no longer insist on unmarked bills,
for there would be no such things. Even the theft of cash would become a
much trickier affair.

Clearly, the technology would have huge privacy implications. On the one
hand, customers of illicit and semi-licit goods and services, such as
recreational drugs and prostitution, would risk losing their anonymity
unless they were careful. On the other, ham-fisted policing might implicate
the innocent in transactions to which they had not been a party, merely
because they once handled suspect notes.

Nevertheless, it is likely that the threat of terrorism and organised
crime, and the precedent of existing methods for tracking money, will be
strong counter-arguments in favour of tracking technology. The relatively
high cost of the tags has led to speculation that they would be practical
only in high-value notes-in the case of the ECB, euro200 and euro500. But
it is just such notes that are of concern to agencies such as Britain's
National Criminal Intelligence Service, which warns that these new
denominations make it easier to move large amounts of currency discreetly
(and possibly illegally) around the world. The global reach of the euro, a
currency that is policed by a fragmented group of authorities, highlights
weaknesses that RFID technology may be well-placed to rectify. For
criminals, money may no longer talk. Instead, it may squeal.


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From nelson at crynwr.com  Sun Feb 10 23:28:04 2002
From: nelson at crynwr.com (Russell Nelson)
Date: Sun, 10 Feb 2002 23:28:04 -0500 (EST)
Subject: PGP & GPG compatibility
In-Reply-To: <20020209223304.B17753-100000@pakastelohi.cypherpunks.to>
References: <15461.31454.838758.348624@desk.crynwr.com>
	<20020209223304.B17753-100000@pakastelohi.cypherpunks.to>
Message-ID: <15463.18177.339810.586737@desk.crynwr.com>

Lucky Green writes:
 > On Sat, 9 Feb 2002, Russell Nelson wrote:
 > > I think the only worthwhile way forward is to create a
 > > cryptographic email standard de novo, which is free of export,
 > > trademark, and patent problems.
 > 
 > I believe such a standard already exists. It is called S/MIME. Best of
 > all, this email encryption standard is supported out-of-the-box by the
 > overwhelming majority of deployed MUA's in the world.

Well, one of the things that PGP/GPG/OpenPGP got right is the web of
trust model.  Given that model, there is nothing preventing someone
from imposing a certificate authority on top of that web.  On the
other hand, I know of know way to make S/MIME work without a
certificate from an authority.

-- 
-russ nelson              http://russnelson.com | Crypto without a threat
Crynwr sells support for free software  | PGPok | model is like cookies
521 Pleasant Valley Rd. | +1 315 268 1925 voice | without milk.
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From adam at cypherspace.org  Mon Feb 11 04:33:32 2002
From: adam at cypherspace.org (Adam Back)
Date: Mon, 11 Feb 2002 09:33:32 +0000
Subject: why there is no WoT in S/MIME (Re: PGP & GPG compatibility)
In-Reply-To: <15463.18177.339810.586737@desk.crynwr.com>; from nelson@crynwr.com on Sun, Feb 10, 2002 at 11:28:04PM -0500
References: <15461.31454.838758.348624@desk.crynwr.com> <20020209223304.B17753-100000@pakastelohi.cypherpunks.to> <15463.18177.339810.586737@desk.crynwr.com>
Message-ID: <20020211093332.A535341@exeter.ac.uk>

The fact that S/MIME doesn't work well with WoT, and that there are
two classes of users: end users, and CAs is a design criteria burnt
into the spec and most of the software.  It's a business issue, the CA
players were involved in writing the standards, and they have a vested
interest to force users into paying them money to use the software.
It's also a factor why most of the statistic of users with S/MIME MUAs
aren't using it.  I think S/MIME would be more widely used by
individuals if the end-user software worked without CA certificates
and preferably supported some form of WoT.

Adam

On Sun, Feb 10, 2002 at 11:28:04PM -0500, Russell Nelson wrote:
> Well, one of the things that PGP/GPG/OpenPGP got right is the web of
> trust model.  Given that model, there is nothing preventing someone
> from imposing a certificate authority on top of that web.  On the
> other hand, I know of know way to make S/MIME work without a
> certificate from an authority.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From adam at cypherspace.org  Mon Feb 11 04:48:56 2002
From: adam at cypherspace.org (Adam Back)
Date: Mon, 11 Feb 2002 09:48:56 +0000
Subject: whats bad about RFIDs in currency (Re: Where's the smart money?)
In-Reply-To: <p05100307b88cb93655c7@[10.0.1.2]>; from rah@shipwright.com on Sun, Feb 10, 2002 at 07:05:24PM -0500
References: <p05100307b88cb93655c7@[10.0.1.2]>
Message-ID: <20020211094856.B535341@exeter.ac.uk>

Isn't it already the case that all notes have serial numbers.  I
thought that with some currencies this is printed in magnetic ink with
letter shape designed for easy electronic reading (blobby numbers with
blobs in different places to make it easy for the reader to
distinguish each of the numbers).  Anyone know if current cash point
dispensers are reading those numbers?

So an electronic serial number (an RFID) is no less or more than a
more expensive, marginally harder to copy (if RFIDs are < 30c each I
can't see them being that hard to reproduce) electronic serial number.

The relatively anonymity of cash comes not from the notes being
indistinguishable (they already are not so), but from the fact that
they are exchanged, potentially many times, in a peer-to-peer fashion
without going via a bank account.  This would still be the case for
RFIDs.

When it would start to get scary would be if the financial tracking
special interest groups introduced online equipment for merchants to
verify validty of RFID bank notes as an anti-fraud measure (with the
real objective for the special interest not being the anti-fraud, but
the tracking).  There is a precedent for currency fraud detection at
merchant point of sale, though not an online one with UV lights,
special pens etc.  There is also a precedent with online fraud
detection with credit cards.

Here the RFID would be bad because it would I suspect make the
equipment to off-line or on-line audit and track notes much cheaper
and more robust.  The alternative of scanner reading the serial
numbers sounds clunky and low tech enough that it wouldn't fly, and
wouldn't be able to masquerade effectively as an anti-fraud measure
which is a tracking measure in disguise.

I think the latter (online anti-fraud detection of RFID) should be
strongly resisted to preserve payment privacy, and therefore the
former (RFIDs in currency) also should be resisted for the reasons
above that it moves us along a path towards online anti-fraud
equipment at merchant point of sale.

Adam

On Sun, Feb 10, 2002 at 07:05:24PM -0500, R. A. Hettinga wrote:
> http://www.economist.com/printedition/displayStory.cfm?Story_ID=975746&CFID=301055&CFTOKEN=47471685

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From Pete.Chown at skygate.co.uk  Mon Feb 11 06:39:50 2002
From: Pete.Chown at skygate.co.uk (Pete Chown)
Date: 11 Feb 2002 11:39:50 +0000
Subject: PGP & GPG compatibility
In-Reply-To: <15463.18177.339810.586737@desk.crynwr.com>
References: <15461.31454.838758.348624@desk.crynwr.com>
	<20020209223304.B17753-100000@pakastelohi.cypherpunks.to> 
	<15463.18177.339810.586737@desk.crynwr.com>
Message-ID: <1013427590.30276.45.camel@hyena.skygate.co.uk>

Russell Nelson wrote:

> Well, one of the things that PGP/GPG/OpenPGP got right is the web of
> trust model.

Sure, it is more flexible than X.509 because you could implement the
X.509 trust model in OpenPGP if you wanted to.

> On the
> other hand, I know of know way to make S/MIME work without a
> certificate from an authority.

Perhaps that is an argument for a new certificate format.  I've thought
that an XML based certificate format would work well...  It could take
advantage of the XML digital signature work, it would be human readable,
and it could be processed with existing tools.  There are also lots of
existing schemas that could be used, such as vcard.

-- 
Pete


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ptrei at rsasecurity.com  Mon Feb 11 10:21:36 2002
From: ptrei at rsasecurity.com (Trei, Peter)
Date: Mon, 11 Feb 2002 10:21:36 -0500
Subject: Losing the Code War by Stephen Budiansky
Message-ID: <F504A8CEE925D411AF4A00508B8BE90A01E90C22@exna07.securitydynamics.com>

> marius[SMTP:marius.corbu at analog.com] wrote:
> 
> > marius wrote:
> > > Not quite true. Encrypting each message twice would not increase the
> > > "effective" key size to 112 bits.
> > > There is an attack named "meet in the middle" which will make the
> > > effective key size to be just 63 bits.
> > 
> > Peter Trei wrote:
> > > Don't forget that the MITM attack (which Schneier claims
> > > takes 2^(2n) = 2^112 time), also requires 2^56 blocks
> > > of storage.
> > [...]
> > > I don't lose sleep over MITM attacks on 3DES.
> 
> 2^57 operations, with 2^56 blocks of storage manipulation can be
> approximated to: 2^56 * log(2^56) + 2^56 * log(2^56) = 2^62 + 2^62 =
> 2^63
> 
> Betting on storage as a show stopper is not a good idea, regardless of
> sleep pattern.
> 
> Marius
> 
Oh, I totally agree - my first followup (Feb 4) read:

- start quote - 

Either way, my point stands: any attack which requires 2^56 blocks
of storage is probably intractable for the time being, imho. 10 years
from now, I'm not so sure.

- end quote - 

The expansion of storage over the last 20 years is even more 
astonishing than the  speedup of microprocessors. The first IBM
PC to ship with a HD (PC-XT ~1983) had a 5 Mb drive. When I
worked for Columbia U, undergraduates were given about 50kb
of diskquota for a semester.

Nevertheless, 2^56 blocks of centralized storage is a lot, and 
will remain a lot for a while.

Peter Trei

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From crawdad at fnal.gov  Mon Feb 11 12:19:06 2002
From: crawdad at fnal.gov (Matt Crawford)
Date: Mon, 11 Feb 2002 11:19:06 -0600
Subject: Where's the smart money?
In-Reply-To: "10 Feb 2002 19:05:24 EST." <p05100307b88cb93655c7@[10.0.1.2]>
Message-ID: <200202111719.g1BHJ6Z19427@gungnir.fnal.gov>

I predict a new EMP vandalism tool that fries the moneychip.

And provides an alibi to passers of notes with no working chip.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ptrei at rsasecurity.com  Mon Feb 11 13:59:24 2002
From: ptrei at rsasecurity.com (Trei, Peter)
Date: Mon, 11 Feb 2002 13:59:24 -0500
Subject: Where's the smart money?
Message-ID: <F504A8CEE925D411AF4A00508B8BE90A01E90C2A@exna07.securitydynamics.com>

My first thought on hearing of this was:
'Wil these survive a session in the microwave?"
(brings new meaning to the phrase 'hot money' :-)

Peter Trei


> ----------
> From: 	Matt Crawford[SMTP:crawdad at fnal.gov]
> I predict a new EMP vandalism tool that fries the moneychip.
> 
> And provides an alibi to passers of notes with no working chip.
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From peter.fairbrother at ntlworld.com  Mon Feb 11 14:11:36 2002
From: peter.fairbrother at ntlworld.com (Peter Fairbrother)
Date: Mon, 11 Feb 2002 19:11:36 +0000
Subject: Where's the smart money?
In-Reply-To: <F504A8CEE925D411AF4A00508B8BE90A01E90C2A@exna07.securitydynamics.com>
Message-ID: <B88DC7E8.1465F%peter.fairbrother@ntlworld.com>

Not having a microwave (or any unwanted money) to experiment, I have to ask
if the metallic strips in present notes would survive microwaving either.


-- Peter Fairbrother

Trei, Peter wrote:

> My first thought on hearing of this was:
> 'Wil these survive a session in the microwave?"
> (brings new meaning to the phrase 'hot money' :-)
> 
> Peter Trei
> 
> 
>> ----------
>> From:  Matt Crawford[SMTP:crawdad at fnal.gov]
>> I predict a new EMP vandalism tool that fries the moneychip.
>> 
>> And provides an alibi to passers of notes with no working chip.
>> 
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
> majordomo at wasabisystems.com


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From SGuthery at mobile-mind.com  Mon Feb 11 14:16:04 2002
From: SGuthery at mobile-mind.com (Scott Guthery)
Date: Mon, 11 Feb 2002 14:16:04 -0500
Subject: Where's the smart money?
Message-ID: <177EEB93DEA5D4119B4800508BE753D2157F8C@FS1>

No ink, no value.
No working chip, no value.

Gotta keep your bills out of the washer AND the dryer.

When they said laundry, they meant all the cycles.

Anybody remember mangles?

Cheers, Scott

-----Original Message-----
From: Trei, Peter [mailto:ptrei at rsasecurity.com]
Sent: Monday, February 11, 2002 1:59 PM
To: cryptography at wasabisystems.com; 'Matt Crawford'
Subject: RE: Where's the smart money?


My first thought on hearing of this was:
'Wil these survive a session in the microwave?"
(brings new meaning to the phrase 'hot money' :-)

Peter Trei


> ----------
> From: 	Matt Crawford[SMTP:crawdad at fnal.gov]
> I predict a new EMP vandalism tool that fries the moneychip.
> 
> And provides an alibi to passers of notes with no working chip.
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to
majordomo at wasabisystems.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ptrei at rsasecurity.com  Mon Feb 11 14:25:27 2002
From: ptrei at rsasecurity.com (Trei, Peter)
Date: Mon, 11 Feb 2002 14:25:27 -0500
Subject: Where's the smart money?
Message-ID: <F504A8CEE925D411AF4A00508B8BE90A01E90C2C@exna07.securitydynamics.com>

That's the scenario which is (semi) worrying. As
the tagged bills wear, some fraction of the RFID
transponders will inevitably fail. When this happens,
is the bill declared invalid? Will merchants regularly
check all incoming cash for a good tag? Is a bill 
with a bad tag presumed to be counterfeit? Can
it be exchanged?

Peter Trei

> Scott Guthery[SMTP:SGuthery at mobile-mind.com] wrote:
> No ink, no value.
> No working chip, no value.
> Gotta keep your bills out of the washer AND the dryer.
> When they said laundry, they meant all the cycles.
> Anybody remember mangles?
> Cheers, Scott
> 
> -----Original Message-----
> From: Trei, Peter [mailto:ptrei at rsasecurity.com]
> 
> My first thought on hearing of this was:
> 'Wil these survive a session in the microwave?"
> (brings new meaning to the phrase 'hot money' :-)
> 
> Peter Trei
> > ----------
> > From: 	Matt Crawford[SMTP:crawdad at fnal.gov]
> > I predict a new EMP vandalism tool that fries the moneychip.
> > 
> > And provides an alibi to passers of notes with no working chip.
> > 
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From bmanning at isi.edu  Mon Feb 11 14:51:57 2002
From: bmanning at isi.edu (Bill Manning)
Date: Mon, 11 Feb 2002 11:51:57 -0800
Subject: Where's the smart money?
In-Reply-To: <F504A8CEE925D411AF4A00508B8BE90A01E90C2C@exna07.securitydynamics.com>
References: <F504A8CEE925D411AF4A00508B8BE90A01E90C2C@exna07.securitydynamics.com>
Message-ID: <20020211195157.GG41228@zed.isi.edu>

I had always thought that one of the key hallmarks of
money was its ability to retain value over a varitey of
hostile environments...


On Mon, Feb 11, 2002 at 02:25:27PM -0500, Trei, Peter wrote:
> That's the scenario which is (semi) worrying. As
> the tagged bills wear, some fraction of the RFID
> transponders will inevitably fail. When this happens,
> is the bill declared invalid? Will merchants regularly
> check all incoming cash for a good tag? Is a bill 
> with a bad tag presumed to be counterfeit? Can
> it be exchanged?
> 
> Peter Trei
> 
> > Scott Guthery[SMTP:SGuthery at mobile-mind.com] wrote:
> > No ink, no value.
> > No working chip, no value.
> > Gotta keep your bills out of the washer AND the dryer.
> > When they said laundry, they meant all the cycles.
> > Anybody remember mangles?
> > Cheers, Scott
> > 
> > -----Original Message-----
> > From: Trei, Peter [mailto:ptrei at rsasecurity.com]
> > 
> > My first thought on hearing of this was:
> > 'Wil these survive a session in the microwave?"
> > (brings new meaning to the phrase 'hot money' :-)
> > 
> > Peter Trei
> > > ----------
> > > From: 	Matt Crawford[SMTP:crawdad at fnal.gov]
> > > I predict a new EMP vandalism tool that fries the moneychip.
> > > 
> > > And provides an alibi to passers of notes with no working chip.
> > > 
> > 
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From decoy at iki.fi  Mon Feb 11 18:09:01 2002
From: decoy at iki.fi (Sampo Syreeni)
Date: Tue, 12 Feb 2002 01:09:01 +0200 (EET)
Subject: Where's the smart money?
In-Reply-To: <F504A8CEE925D411AF4A00508B8BE90A01E90C2C@exna07.securitydynamics.com>
Message-ID: <Pine.SOL.4.30.0202120047220.9402-100000@kruuna.Helsinki.FI>

On Mon, 11 Feb 2002, Trei, Peter wrote:

>That's the scenario which is (semi) worrying. As the tagged bills wear,
>some fraction of the RFID transponders will inevitably fail. When this
>happens, is the bill declared invalid?

I see no reason why sufficiently reliable RFID notes (say an MTBF in
average use of around 5; not technologically infeasible, yet around what
current print-only notes can take at max) could not be handled this way.
But if this is really such a problem, one would expect the issuer to be
able to invest a fair amount of money per bill in circulation into
verification methods in excess of what you'd typically see in a grocery
store -- a reasonable MTBF and enough circulation through the issuer would
lead to few notes getting into a bad shape to be passed this far up the
chain. Thus, failed notes could be replaced at a cost not much higher than
that incurred by routine check-ups, only with a greater delay.

Besides, there's a point in invalidating failed bills -- if this is not
done, where's the incentive for people to keep the stock in shape? A
monetary economy, by itself, *can* adapt to lost bills via deflation, and
bills going invalid is something nobody really wants to experience.
Also, it is likely that deflationary pressures arising out of economic
growth will completely drown out any effects lost notes might have on the
larger economy. The implication is, wear and tear of bills can be
accurately analyzed by treating them as a slowly devaluing physical good,
and the usual efficiency arguments apply.

Sampo Syreeni, aka decoy - mailto:decoy at iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From geer at world.std.com  Mon Feb 11 20:36:56 2002
From: geer at world.std.com (Dan Geer)
Date: Mon, 11 Feb 2002 20:36:56 -0500
Subject: Where's the smart money? 
In-Reply-To: Your message of "Mon, 11 Feb 2002 13:59:24 EST."
             <F504A8CEE925D411AF4A00508B8BE90A01E90C2A@exna07.securitydynamics.com> 
Message-ID: <200202120136.UAA28900@world.std.com>


> I predict a new EMP vandalism tool that fries the moneychip.
> 
> And provides an alibi to passers of notes with no working chip.

You are, of course, assuming that RFID money that has been
damaged will still be accepted without manual processing
delays to the putative depositor.  I can, after all, tear
all my paper USD in half but I will surely then incur some
manual processing delay when uploading them to the bank,
likely in proportion to the size of my deposit.  The real
question might be whether instead of today's dye pack one
got an EMP generator as a special gift when holding up the
local S&L.

--dan


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From peter.fairbrother at ntlworld.com  Mon Feb 11 20:49:02 2002
From: peter.fairbrother at ntlworld.com (Peter Fairbrother)
Date: Tue, 12 Feb 2002 01:49:02 +0000
Subject: Where's the smart money?
In-Reply-To: <Pine.SOL.4.30.0202120047220.9402-100000@kruuna.Helsinki.FI>
Message-ID: <B88E250E.1469B%peter.fairbrother@ntlworld.com>

I don't know whether to smile, or call you an arsehole, you give few clues -
"economic growth"?.

I just hope that if your suggestion is taken up then all the bills that are
declared invalid belong to you, and thus not to me or anyone else.

:)

Even credit card invalidity is not thoroughly recognised these days - just
before Christmas I ordered a CD which was sent, even though I'd
inadvertantly gone over my limit and the payment authorisation was refused -
they wrote a note telling me so on the delivery invoice. A human being, not
a computer system.

People give cash notes to other people, who may or may not be retailers. If
it's not humanly recognisable without a terminal, it's likely to be refused.
I suppose they could do an introduction of new notes, like they did with the
Euro, but I can't see it working.

And after a few exchanges on the lines of "It won't pass the box" - "Give me
my change or I'll break your head" I suspect the retailer boxes would become
as likely to be sabotaged as the notes.

What about eg markets where there is no electricity, never mind connectivity
to check notes? R. Branson started there, for one.


Cash has it's place, but requiring electronic confirmation is exactly where
it isn't. We have credit cards for that. Cash needs to be authenticatable by
humans alone.

-- Peter Fairbrother


> Sampo Syreeni wrote:

> On Mon, 11 Feb 2002, Trei, Peter wrote:
> 
>> That's the scenario which is (semi) worrying. As the tagged bills wear,
>> some fraction of the RFID transponders will inevitably fail. When this
>> happens, is the bill declared invalid?
> 
> I see no reason why sufficiently reliable RFID notes (say an MTBF in
> average use of around 5; not technologically infeasible, yet around what
> current print-only notes can take at max) could not be handled this way.
> But if this is really such a problem, one would expect the issuer to be
> able to invest a fair amount of money per bill in circulation into
> verification methods in excess of what you'd typically see in a grocery
> store -- a reasonable MTBF and enough circulation through the issuer would
> lead to few notes getting into a bad shape to be passed this far up the
> chain. Thus, failed notes could be replaced at a cost not much higher than
> that incurred by routine check-ups, only with a greater delay.
> 
> Besides, there's a point in invalidating failed bills -- if this is not
> done, where's the incentive for people to keep the stock in shape? A
> monetary economy, by itself, *can* adapt to lost bills via deflation, and
> bills going invalid is something nobody really wants to experience.
> Also, it is likely that deflationary pressures arising out of economic
> growth will completely drown out any effects lost notes might have on the
> larger economy. The implication is, wear and tear of bills can be
> accurately analyzed by treating them as a slowly devaluing physical good,
> and the usual efficiency arguments apply.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From smb at research.att.com  Mon Feb 11 18:43:49 2002
From: smb at research.att.com (Steven M. Bellovin)
Date: Mon, 11 Feb 2002 18:43:49 -0500
Subject: Where's the smart money? 
Message-ID: <20020211234349.954887B5D@berkshire.research.att.com>

In message <F504A8CEE925D411AF4A00508B8BE90A01E90C2C at exna07.securitydynamics.co
m>, "Trei, Peter" writes:
>That's the scenario which is (semi) worrying. As
>the tagged bills wear, some fraction of the RFID
>transponders will inevitably fail. When this happens,
>is the bill declared invalid? Will merchants regularly
>check all incoming cash for a good tag? Is a bill 
>with a bad tag presumed to be counterfeit? Can
>it be exchanged?
>

I can't speak for other countries, but the U.S. already has 
well-defined procedures for trading in damaged currency.  For example, 
if you have >3/5 of the bill, you get full value; between 2/5 and 3/5, 
you get half-value; below that, you get nothing.  I believe that such 
exchanges can be done at any bank, though I could be wrong about that.

Anyway -- I'd assume that similar procedures would be put in place for 
tagged bills.  Validation might inlude a waiting period to see if the 
tag corresponding to that serial number shows up.

		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From jme at off.net  Mon Feb 11 20:55:20 2002
From: jme at off.net (Jerome Etienne)
Date: Mon, 11 Feb 2002 20:55:20 -0500
Subject: CFS vs. loopback encryption (was Re: [open-source] File encryption)
Message-ID: <20020211205520.A854@long-haul.net>

for information, i released a text which describes a security hole in
the encrypted loop device for linux. Because of it an
attacker is able to modify the content of the encrypted device
without being detected. This text proposes to fix the hole by
authenticating the device.

the text can be found in http://www.off.net/~jme/loopdev_vul.html

> In article <56A53A20-175F-11D6-9052-000393471DA8 at pobox.com>,
> Nicholas Brawn  <ncb at pobox.com> wrote:
> >What are people's thoughts on CFS vs. loopback encryption? I've used CFS
> >in the past and found it quite useful, though as Matt said - a little
> >long in the tooth. Never really looked into loopback encryption (which
> >I'm aware is not something present across the majority of Unixes).
> 
> I use loopback encryption on Linux (loop-aes.sourceforge.net).
> I'm very happy with it.  I have it encrypting data with a passphrase
> and swap with a random key.
> 
>    - Ian


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From dahonig at cox.net  Mon Feb 11 21:02:26 2002
From: dahonig at cox.net (David Honig)
Date: Mon, 11 Feb 2002 18:02:26 -0800
Subject: Where's the smart money?
In-Reply-To: <Pine.SOL.4.30.0202120047220.9402-100000@kruuna.Helsinki.FI
 >
References: <F504A8CEE925D411AF4A00508B8BE90A01E90C2C@exna07.securitydynamics.com>
Message-ID: <3.0.6.32.20020211180226.007ae210@mail.orng1.occa.home.com>


Old money is analogue, and therefore decays in a gradual
fashion.  The Treasury (via the banks) culls fading bills.

An RFID would be digital and would fail catastrophically.

This is an important difference.

[Moderator's note: enough on the RFID now. It is far away from crypto. -Perry]
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ian at cypherpunks.ca  Tue Feb 12 09:37:09 2002
From: ian at cypherpunks.ca (Ian Goldberg)
Date: 12 Feb 2002 09:37:09 -0500
Subject: CFS vs. loopback encryption (was Re: [open-source] File
	encryption)
In-Reply-To: <20020211205520.A854@long-haul.net>
References: <20020211205520.A854@long-haul.net>
Message-ID: <1013524629.31460.50.camel@janus.paip.net>

On Mon, 2002-02-11 at 20:55, Jerome Etienne wrote:
> for information, i released a text which describes a security hole in
> the encrypted loop device for linux. Because of it an
> attacker is able to modify the content of the encrypted device
> without being detected. This text proposes to fix the hole by
> authenticating the device.
> 
> the text can be found in http://www.off.net/~jme/loopdev_vul.html

I'm not sure I believe that that's the right threat model.  If an
attacker can modify your encrypted device and return it to you without
your knowledge, surely he could more easily just patch your losetup to
record your passphrase, or replace AES with the identity transform,
or something more fundamental like that?

Once the attacker gets root or physical control over your device, I'd be
hard-pressed to consider it part of your TCB any more.

That being said, if your encrypted device *isn't* part of your TCB,
you do have a good point.  If you make an encrypted filesystem out of
an NFS-mounted file, say (I'm not sure this is actually possible),
or a removable disk, then what you point out is really important.

Many people use an encrypted filesystem in case the machine is lost or
stolen; once the machine transitions from being in your TCB to out of
it, I don't think it can come back in very easily.

   - Ian

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From weinmann at cdc.informatik.tu-darmstadt.de  Tue Feb 12 13:23:22 2002
From: weinmann at cdc.informatik.tu-darmstadt.de (Ralf-P. Weinmann)
Date: Tue, 12 Feb 2002 19:23:22 +0100
Subject: FlexiProvider 1.1.1 released
Message-ID: <20020212192322.A1476@cdc-ws1.cdc.informatik.tu-darmstadt.de>

Release announcement: FlexiProvider version 1.1.1
=================================================

FlexiProvider - Harnessing the power of the Java Cryptography Architecture
http://www.flexiprovider.de

The FlexiProvider group is pleased to announce the availability of version
1.1.1 of our open source toolkit for the JCA/JCE. The FlexiProvider toolkit
was previously known as cdcProvider, however in late 2001, our research
group decided to change the name of the toolkit.

Several significant changes have occured since the last release of the
provider, which was the cdcProvider 1.9.1:

    * The Standard Provider has been renamed to Core Provider.

    * The message digest SHA-1 was optimized for better performance.

    * Since NTT no longer supports the adoption of the E2 cipher, we decided
      to drop it in the current release of the Core Provider.

    * The mode classes for the symmetric ciphers were rewritten. This resulted
      in a higher throughput for these ciphers.

    * Design changes werde made to the class BasicCipher, which mode classes
      and padding classes interoperate with.

    * The EC provider now supports both GF(p) and GF(2n) arithmetic.

    * Furthermore, support for ECElGamal was dropped for security reasons
      and is now superseded by the integrated encryption scheme ECIES.

    * Support for the Diffie-Hellmann key exchange protocol ECDH was added
      as well as the Nyberg-Rueppel style signature scheme ECNR.

    * The block cipher SAFER++ (a NESSIE candidate) has been implemented and
      is available in the Core Provider.

    * The Number Field Provider, wich formerly was being announced but then
      withheld from the public, has now been released in an alpha-beta version. 

    * Bugs impairing the functionality of the provider were found and fixed in
      the Asymmetric ECB, RSA PKCS #1 v1.5 and v2.1 cipher as well as in the
      RSA PKCS #1 v1.5 signature classes.

As numerous bugs have been fixed we recommend users of the cdcProvider upgrade
to the latest version of the FlexiProvider as soon as possible.


Regards,
The FlexiProvider group

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From declan at well.com  Tue Feb 12 17:40:02 2002
From: declan at well.com (Declan McCullagh)
Date: Tue, 12 Feb 2002 17:40:02 -0500
Subject: SafeWeb's anonymous-surfing technology is not that safe
Message-ID: <20020212174002.B486@cluebot.com>

The Martin-Schulman paper:
http://www.cs.bu.edu/techreports/pdf/2002-003-deanonymizing-safeweb.pdf

PrivSec's free SafeWeb-licensed service: (username: demo, password: secure)
http://www.privasec.com/regusers/demolaunch.htm

---

http://www.wired.com/news/politics/0,1283,50371,00.html
   
   SafeWeb's Holes Contradict Claims
   By Declan McCullagh (declan at wired.com)
   12:35 p.m. Feb. 12, 2002 PST
   
   WASHINGTON -- SafeWeb's anonymous-surfing technology turns out not to
   be very safe after all.
   
   A pair of researchers has unearthed flaws in the CIA-funded product
   that contradict the company's claims of "complete privacy" and reveal
   the supposedly confidential information of customers.
   
   Founded in April 2000, SafeWeb marketed an advertising-supported
   service said to allow users to browse the Web anonymously. In
   interviews, SafeWeb CEO Jon Chun boasted that the technology had been
   "through the rigors of the CIA's stringent review process, which far
   exceeds those of the ordinary enterprise client."
   
   Citing the economic downturn, SafeWeb abandoned the free service in
   November 2001. It has licensed its anonymizing technology to another
   company, PrivaSec, which currently offers the service for free and
   plans to charge for it soon.
   
   In a paper (PDF) released on Tuesday, David Martin, a Boston
   University computer scientist, and Andrew Schulman of the Privacy
   Foundation say that SafeWeb's assertions were more hopeful than true.
   
   They say, and SafeWeb has acknowledged, that flaws in the company's
   architecture allow a website to use JavaScript to obtain the concealed
   Internet address of the visitor. Because of SafeWeb's centralized
   technology, that page can also download a browser's cookies and obtain
   copies of subsequent Web pages visited during that session.

   [...]



-------------------------------------------------------------------------
POLITECH -- Declan McCullagh's politics and technology mailing list
You may redistribute this message freely if you include this notice.
Declan McCullagh's photographs are at http://www.mccullagh.org/
To subscribe to Politech: http://www.politechbot.com/info/subscribe.html
This message is archived at http://www.politechbot.com/
-------------------------------------------------------------------------


----- End forwarded message -----

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From adam at cypherspace.org  Tue Feb 12 18:16:17 2002
From: adam at cypherspace.org (Adam Back)
Date: Tue, 12 Feb 2002 23:16:17 +0000
Subject: CFS vs. loopback encryption (was Re: [open-source] File encryption)
In-Reply-To: <1013524629.31460.50.camel@janus.paip.net>; from ian@cypherpunks.ca on Tue, Feb 12, 2002 at 09:37:09AM -0500
References: <20020211205520.A854@long-haul.net> <1013524629.31460.50.camel@janus.paip.net>
Message-ID: <20020212231617.A576723@exeter.ac.uk>

It's quite hard to guarantee that no one has unattended access to your
machine at any time.  

A paranoid user could checksum his binaries, and keep the checksum and
minimal boot image on a flash USB fob, or boot off a CDROM, and keep
the checksum on flash.  Then the user could again consider the machine
part of the TCB modulo hardware keyboard sniffers etc.

So it might be nice for an encrypted file system to have native
support for authentication based on the password for this reason also.

Of course said paranoid users could always do their own authentication
using hmac or whatever of the entire file system contents, but
built-in support could more efficiently do this for larger file
systems by MACing parts (sectors?).

Adam

On Tue, Feb 12, 2002 at 09:37:09AM -0500, Ian Goldberg wrote:
> On Mon, 2002-02-11 at 20:55, Jerome Etienne wrote:
> > for information, i released a text which describes a security hole in
> > the encrypted loop device for linux. Because of it an
> > attacker is able to modify the content of the encrypted device
> > without being detected. This text proposes to fix the hole by
> > authenticating the device.
> > 
> > the text can be found in http://www.off.net/~jme/loopdev_vul.html
> 
> I'm not sure I believe that that's the right threat model.  If an
> attacker can modify your encrypted device and return it to you without
> your knowledge, surely he could more easily just patch your losetup to
> record your passphrase, or replace AES with the identity transform,
> or something more fundamental like that?
> 
> Once the attacker gets root or physical control over your device, I'd be
> hard-pressed to consider it part of your TCB any more.
> 
> That being said, if your encrypted device *isn't* part of your TCB,
> you do have a good point.  If you make an encrypted filesystem out of
> an NFS-mounted file, say (I'm not sure this is actually possible),
> or a removable disk, then what you point out is really important.
> 
> Many people use an encrypted filesystem in case the machine is lost or
> stolen; once the machine transitions from being in your TCB to out of
> it, I don't think it can come back in very easily.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Tue Feb 12 17:43:56 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 12 Feb 2002 17:43:56 -0500
Subject: The encrypted jihad
Message-ID: <p05100313b88f4adcb025@[10.0.1.2]>

http://www.salon.com/tech/feature/2002/02/04/terror_encryption/print.html


The encrypted jihad
We can't stop terrorists from using uncrackable codes. So we shouldn't even
try.

- - - - - - - - - - - -
By Barak Jolish

Feb. 4, 2002 | Here's a tip for Treasury Department agents tracking
al-Qaida's finances: You might want to pay a visit to the volume discount
department at Dell Computer. Al-Qaida, it seems, has been an avid consumer
of computers over the last several years, and is especially fond of
laptops. It isn't hard to understand why. With his hectic, on-the-go
lifestyle, no self-respecting terrorist can function without a computer
that fits comfortably on an airplane tray table. Alleged "20th hijacker"
Zacarias Moussaoui, for instance, used his to research crop dusters, quite
possibly in preparation for a biological attack on a densely populated
American city. Ramsi Yousef used a laptop he accidentally left in a Manila
apartment to plan his extensive itinerary, which included assassinating the
pope in the Philippines, attacking an Israeli Embassy in Thailand, and
bombing the World Trade Center in 1993.

It's not surprising, then, that the seizure of computers has become a
primary goal for U.S. soldiers scouring Afghan caves and ambushing Taliban
and al-Qaida operatives. Ironically, though, winning possession of this
equipment on the battlefield may be the easy part; terrorists today have
the capacity to protect data with encryption schemes that not even
America's high-tech big guns can crack. The number of possible keys in the
new 256-bit Advanced Encryption Standard (AES), for example, is 1 followed
by 77 zeros -- a figure comparable to the total number of atoms in the
universe.

Luckily, not all encryption is hopelessly secure. Ramsi Yousef was careless
in protecting the password to his encrypted files, giving the FBI
relatively easy access to their contents. It took the Wall Street Journal
only days to decrypt files on two Al-Qaida computers that used a weak
version of the Windows 2000 AES cipher in Afghanistan. The U.S. cannot,
however, count on such carelessness indefinitely.

But recent changes in U.S. policy have actually reduced restrictions on the
spread of sophisticated encryption. In January 2000, for instance, the
Clinton administration ruled that "retail products" that undergo a
one-time, 30-day government review can be exported to nearly all countries
(with the exception of Cuba, Iran, Iraq, Libya, North Korea, Sudan and
Syria) without any government licensing requirement. Revisions published
later that year relaxed even these limitations for products exported to the
15 nations of the European Union and several of their major trading
partners. The practical effect of these reforms has been that the
industrial-strength Windows 2000 128-bit High Encryption Pack is now freely
available over the Internet to anyone, including Hamburg residents such as
presumed Sept. 11 ringleader Mohammed Atta.

Since Sept. 11, some commentators and lawmakers have suggested that the
U.S. reverse itself once again, and redouble efforts to control encryption.
On the surface, this sentiment is understandable -- it is difficult to
argue against any moves that may prevent future terrorist attacks on the
scale of the WTC disaster. This position is, however, dead wrong.

Quite simply, the U.S. regime of strict encryption controls didn't make
sense before Sept. 11, and it doesn't make sense now. The starkest
illustration of this reasoning is the case study of Israel, which is
simultaneously a leader in encryption product exports and a major focus of
terrorist attacks.

Before President Clinton's 2000 reforms, proponents of encryption export
controls were besieged from all sides: on the left and right flanks privacy
advocates argued that strong encryption is vital to protecting individual
liberty against government intrusion. First Amendment devotees launched a
frontal attack in the courts, claiming that encryption code was essentially
speech. Most effective, however, was the carpet bombing of lobbyists and
campaign contributions from the software industry -- the Microsofts, IBMs
and Suns of the world -- who argued that export controls simply drove
customers seeking secure products to companies in other countries -- such
as Israel. These companies estimated their losses in billions of dollars,
and noted the costs to workers as well; even domestic companies were hiring
independent overseas software developers to create encryption products.

Though their agendas differed, the above parties were united in their
claims that the government's policy stood little chance of significantly
controlling criminal use of encryption. First, they noted that producing
encryption algorithms takes few resources beyond advanced mathematical
training. In fact, sometimes even these skills are not necessary; in early
1999 a 16-year-old Irish high school student named Sarah Flannery developed
a new data-encryption algorithm that was 22 times faster than the popular
RSA algorithm used in many business transactions today.

Second, reform advocates stressed that there is no practical way to keep
encryption within or without the confines of physical borders. For
instance, anyone can purchase a copy of the encryption program Crypto II on
the streets of Moscow for $5, and then e-mail it to a friend in New York.

Third, legal controls on encryption will bind only those who decide to
follow the law. Terrorists who are willing to fly a jet into the side of a
building will have no qualms about breaking laws against illegal
encryption. Finally, encryption advocates claim that government control
stifles development of the strong encryption we need to protect computer
networks from attacks by hackers and other criminals, and to secure our
systems for air traffic control, electrical distribution, financial markets
and telecommunications.

But hasn't Sept. 11 changed the equation? Americans have, after all, now
come to accept that they will have to compromise on issues like privacy or
economic growth in favor of increased security.

It is specifically in the aftermath of this trauma that where it becomes
instructive to look at the policy of Israel, a country defined by its
obsession with security. The Israeli predicament is essentially a starker
version of that of the U.S. On the one hand, Israel has faced six wars in
its first 50 years, and confronts terrorist shootings and suicide bombings
virtually every week. Both the Israeli army and the FBI have confirmed that
Hamas and other Islamic militants regularly use the Internet to transmit
encrypted instructions for terrorist attacks -- including maps,
photographs, directions, codes and technical details about how to use
bombs. On the other hand, Israel's economy is among the most reliant in the
world on high technology exports. In fact, the share of Israel's
information technology exports as a percentage of services exports is
surpassed only by Japan. All of this has helped earn a country with few
natural resources other than potash a per capita GDP of $17,500 -- higher
than that of several members of the European Union.

In this context it is significant that in 1998 Israel, too, revised its
rather draconian encryption laws, granting regulators a great deal of
flexibility to permit the export of strong encryption products -- including
a "free means" category for which all license requirements are waived.
These changes were prefaced by a government report that noted the futility
of limiting "the use of means that can be freely obtained from many public
sources," and said that the law should permit Israeli companies to develop
and export "competitive products that can be marketed in most of the
world's countries as off-the-shelf products." In fact, even before the 1998
liberalization, flexible enforcement had allowed Israeli companies such as
Checkpoint Software to dominate the network security field.

The lesson from the Israelis is not how to control terror -- they don't
seem to have better answers than anyone else -- but rather how to live with
it and continue to function with as little social and economic disruption
as possible. If, as President Bush tells us, we're in this war for the long
haul, we simply cannot afford to sap our economic strength to prop up the
fantasy that we can control the actions of terrorists by fiat. There are
some battles we just shouldn't fight.



- - - - - - - - - - - -
About the writer
Barak Jolish is an attorney at the intellectual property law firm of Fish &
Neave in Palo Alto, Calif.

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Tue Feb 12 17:06:36 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 12 Feb 2002 17:06:36 -0500
Subject: U.S. Backing for Guidelines on Fighting Cybercrime
Message-ID: <p05100306b88f4250ae1f@[10.0.1.2]>

http://www.nytimes.com/2002/02/12/technology/12CYBE.html?todaysheadlines=&pagewanted=print



February 12, 2002


U.S. Backing for Guidelines on Fighting Cybercrime


By BARNABY J. FEDER


he first guidelines for responding to attacks on computer systems to be
endorsed by both the F.B.I. and the Secret Service, the main Federal
agencies fighting such crimes, were published yesterday.

The guidelines were drafted by government and private security experts
brought together by CIO magazine, a trade publication for information
technology executives.

The guidance comes at a time when the number of both government and private
organizations trying to track and fight electronic crimes has been
expanding, partly in response to Sept. 11. But experts say many businesses
continue to be reluctant to provide law enforcement officials with enough
information to pursue cybercriminals. Companies often fear that they will
lose business if security breaches become public or that they will become
the target of revenge attacks.

"People are very fearful of all the publicity that surrounds going after
someone and convicting them," said Bruce Schneier, chief technology officer
of Counterpane, a computer security company based in Cupertino, Calif.

Such fears can be overcome in many cases, said Ronald L. Dick, the F.B.I.
official who heads the government's National Infrastructure Protection
Center. "They'll share information with us every time if they have an
inkling we can prosecute successfully," Mr. Dick said. Still, he said, the
new guidelines should help fight fears that the government agencies would
respond to intrusion reports "by seizing your server and putting yellow
tape around it."

The 12-page CIO guidelines provide complete contact information for
businesses to report intrusions to public authorities and various
information-sharing partnerships like the 65 InfraGard chapters the F.B.I.
has helped set up around the nation. They also outline practices that the
F.B.I. and Secret Service advocate, like developing relationships with
electronic crimes experts at the agencies ahead of time so that managers
have a personal contact to take their call.

The guidelines advise against reporting minor intrusions, like the efforts
of outsiders to scan corporate systems for ways to penetrate them. Such
probes can occur hundreds or even thousand of times a month at a major
company. While such information could be useful in theory, the guidelines
say, it would swamp the current data systems of clearinghouses like the
National Infrastructure Protection Center or the Internet Storm Center,
which is operated by the SANS Institute, an international research
organization for security experts.

Breaches of computer defenses by worms, viruses, hacks and other intrusions
that cause damage are another matter. Law enforcement officials need all
the help they can get in catching up with such activity, said Bruce A.
Townsend, special agent in charge of the Secret Service's financial crimes
division.

"This is constantly evolving, unlike something like drug trafficking," Mr.
Townsend said.

Most experts say cybercrimes cost billions of dollars annually. Last year,
only 36 percent of those who experienced intrusions reported them to
authorities, according to an annual survey by the Computer Security
Institute and the San Francisco office of the F.B.I.

Mr. Townsend said the major part of the guidelines was not the standardized
form for reporting intrusions but the emphasis on planning ahead. Some
experts argue though that few companies will do an adequate job in that
regard unless forced to by regulatory authorities.

"We need metrics of how prepared people are for cyberattacks and provisions
like the Securities and Exchange Commission required for Y2K for corporate
disclosure," said Harris N. Miller, president of the Information Technology
Association of America, a trade group that has participated in organizing
information-sharing groups on security matters.
Home | Back to Technology | Search | Help 	Back to Top


Copyright 2002 The New York Times Company | Privacy Information
-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Tue Feb 12 17:45:08 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 12 Feb 2002 17:45:08 -0500
Subject: JIBC Review of Brands' Book
Message-ID: <p05100314b88f4b49c9d7@[10.0.1.2]>

http://www.arraydev.com/commerce/JIBC/0104_01.htm


Rethinking Public Key Infrastructures and Digital Certificates and Privacy
------------------------------------------------------------------------

A Review of Rethinking Public Key Infrastructures and Digital Certificates
and Privacy, Stefan A. Brands, MIT Press 2000. ISBN 0-262-02491-8.

Reviewed by Martin Nemzow
E-mail: mnemzow at networkperf.com
Web: www.networkperf.com
------------------------------------------------------------------------
This is a background book for technical staff and some managers involved in
e-commerce or its implementations. Its focus is clearly described by its
title and does not wander from that topic. Much of the content is academic
and very mathematical. Less-formal discussions, such as on topics of
authentication implementation and smart cards, are unparalleled in current
security literature because they are balanced but also supported with
significant scientific and mathematical documentation. I read the book and
ignored the proofs on the first pass, reading only for ideas and content.
On the second pass, I still skipped some proofs, but delved into others
because of their relevance to some of my actual current implementation and
marketing activities.

At some point, in real ecommerce activities, security bypasses the implicit
need and becomes an explicit, legal, and fiduciary responsibility. At that
stage, when you need to be as well-versed as a professional and aware of
foundations in security, this book represents a formal and precise
reference. This college-level textbook is not a light reading, nor is it
intended to be. Note that much of the book is highly mathematical with
elaborate proofs of security, workflow, and implementations. To that
degree, it is not a typical security manual or a book to read curled up in
front of the fireplace on vacation. However, this book is a good contrast
to "Secret and Lies" by Bruce Schneier because it focuses on the scientific
path rather than the social engineering one. There is a distinct place for
both types of books. With that representation, it is a great reference for
any specialist in electronic security because of its scholarly grounding in
security theorems and proofs.

This book focuses on the background for public key infrastructures and the
mechanisms that create security. Half of this book is driven to the
mathematics and the allegation of how certificate verification should work
and what can be done to improve it. Do not overlook other parts in the
book, which have a tremendous technical overview dealing with privacy, an
ill-defined concept that everyone quotes and wants, but has failed to
define, measure, or realistically implement. In this context, Mr. Brands
defines privacy as the confidence to deliver information without having
compromise. Focus in his book is establishing validity and authenticating
security certificates in workflow. Relevant and referenced applications
include electronic cash, electronic postage, digital rights management
(such as copyright protection), protection of health information, and ways
to enable electronic voting. The proofs are actually a great litmus test
when talking with vendors--if you're into the mathematics and want to
validate technical support or developers with those vendors. However, the
overview is actually much more informative than security books aimed at the
mass market because of the formal structure and the lack of spurious or
unsubstantiated assertions.

For example, Mr. Brands specifically explains how public key
infrastructures can be applied for banking activities to authenticate
individuals, process, and transactions. This is of relevance to JIBC
readers because theft of identity is likely to become increasingly
expensive crime in e-commerce and Internet banking. The rewards are great,
the risk is low, and the current infrastructure remains so insecure. The
burden of making identity theft wrongs right will fail to those with the
deep pockets, the banks, brokerages, and businesses. Chapter 6 is
specifically geared towards smart card operation. Smart cards will have
increasing value in the banking community as a means to limit exposure and
extent of losses. The epilogue explains what can go wrong with this
technology that is sufficient background for anyone talking to vendors. It
is also useful to impress and assess potential security hires and
subordinates. It is a shame that the references are the usual security ACM
journal articles and commercial press; the academic depth in the book
itself outshines the usual stale security assertions. I would have hoped
that the references would have opened new doors to security threads, but
the book itself does a lot of that.

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From xrc at ieee.org  Tue Feb 12 04:27:53 2002
From: xrc at ieee.org (N. Ronald Crandall)
Date: Tue, 12 Feb 2002 01:27:53 -0800
Subject: Where's the smart money?
In-Reply-To: <p05100307b88cb93655c7@[10.0.1.2]>
Message-ID: <4.3.2.7.1.20020212012448.00b1eb30@mail.cwia.com>

[Moderator's note: I'd called an end to this but this one insight was
quite cute. --Perry]

At 04:05 PM 2/10/02, you wrote:
>.... Also unlike bar codes, RFIDS can be read
>remotely without having to be in the line of sight of the reader.

  My, how convenient this is for the pickpockets and muggers.
They can now target their efforts to the most profitable
targets.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From bill.stewart at pobox.com  Wed Feb 13 04:54:51 2002
From: bill.stewart at pobox.com (Bill Stewart)
Date: Wed, 13 Feb 2002 01:54:51 -0800
Subject: Announce: San Francisco Cypherpunks, Sat 2/16/02, 6pm - 225
  11th, SF
Message-ID: <5.0.2.1.1.20020213012203.039425d0@idiom.com>

This announcement will be at 
http://cryptorights.org/cypherpunks/meetingpunks.html
and is being sent to several cypherpunks-related mailing lists.
===============================================

The San Francisco Bay Area Cypherpunks Meeting will be
Saturday, February 16, 2002, at Don Ramon's Restaurant, 225 11th St, San 
Francisco.


As usual, this is an open public meeting on US soil.
Everyone's invited, including non-US-citizens, and several suspected Canadians
will be present :-)

Our agenda is a widely-held secret.
Predicted topics include Intrepid Traveller Bill Scannell's trip to Cuba,
discussion of the crypto and data-sharing presentations from Codecon,
potentially a couple of projects that were too late for Codecon,
and generally what everybody's been doing and working on.

The unusual time and place are because the Codecon conference www.codecon.org
will be a block away at the DNA Lounge www.dnalounge.com Friday-Sunday 
afternoons,
and the RSA conference will be at the San Jose Convention Center the 
following week.
A number of cypherpunks will be speaking at Codecon (See people.html and 
schedule.html.)

The RSA Conference appears to have decided to protect their agenda through 
Obscurity;
you can obtain PDFs of the agenda from their website if you have Multimedia 
Flash :-)
Codecon is a low-priced conference; RSA has high-priced talks, low-priced 
exhibits,
and the usual vendor parties.

=================== DIRECTIONS AND PARKING ====================================
Don Ramon's Restaurant - Look for Usual Suspects, probably upstairs.
	The restaurant serves family-style Mexican food, as well as
	caffeine and ethanol, and is said to be pretty good.

Directions: 	225 11th St. is a block north of the DNA Lounge,
	for which directions are available at http://www.dnalounge.com/directions/ .

 From the South Bay:
	Take 101 North to the 9th Street / Civic Center exit.
	Take 9th Street, and turn left onto Harrison, then right onto 11th.

 From the East Bay:
	From the Bay Bridge, take I-80 West to the 9th Street / Civic Center exit.
	Keep right at the fork in the ramp. Turn left onto Harrison, then right 
onto 11th.

By Public Transit:
	The nearest BART stations are at 16th and Mission and Civic Center (Market 
and Hyde),
	both about 3/4ths of a mile away.
	There are bus stops at 11th and Harrison (right outside the club),
	and at Market and Van Ness (four blocks away).
	From Caltrain, it appears that the #47 bus is probably the best choice.

Parking is easy for once:  Ample public parking is available at the Costco 
parking lot,
	at the corner of 11th and Harrison. The parking lot entrance is on 11th.
	You can also find free street parking, but beware of the street cleaning 
signs.

=============================================================================



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ptrei at rsasecurity.com  Wed Feb 13 08:55:19 2002
From: ptrei at rsasecurity.com (Trei, Peter)
Date: Wed, 13 Feb 2002 08:55:19 -0500
Subject: Announce: San Francisco Cypherpunks, Sat 2/16/02, 6pm - 225 1
	1th, SF
Message-ID: <F504A8CEE925D411AF4A00508B8BE90A01E90C44@exna07.securitydynamics.com>

> Bill Stewart[SMTP:bill.stewart at pobox.com]
> 
> The San Francisco Bay Area Cypherpunks Meeting will be
> Saturday, February 16, 2002, at Don Ramon's Restaurant, 225 11th St, San 
> Francisco.
	[...]

For the last 4 years I've been able to arrange space at the RSA conference
for the adjacent Cypherpunks meeting. I apologize for not doing so this
year.
There were a number of factors:

1. RSA is running Monday -> Friday instead of the usual Sunday -> Thursday,
so the Saturday cp meet is no longer adjacent to the conference, which
allowed
us to get a room while setup was going on around us.

2. RSA is in San Jose, but Codecon is in SF, and is closely aligned with
list
member interests. Next year, RSA will be back at the Moscone center in SF.

3. Due to conflicts, I'm not out on the West Coast till Monday afternoon, so
I
can't host or attend the meeting personally. I'm really annoyed about that
:-(.

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

As to the RSA conference web site, I've raised a stink about certain facets 
of it, and there will be a Flash-free site next year.

Peter Trei


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Wed Feb 13 10:47:23 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 13 Feb 2002 10:47:23 -0500
Subject: The Secret Lives of Numbers
Message-ID: <p05100336b8903b021c49@[10.0.1.2]>


--- begin forwarded text


Status:  U
From: "Gordon Mohr" <gojomo at usa.net>
To: <fork at xent.com>
Subject: The Secret Lives of Numbers
Date: Wed, 13 Feb 2002 01:17:05 -0800
Sender: fork-admin at xent.com
List-Id: Friends of Rohit Khare <fork.xent.com>

More search-engine datamining, interesting topic, vivid applet.

Does your ATM code appear more often than the numbers around it?

http://www.turbulence.org/Works/nums/index.html

# The authors conducted an exhaustive empirical study, with the aid of
# custom software, public search engines and powerful statistical
# techniques, in order to determine the relative popularity of every
# integer between 0 and one million. The resulting information
# exhibits an extraordinary variety of patterns which reflect and
# refract our culture, our minds, and our bodies.
#
# For example, certain numbers, such as 212, 486, 911, 1040, 1492,
# 1776, 68040, or 90210, occur more frequently than their neighbors
# because they are used to denominate the phone numbers, tax forms,
# computer chips, famous dates, or television programs that figure
# prominently in our culture. Regular periodicities in the data,
# located at multiples and powers of ten, mirror our cognitive
# preference for round numbers in our biologically-driven base-10
# numbering system. Certain numbers, such as 12345 or 8888, appear to
# be more popular simply because they are easier to remember.
#
# Humanity's fascination with numbers is ancient and complex. Our
# present relationship with numbers reveals both a highly developed
# tool and a highly developed user, working together to measure,
# create, and predict both ourselves and the world around us. But like
# every symbiotic couple, the tool we would like to believe is
# separate from us (and thus objective) is actually an intricate
# reflection of our thoughts, interests, and capabilities. One
# intriguing result of this symbiosis is that the numeric system we
# use to describe patterns, is actually used in a patterned fashion to
# describe.
#
# We surmise that our dataset is a numeric snaphot of the collective
# consciousness. Herein we return our analyses to the public in the
# form of an interactive visualization, whose aim is to provoke
# awareness of one's own numeric manifestations.
#
#   The Secret Life of Numbers by Golan Levin, et. al. (February 2002)
#   is a commission of New Radio and Performing Arts, Inc., for its
#   Turbulence web site. It was made possible with funding from The
#   Greenwall Foundation. Further information here.




http://xent.com/mailman/listinfo/fork

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From marius.corbu at analog.com  Wed Feb 13 18:50:41 2002
From: marius.corbu at analog.com (marius)
Date: Wed, 13 Feb 2002 15:50:41 -0800
Subject: Losing the Code War by Stephen Budiansky
References: <F504A8CEE925D411AF4A00508B8BE90A01E90C22@exna07.securitydynamics.com>
Message-ID: <3C6AFBD1.4A834BBE@analog.com>

"Trei, Peter" wrote:
> 
> > marius[SMTP:marius.corbu at analog.com] wrote:
> >
> > > marius wrote:
> > > > Not quite true. Encrypting each message twice would not increase the
> > > > "effective" key size to 112 bits.
> > > > There is an attack named "meet in the middle" which will make the
> > > > effective key size to be just 63 bits.
> > >
> > > Peter Trei wrote:
> > > > Don't forget that the MITM attack (which Schneier claims
> > > > takes 2^(2n) = 2^112 time), also requires 2^56 blocks
> > > > of storage.
> > > [...]
> > > > I don't lose sleep over MITM attacks on 3DES.
> >
> > 2^57 operations, with 2^56 blocks of storage manipulation can be
> > approximated to: 2^56 * log(2^56) + 2^56 * log(2^56) = 2^62 + 2^62 =
> > 2^63
> >
> > Betting on storage as a show stopper is not a good idea, regardless of
> > sleep pattern.
> >
> > Marius
> >
> Oh, I totally agree - my first followup (Feb 4) read:
> 
> - start quote -
> 
> Either way, my point stands: any attack which requires 2^56 blocks
> of storage is probably intractable for the time being, imho. 10 years
> from now, I'm not so sure.
> 
> - end quote -
> 
> The expansion of storage over the last 20 years is even more
> astonishing than the  speedup of microprocessors. The first IBM
> PC to ship with a HD (PC-XT ~1983) had a 5 Mb drive. When I
> worked for Columbia U, undergraduates were given about 50kb
> of diskquota for a semester.
> 
> Nevertheless, 2^56 blocks of centralized storage is a lot, and
> will remain a lot for a while.
> 
> Peter Trei

So let say that I don't have 2^56 blocks of centralized storage, but I
have 2^40. Now by independently guessing 16 bits of each Key1 and Key2,
I will need only 2^(56-16) = 2^40 blocks of centralized storage . But
the attack must be run now over 2^16 * 2^16 pairs of such tables to
allow all possible key pairs. So the time is on order of 2^(2*16) *
2^(56-16) = 2^72.

That means that I can make an time-memory tradeoff, such that it will
accommodate my resources. 

Marius

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ptrei at rsasecurity.com  Wed Feb 13 19:50:14 2002
From: ptrei at rsasecurity.com (Trei, Peter)
Date: Wed, 13 Feb 2002 19:50:14 -0500
Subject: Losing the Code War by Stephen Budiansky
Message-ID: <F504A8CEE925D411AF4A00508B8BE90A01E90C52@exna07.securitydynamics.com>



> ----------
> From: 	marius[SMTP:marius.corbu at analog.com]
> Sent: 	Wednesday, February 13, 2002 6:50 PM
> To: 	Trei, Peter
> Cc: 	Joshua Hill; 'Ben Laurie'; cryptography at wasabisystems.com
> Subject: 	Re: Losing the Code War by Stephen Budiansky
> 
> "Trei, Peter" wrote:
> > 
> > > marius[SMTP:marius.corbu at analog.com] wrote:
> > >
> > > > marius wrote:
> > > > > Not quite true. Encrypting each message twice would not increase
> the
> > > > > "effective" key size to 112 bits.
> > > > > There is an attack named "meet in the middle" which will make the
> > > > > effective key size to be just 63 bits.
> > > >
> > > > Peter Trei wrote:
> > > > > Don't forget that the MITM attack (which Schneier claims
> > > > > takes 2^(2n) = 2^112 time), also requires 2^56 blocks
> > > > > of storage.
> > > > [...]
> > > > > I don't lose sleep over MITM attacks on 3DES.
> > >
> > > 2^57 operations, with 2^56 blocks of storage manipulation can be
> > > approximated to: 2^56 * log(2^56) + 2^56 * log(2^56) = 2^62 + 2^62 =
> > > 2^63
> > >
> > > Betting on storage as a show stopper is not a good idea, regardless of
> > > sleep pattern.
> > >
> > > Marius
> > >
> > Oh, I totally agree - my first followup (Feb 4) read:
> > 
> > - start quote -
> > 
> > Either way, my point stands: any attack which requires 2^56 blocks
> > of storage is probably intractable for the time being, imho. 10 years
> > from now, I'm not so sure.
> > 
> > - end quote -
> > 
> > The expansion of storage over the last 20 years is even more
> > astonishing than the  speedup of microprocessors. The first IBM
> > PC to ship with a HD (PC-XT ~1983) had a 5 Mb drive. When I
> > worked for Columbia U, undergraduates were given about 50kb
> > of diskquota for a semester.
> > 
> > Nevertheless, 2^56 blocks of centralized storage is a lot, and
> > will remain a lot for a while.
> > 
> > Peter Trei
> 
> So let say that I don't have 2^56 blocks of centralized storage, but I
> have 2^40. Now by independently guessing 16 bits of each Key1 and Key2,
> I will need only 2^(56-16) = 2^40 blocks of centralized storage . But
> the attack must be run now over 2^16 * 2^16 pairs of such tables to
> allow all possible key pairs. So the time is on order of 2^(2*16) *
> 2^(56-16) = 2^72.
> 
> That means that I can make an time-memory tradeoff, such that it will
> accommodate my resources. 
> 
> Marius
> 
Well, I guess your resources include a LOT of time. 2^72 test
decryptions....
Lets be optimistic. Lets assume you can do a test every clockcycle, and
your cracker is running at 1GHz. How long would it take you to do 2^72
tests???

About 150,000 years, if my math is correct.

If Moore's Law holds out, you might get an answer in 20-30 years, for a
single message. (Subsequent ones would be a lot faster).

But it's all moot - no one who knows what they are doing uses 1 or 2 
key DES, and even 3 key DES is only being put in new apps until 
folks are more confident with 128+bit AES. 

Peter Trei






---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Wed Feb 13 23:20:04 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 13 Feb 2002 23:20:04 -0500
Subject: FBI Web Cache Mirror
Message-ID: <p0510036fb890eb6c8ee2@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Wed, 13 Feb 2002 20:57:02 -0800
To: cypherpunks at lne.com
From: John Young <jya at pipeline.com>
Subject: FBI Web Cache Mirror
Sender: owner-cypherpunks at lne.com

We had an e-mail exchange today with the FBI about
a bot coming to Cryptome daily to grab new files and
to check on old ones. We complained about the bot
taking over the site during its visit. The FBI explained
that the visits are part of a "web cache mirroring process:"

  http://cryptome.org/fbi-web-mirror.htm

We would appreciate hearing of other sites being mirrored
by the FBI. The IP address range of the MAS program:

  65.207.53.xxx

We have no objection to the FBI mirroring or by anybody else,
but misconfigured bots have been an annoyance for repeatedly
downloading old files, racking up tens of thousands error logs.
One today produced over 16MB of log files before we got the
user to wake up. Misconfigured WGet, as often, was the culprit.

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Wed Feb 13 23:20:22 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 13 Feb 2002 23:20:22 -0500
Subject: TLA Indexing and Mirroring
Message-ID: <p05100370b890eb7f9387@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Wed, 13 Feb 2002 21:12:02 -0800
To: cypherpunks at lne.com
From: John Young <jya at pipeline.com>
Subject: TLA Indexing and Mirroring
Sender: owner-cypherpunks at lne.com

To supplement the FBI bot message we note that
several TLAs and others visit each day to download
Cryptome home page, and sometimes individual
files. We assume the file listings are part of a general
Web gathering for internal distribtution. In the case of
NSA and the venerable bot of several years's almost
daily visits, it now just takes the home page and no
files. Later, various machines in the domain retrieve
files directly, that is bypassing the home page.

CIA began to visit daily recently, at least under an identifiable
domain name, ucia.gov. Before CIA visitors came via an
IP address not domain name. Not many files taken daily.
But a few are taken directly after the bot visits.

Dozens from .mil daily and, once or twice a week, eop.gov.
But never nro.mil or nro.gov, nor a visitor from fbi.gov.

The TLAs from other countries, what can be said of
them: they too are hungry for recognition after the years
of obscurity. It must be a bitch using anonymizers when
you ache for being noticed, like Hanssen and Ames and
all the others filled with hatred of spotlighted babbling
heads of agencies.

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Thu Feb 14 12:13:26 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 14 Feb 2002 12:13:26 -0500
Subject: Digital Money 5 Final Programme
Message-ID: <p0510038db891a0b5269b@[10.0.1.2]>


--- begin forwarded text


Status:  U
User-Agent: Microsoft-Entourage/9.0.1.3108
Date: Thu, 14 Feb 2002 16:20:34 +0000
Subject: Digital Money 5 Final Programme
From: "David G.W. Birch" <dgw-lists at birches.org>
To: Digital Bearer Settlement List <dbs at philodox.com>,	<dcsb at ai.mit.edu>
Sender: <dbs at philodox.com>
List-Subscribe: <mailto:dbs-on at philodox.com>

......... the fifth annual Consult Hyperion forum .........
.............. D I G I T A L ... M O N E Y ................


              Crowne Plaza Hotel, St. James
                        London
                 April 10th/11th, 2002

sponsored by RSA Security     supported by NCipher
         and DataCard                      American Express
                                       and Transys

in association with The Henley Centre

official publications Finance on Windows
                      Reach

.......................The Event............................

Now in its fifth year, the annual Digital Money Forum will
be two days of interactive discussion and debate from the
centre of the digital money world.

The Forum is not about technology or marketing: it is about
the whole subject of the digitisation of money and the
implications of that process for individuals, businesses
and governments. A central theme of this year's conference is
the increasing role of non-bank organisations in the evolution
of digital money systems.

Both speakers and delegates will be leaders in field,
looking at the evolution of electronic payments from the
retail, regulatory, bank, legal, sociological and other
perspectives. With experts in financial systems, interactive
TV, mobile commerce, mass transit, retail and related subjects
gathered in one place, the Forum will continue to be the place
to be for anyone who wants to understand Digital Money.

Last year, the audience came from as far afield as the USA
and Singapore to discuss topics ranging from the euro and
non-interest bearing currencies to pre-paid mobile
telephony and e-mail payments. This year, the subjects
already on the agenda include the role of mass transit
operators in introducing electronic cash to the European
Commission's Directive on "Electronic Money Insitutions" and
the potential for new payment technologies to implement
"social money".

Please note that due to the success of the Forum, this year
we have decided to limit the number of places to 70 in order
to preserve the much-valued interactive nature of the event.


........................Day One.............................
        Chairman: David Birch, Consult Hyperion

Charles Cohen             Garen Staglin
former ceo, Beenz (UK)    ceo EOne (US)

Cyprien Godard            Chad Warren
iPin (France)             The Henley Centre

Jack Selby                James Turk
Paypal (US)               Goldmoney (US)

Jon Clark                 Speaker to be confirmed
Transys                   DataCard

Edward Davey, Member of Parliament
Liberal Democrat spokesman on Treasury affairs

Followed by champagne round tables.

........................Day Two.............................
      Chairman: Mike Hendry, Payment Systems Consultant

Dominic Storey            Richard Cass
RSA Security              Sky Interactive

Tribh Grewal              David Boyle
Visa International        Author and Journalist (UK)

Bernard Lietaer           Thaer Sabri
Author "Future of Money"  Electronic Money Association

Carl Larkin               Dominic Peachey
American Express          Financial Services Authority

.....................Administration.........................

          The detailed programme is on line at
           http://www.digitalmoneyforum.com/

Thanks to the generosity of our sponsors, this year the
seminar costs only 595 pounds Sterling per person excluding
VAT.

The fee includes the seminar, documentation, meals, cocktails
and drinks around the champagne tables.

This is a not-for-profit event and any surplus generated is
distributed, as in previous years, to a variety of mainly
local charities.

For further information or to reserve a place please contact

Gloria Benson                  <glor at consult.hyperion.co.uk>
Telephone +44 1483 301793                Fax +44 1483 561657
============================================================

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Thu Feb 14 22:08:05 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 14 Feb 2002 22:08:05 -0500
Subject: FW: [sg-dc] Announcement
Message-ID: <p0510031ab8922bc3e2de@[10.0.1.2]>


--- begin forwarded text


Status:  U
From: "Bruce Potter" <gdead at shmoo.com>
To: "'R. A. Hettinga'" <rah at shipwright.com>,
   "'R. A. Hettinga'" <rahettinga at earthlink.net>
Subject: FW: [sg-dc] Announcement
Date: Thu, 14 Feb 2002 19:59:58 -0500

So which address works now? ;)
[all of them do, thanks to an RFC-violating A-record :-) -- RAH]
Could you forward this announcement to the list?  We're trying to drum
up interest in other areas besides DC and Seattle (we've got a chapter
starting there as well) and I figured DCSB was a good place to cover a
lot of geographic area.

later

bruce

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

The DC Security Geeks are proud to announce that, starting February
28th, there will be monthly meetings for security professionals in the
Northern Virginia / Washington DC area.  The meetings are free, and open
to all.

Meetings will be held on the last Thursday of every month at the
Virginia Tech graduate center (on the Metro in Falls Church, VA). They
will be from 7:30-9:30pm.  The exact room number will be posted in the
lobby the night of the meeting.

The DC Security Geeks web site has a mailing list, directions, meeting
information.  See dc.securitygeeks.com.

Detailed information on our first meeting is at the bottom of this mail.

Here are our upcoming events:

Feb. 28, 2002
- Bruce Potter, Verisign (author of an upcoming O'Reilly book on 802.11
security)
  802.1x -- What it Really Means to Wireless Security
- Open Discussion:State of The Security Industry in the DC area

Mar. 28, 2002
- Russ Housley, RSA Labs (co-author of Planning for PKI)
  PKI Future Directions

Apr. 25, 2002
- Shawn Geddis, Apple (head of the Secure Trusted OS Consortium)
(tentative)
  Apple OS X Security and the Secure Trusted OS Consortium

May 30, 2002
- John Viega, Secure Software (co-author of Building Secure Software)
(tentative)
  Why SSL isn't Securing Your Software

Securitygeeks is an effort to foster communication between security
professionals on a regional basis.  Computer security is a growing
concern these days, but most security events are either hacker cons or
technical tutorials. Through Securitygeeks, we are hoping to provide a
forum for folks to get together on a monthly basis, hear a few talks on
contemporary security issues, and network with other security geeks.
People interested in having a Security Geeks chapter in their own area
should mail us at sg.core at shmoo.com.

Here are the details on this month's event:

Talk: 802.1x -- What it Really Means to Wireless Security
Speaker: Bruce Potter, Verisign, Inc.

Abstract
Wireless networks are everywhere. While driving down the Dulles Toll
Road, you can pick up dozens of corporate wireless access points with
equipment available from any computer store. Most organizations are
unaware of the risks associated with having a deployed WLAN.
Unfortunately, even those that do understand the risks do not
necessarily understand how to secure themselves. 802.1x is a new
protocol to provide port level authentication for all IEEE 802 based
networks. Some companies claim 802.1x will be the savior of secure
wireless computing. Others see it as misguided and overly complex. This
talk will examine the risks in wireless computing and whether or not
802.1x can live up to its hype.

About the Speaker
By day, Bruce Potter is the Manager of Network and Security Operations
for the Mass Markets Division of VeriSign, Inc. By night, Mr. Potter
works on various independent network and security projects. He is the
author of a forthcoming O'Reilly book on 802.11 Wireless security. Mr.
Potter is the founder of NoVAWireless, a community wireless network
group for the greater Northern Virginia area. He is also the founder of
The Shmoo Group, a three-year old ad-hoc group of security professionals
scattered throughout the world. Mr. Potter spends his time working on
wireless security, large scale network architectures, assisting with
open source software projects, and complaining about insecure coding
practices.

Open Discussion: State of the Security Industry in the DC area

Between the ".com" layoffs, people in big industry and government, and
those who are still working at start-ups, what's the state of the
security industry in the DC area? How have we been influenced by the
bubble bursting and the recent September 11 attacks?




_______________________________________________
sg-dc mailing list
sg-dc at securitygeeks.com
http://www.securitygeeks.com/mailman/listinfo/sg-dc

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Thu Feb 14 22:11:42 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 14 Feb 2002 22:11:42 -0500
Subject: Will anonymous e-mail become a casualty of war?
Message-ID: <p0510031cb8922cbc1d9c@[10.0.1.2]>

http://www.cnn.com/2002/TECH/internet/02/13/anonymous.email.idg/index.html
  

Powered by	  
 

 SAVE THIS | EMAIL THIS | Close 
 
Will anonymous e-mail become a casualty of war?


By Tom Spring

(IDG) -- Ever wonder how to trace the trail of that spam, track its source,
and shut it down once and for all? These days, so does the U.S. government.

E-mail messages yielded a few clues to the location of abducted Wall Street
Journal reporter Daniel Pearl. But investigators complain the search for
Pearl is hampered by difficulties pinpointing where the e-mail originated.
Authorities have released few details, but apparently the e-mail was
prepared and sent in a way that made it difficult to track. In at least one
case, investigators were able to identify three Pakistanis who allegedly
had links to a particular PC used to send photos and messages about Pearl.

The Pearl case is just the latest current event fueling a contentious
debate over anonymity on the Internet. Tracking down bad guys is good
thing. But without anonymity, can free speech and whistle-blowers exist
online?

Options for anonymity

Sending anonymous e-mail is quite easy. Both fee-based and free services
pander to the paranoid and guarantee anonymity. Advicebox.com lets you send
e-mail anonymously and free through a Web-based interface. Anonymizer
charges $5 monthly for a subscription that supports anonymous e-mail and
Web browsing. Both it and QuickSilver also let you post messages
anonymously to Usenet groups. Other anonymous e-mail software programs
include Private Idaho and Potato, which make tracing an e-mail nearly
impossible.

The simplest way to send anonymous e-mail is through one of about 35
remailers. The service strips your e-mail of all electronic ties to you and
ships the message to its recipient. However, privacy purists point out that
the remailer still knows your real identity. So some remailers encrypt and
send e-mail through the Mixmaster network, developed by Anonymizer
president Lance Cottrell.

The Mixmaster network involves client software that runs on your PC, and
Mixmaster servers that forward your e-mail. The client can be used as a
plug-in for the QuickSilver e-mail client or with other remailer software.
When you use QuickSilver, e-mail is encrypted (under triple DES technology)
and sent to multiple Mixmaster servers, stripping the return address each
time and making e-mail impossible to trace. On the last leg of your
e-mail's journey, it's decrypted and delivered to an in-box. Cottrell
insists the Mixmaster remailer network is hack-and spook-proof.

"If a message is sent and you want to find out who sent it, there is no way
you can," Cottrell says..p>

Tiers of anonymity, paranoia

Most Internet users don't realize how easy it is to trace e-mail. For most
normal law-abiding people a Yahoo Mail account under a pseudonym is
sufficient.

However, e-mail sent from Web-based e-mail services like Yahoo or Hotmail
carry the fixed Internet protocol address of the PC or network used to send
the message. A site like Advicebox.com doesn't carry IP information with
its Web-based mail.

Advicebox.com keeps tabs of computers that visit its site but doesn't log
or record the e-mail sent through its service, according to Tim Cutting,
company spokesperson. But last year, Advicebox.com had to hand over the
electronic evidence to police when a recipient of a death threat delivered
by Advicebox.com e-mail reported it to police.

"AdviceBox keeps zero record of the e-mail contents sent from the site.
However, as with any computer server, it does keep a record of what ISPs
access the server and at what time," Cutting adds.

Anonymizer intentionally keeps no records of people's comings and goings,
making a subpoena useless, says Cottrell. How do the Feds feel about that?
Since September 11, law enforcement has not contacted Cottrell except to
sign up for his service. Cottrell says his clients include local cops, FBI
agents, and U.S. embassies.

Anonymous or responsible?

Most anonymous e-mail proprietors admit their products can be tools for
terrorists, pedophiles, and scammers. But they also point out that
anonymous e-mail can protect whistle-blowers or the politically oppressed,
and help shield the identity of people who would otherwise be afraid to
seek help over the Net.

"Just like any powerful technology, in the wrong hands it can be misused,"
says Rob Courtney, policy analyst with the Center for Democracy and
Technology. "It's quite clear the benefits of anonymous e-mail greatly
outweigh the risks," he claimed.

Certainly, anonymous e-mail can be a safe way for an employee to blow the
whistle on a questionable business practices, or to tip off police to a
crime. On the other hand, it also is easy to imagine anonymous e-mail
making it safe for terrorists to communicate, plan murderous attacks, or
issue ransom notes.

"The abuse bothers me," acknowledges Richard Christman, the developer of
QuickSilver. But he says free speech is more important. Anonymizer's
Cottrell says his services have helped many, such as Yugoslavian
human-rights activists during the Milosovec regime. Also, an airline
mechanic once inquired about Anonymizer so he could anonymously tip off
airline executives to shoddy maintenance practices.

Anonymity: A smoking gun?

Anonymity is an important aspect of free speech, say government legal
agencies. But if it's used for a crime, law enforcement will try to strip
away the cloak.

The FBI likens anonymous e-mail to guns. Like firearms, services and
software are legal, but if they're used in a crime, the FBI will take
action. "If we need to, we will investigate," says Steven Berry, an FBI
spokesperson. Tracing e-mail has helped catch bad guys, such as the
Philippino creator of the I Love You virus. It also identified a University
of California at Irvine student whose e-mail message threatened to "hunt
down and kill" Asian students.

Late last year, the U.S. government got some serious investigative help
when Congress passed the Patriot Act in response to the terrorist attacks.
The measure gives government the authority to monitor e-mail and other
electronic communication and share that information among agencies. "E-mail
is just one clue to the larger crime," says a representative of the
Department of Justice, of the new tools provided by the Patriot Act.

Last November, the FBI acknowledged the existence of Magic Lantern, a
Trojan horse program under development. It is intended to render encryption
useless by logging the keystrokes on a suspect's PC. That will only help in
some cases, however; if FBI officials can't figure out who is sending
e-mail, how can they plant a bug on the computer?

Sensibility drift

The threat to online privacy is real, say privacy activists. They argue
that anonymous e-mail, in an age of cookies, Web bugs, and government
surveillance, may be even more important today than before September 11.

Since the terrorist attacks, public and political sensibility has shifted
regarding privacy, says Beth Givens, director of the Privacy Rights
Clearinghouse. Americans are now more willing to accept facial recognition
technology at the Olympics, show a personal ID to virtually anyone who
asks, and surrender their anonymity online.

That sensibility has reached the Internet. Anonymous Internet usage is
getting harder to achieve. Just days after the terrorist strike, the
government required ISPs to open their records in hope of finding
electronic leads.

Zero Knowledge, which ensured anonymous Internet access, shut down its
Freedom Network, which provided anonymous e-mail and Web surfing. SafeWeb
closed its free anonymous Web browsing service, too. Both say they halted
anonymous Net access not because of government pressure, but because they
were not commercially viable.

Privacy advocates say this weakens consumers' protection from government
and big business. Givens says anonymous remailers are not a rogue tool, but
one of the Net's last free speech vehicles. She argues the Internet has
also become less anonymous as companies use libel suits to find and unmask
their online critics.

Legal prying continues

In fact, civil and criminal investigations have pried at anonymous
communication. Anonymity could have helped 21 Raytheon employees who riled
Raytheon executives on a Yahoo bulletin board. Raytheon was so upset by the
postings, which it alleges disclosed confidential information, that it
forced Yahoo by court order to reveal the users' identities. Charges were
eventually dropped.

Remailers, though legal, are not immune from such investigations. At the
request of California police and the Church of Scientology, Finnish police
ordered Johan Helsingius to identify an Internet user who allegedly stole
files from the church and was using Helsingius' remailer technology to post
them on Usenet groups.

In 1999, Canadian Carl Edward Johnson used a remailer network called
Cypherpunks to send rambling but threatening messages to Bill Gates, the
IRS, and government officials. Investigators pieced together rants posted
on Web sites, in e-mail messages, and writing found at his home to confirm
his identity.

The issue raises concern throughout the political spectrum. Anonymous
communications has a long, proud history in the United States, says Adam
Thierer, of the Cato Institute, a right-wing Libertarian think tank. In
1776, Thomas Paine's Common Sense, a pamphlet urging separation from
Britain, was released under the pseudonym "An Englishman."

"Paine didn't hide his identity to be cute or clever. He did it so he
wouldn't be thrown in jail or put to death," Thierer says. "Anonymity is a
key component to free speech and political discord."

The most cautious even worry that some remailers are operated by hackers or
government agents.

"There is no evidence that any of these tools of anonymity have ever been
used by a terrorist," says Anonymizer's Cottrell. But then again, if
terrorist did use Cottrell's Anonymizer service, how would anyone know?

 
 

 
Find this article at:
http://www.cnn.com/2002/TECH/internet/02/13/anonymous.email.idg/index.html
 

 SAVE THIS | EMAIL THIS | Close 
 Check the box to include the list of links referenced in the article.

 
 



-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Fri Feb 15 07:53:20 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Fri, 15 Feb 2002 07:53:20 -0500
Subject: Results, Not Resolutions
Message-ID: <p05100325b892b50e24c0@[10.0.1.2]>

http://www.securityfocus.com/news/315

Results, Not Resolutions
A guide to judging Microsoft's security progress.
By Bruce Schneier and Adam Shostack
Jan 24 2002 3:50AM PT
Last week, Bill Gates published a company-wide memo outlining a new
strategic direction for Microsoft. Comparing this to the change when the
company embraced the Internet, Gates elevated security to Microsoft's
highest priority. By focusing on what he called "Trustworthy Computing,"
Gates plans on transforming Microsoft into a company that produces software
that is available, reliable, and secure.


"We must lead the industry to a whole new level of Trustworthiness in
computing." - Bill Gates internal memo, 15 January 2002.

Trust is not something that can be handed out; it has to be earned. And
trustworthiness is a worthy goal in computing. But unlike performance goals
or feature lists, progress toward it is hard to measure. How can we
determine if one piece of software is more secure than another? Or offers
better data integrity than another? Or is less likely to contain
undiscovered vulnerabilities? How do we know if Microsoft is really
committed to security, or if this is just another performance for the press
and public? It's not as easy as measuring clock speeds or comparing feature
lists; security problems often don't show up in beta tests.

As longtime security experts, we'd like to suggest some concrete ways to
evaluate Microsoft's (and anybody else's) progress towards trustworthiness.

These are specific and measurable changes that we would like Microsoft to
make. This is not intended to be an exhaustive list: building secure
software requires much more than what we delineate here. Our goal is to
provide a list of measurable recommendations, so that the community can
judge Microsoft's sincerity.

Some of our recommendations are easier to implement than others, but if
Microsoft is serious about security and wants to take a true leadership
position, they can't shirk any of them. Some of our changes are easier to
verify than others, but it is our goal that all of them be independently
measurable. In the end, the pronouncements and press releases don't mean a
thing. In security, what matters are results.

If we can distill our recommendations into a single paradigm, it's one of
simplicity. Complexity is the worst enemy of security, and systems that are
loaded with features, capabilities, and options are much less secure than
simple systems that do a few things reliably. Clearly Windows is, and
always will be, a complex operating system. But there are things Microsoft
can do to make even that complex system simpler and more secure. Microsoft
must focus its programmers on designing secure software, on building things
right the first time.

I. Data/Control Path Separation


"Security models should be easy for developers to understand and build into
their applications." -Gates memo.

One of the simplest, strongest, and safest models is to enforce a rigid
separation of data and code. The commingling of data and code is
responsible for a great many security problems, and Microsoft has been the
Internet's worst offender.

Here's one example: Originally, e-mail was text only, and e-mail viruses
were impossible. Microsoft changed that by having its mail clients
automatically execute commands embedded in e-mail. This paved the way for
e-mail viruses, like Melissa and LoveBug, that automatically spread to
people in the victims' address books. Microsoft must reverse the security
damage by removing this functionality from its e-mail clients, and from
many other of its products. This rigid separation of data from code needs
to be applied to all products.

Microsoft has compounded the problem by blurring the distinction between
the desktop and the Internet. This has led to numerous security
vulnerabilities, based on different pieces of the operating system using
system resources differently. Microsoft should revisit these design
decisions.

We recommend the following modifications in the next release of these
Microsoft products. In short: illustrate the actions, and provide a sandbox
environment. This release should be focused only on removing insecure
features and adding security.

Office: Macros should not be stored in Office documents. Macros should be
stored separately, as templates, which should not be openable as documents.
The programs should provide a visual interface that walks the user through
what the macros do, and should provide limitations of what macros not
signed by a corporate IT department can do.

Internet Explorer: IE should support a complete separation of data and
control. Java and JavaScript should be modified so they cannot use external
programs in arbitrary ways. ActiveX should eliminate all controls that are
marked "safe for scripting."

E-mail: E-mail applications should not support scripting. (At the very
least, they should stop supporting it by default.) E-mail scripts should be
attached as a separate MIME attachment. There should be limitations of what
macros not signed by a corporate IT department can do.

.NET: .NET should have a clear dilineation of what can act and what cannot.
The security community has learned a lot about mobile code security from
Java. Mobile code is very dangerous, but it's here to stay. For mobile code
to survive, it should be redesigned with security as a primary feature.

Implementation of Microsoft SOAP, a protocol running over HTTP precisely so
it could bypass firewalls, should be withdrawn.

II. Default Configurations


"Our products should emphasize security right out of the box." -Gates memo.

Microsoft software, by default, installs with many more features than most
users need or want. This makes the software more vulnerable than necessary.
There are many recent examples of this. The recent Universal Plug-and-Play
bugs work even if you don't know what UPnP does, or whether or not you're
using it. The SuperCookie bug in Windows Media Player works even if you
don't use WMP. Code Red successfully attacks IIS installations, even in
Windows setups that aren't being used as a Web server.

Additionally, features must be installable one by one. In UNIX, for
example, a Web server and an ftp server are separate, and must be installed
separately. With IIS, installing a Web server not only installs a Web
server, but also an ftp server, a Gopher server, and Bill himself probably
doesn't know what else.

It's not enough to give users the ability to turn off unneeded features.
Users don't even know which features are turned on, much less how to turn
them off, and the features might accidentally get turned on again. The best
prevention for attacks against a feature is for the feature not to be there.

We recommend that the next release of all Microsoft products have default
installations with the most minimal feature set possible, and that
additional features require special installation activity to make them
work. We also recommend that this installation be visible to the user, so
that the user knows the features are there. We recommend that Microsoft
ensure that all features can be installed and uninstalled separately, as
well as in common packages. We recommend that unneeded features not be
installed, instead of being installed and disabled. Additional controls
should be implemented to allow a corporate IT department to prohibit
certain features from being installed.

We also recommend that .NET come with the ability to use configurations
from a variety of sources, including Microsoft, its competitors, and public
interest/advocacy groups like the Electronic Frontier Foundation.

III. Separation of Protocols and Products


"As software has become ever more complex, interdependent and
interconnected, our reputation as a company has in turn become more
vulnerable." -Gates memo.

Today Microsoft builds large, complex services that intermingle many
smaller services. For example, the Microsoft file-sharing protocol contains
file sharing, registry sharing, remote editing, printer sharing, password
management, and a host of other services. If a user wants one of those
services, he has to implement them all.

These need to be split into separate services, running on separate bits of
server software so that a user can choose which to install where. Absent
that, the complexity of the software grows to demonstrably insecure levels.

We recommend that Microsoft separate functionality so that the user can
install only the specific functions they need. We also recommend that
Microsoft provide, and allow others to provide, a variety of pre-bundled
functions. Most users don't want to install individual functions, and will
rely on others to tell them what they need.

IV. Building Secure Software


"So now, when we face a choice between adding features and resolving
security issues, we need to choose security." -Gates memo.

Commercial software is full of bugs, and some of those bugs harbor security
vulnerabilities. This is not meant to excuse Microsoft's long-standing
apathy towards security; it's merely a statement of fact. These bugs are
caused by bad software specification, design, and implementation.

Much of what we discuss above (data/command separation, default
configurations, separate software for separate protocols) has the effect of
minimizing the impact of software bugs by reducing the amount of software
on a computer. However, there will still be a great deal of software on any
computer, and that software needs to be resilient to attack. This means
that the software doesn't easily break when attacked. And if it does break,
the system as a whole doesn't fall apart. Today, we can worry that a single
bug in Windows will render a server completely insecure, or a single bug in
IIS will expose all the data in .NET. Today Microsoft software is brittle;
it needs to be resilient.

There is much Microsoft can do to make its software more resilient, and our
recommendations could go on for pages. But generally speaking, certain
features are more fragile than others. We recommend the following:

Microsoft should drop all plans for automatic software updates via the
Internet until they can be done securely and reliably. Today there are too
many problems with updates and patches to allow them to occur without the
user's knowledge, and too many problems with authentication to prevent
others from maliciously using the capability to attack systems.

Microsoft should eliminate all centralized customer databases in its .NET
services. These databases are too dangerous to keep in one place; the
ramifications of a security breach are too great.

Microsoft is already moving towards signing code files. While we recommend
that Microsoft continue this practice, we also recommend that Microsoft not
rely on code signing for security. Signed code does not equal trustworthy
code, something the security community graphically demonstrated through the
many ActiveX vulnerabilities. Microsoft should drop the code-signing
security paradigm in favor of the sandbox paradigm.

Today, too many Microsoft server components run as Administrator. When a
service runs as Administrator, it is much easier for a security flaw to
result in the machine being fully compromised. Under UNIX, servers are
often designed to run as a normal user. This should be the default
configuration for Microsoft servers as well.

All other Microsoft features should be evaluated for resilience. Those that
are too risky should be removed until they can be rewritten and secured.

V. Transparency and Auditability


"If there is any way we can better protect important data and minimize
downtime, we should focus on this." -Gates memo.

Too much of the Microsoft operating system operates invisibly, without the
user's knowledge. Too much of it functions without leaving audit records of
what happened. With each successive version of the Microsoft operating
system, it has become increasingly difficult for a user to control his own
system or to examine what his system is doing. This has disastrous security
ramifications, and should be reversed.

We recommend that Microsoft add strong auditing capabilities to all
products, both operating systems and applications software. We recommend
that Microsoft provide configuration tools along with its operating system,
as well as tools for an IT department to manage the configurations of its
computers. We would also like to see Microsoft abandon the Registry in
favor of a less opaque and more user-friendly system.

VI. Advance Publication of Protocols and Designs


"There are many changes Microsoft needs to make as a company to ensure and
keep our customers' trust at every level-from the way we develop software,
to our support efforts, to our operational and business practices." -Gates
memo.

If there's one thing that security experts have learned over the years,
it's that any system, when initially proposed, will have security bugs. The
only reliable remedy is to publish system details early, and let the
security community examine them.

Microsoft needs to publish specifications for protocols in advance and
encourage public comment. This is doubly important for security protocols
and systems. If a portion of the software is critical to security, then
there is no way to achieve trustworthiness without publication. Publication
does not ensure security, but it's an unavoidable step in the process.

We're not suggesting that Microsoft must give up all proprietary rights to
its protocols and interfaces, or allow anyone to implement or use its
standards. We are saying that they must be public, not secret.

The published specifications must be complete, readable, and generally
available. It's not sufficient to make the specifications available to
specific researchers, or to people who have signed non-disclosures or paid
for the privilege. Again, this is not easy from a business point of view,
but if Microsoft is serious about putting security first, it needs to
engage rather than ignore the security community. And Microsoft should wait
before implementing those specifications in products

We recommend that all protocols and interfaces used in Microsoft software
be immediately published, and a one-year moratorium be placed on all
non-security modifications to those protocols. We also recommend that
Microsoft publish any new protocols or interfaces at least one year before
implementing them in products.

In addition to making its protocols and interfaces public, we suggest that
Microsoft consider making its entire source code public. We're not
advocating that Microsoft make its products open source, but if they really
want to impress everyone about their newfound security religion, they will
make their code available for inspection. Honestly, we don't expect
Microsoft will do this. It's too much of a cultural change for them to even
consider.

VII. Engaging the Community


"Compensation plans of Microsoft product engineers, such as raises and
bonuses, will also be tied to how secure their products are." -Associated
Press article on Gates memo, 15 January 2002.

Tying security to compensation is the best way to effect a cultural change
inside Microsoft. We feel that Microsoft needs to go further, and reward
not only Microsoft employees but independent researchers. Microsoft can no
longer threaten, insult, or belittle independent researchers who find
vulnerabilities in their products.

Microsoft needs both automated security reviews and evaluations by security
experts. A great deal of work in this area has already been done outside
Microsoft. We recommend that Microsoft devote resources towards
comprehensive security reviews for all of its code, using security experts
both inside and outside the company. We also recommend that Microsoft set
up an independent body to evaluate security vulnerabilities found by
researchers outside the company.

Conclusion


"Eventually, our software should be so fundamentally secure that customers
never even worry about it." -Gates memo.

Our recommendations are by no means comprehensive. There's substantially
more involved in building secure software than the seven items we list
here. These items are intended to be near-term milestones; they're
recommendations more about implementation than architecture.

Buffer overflows, everyone's favorite whipping boy, are a comparatively
easy implementation-level problem to fix. Higher-level constructs, such as
implementing a scripting engine or securing inter-process communications,
are more complicated design-level issues. But if Microsoft doesn't start
with the simpler stuff, they're never going to get to the hard stuff.

Security isn't easy, nor is it something that you can bolt onto a product
after the fact. Making security Microsoft's first priority will require a
basic redesign of the way the company produces and markets software. It
will involve a difficult cultural transition inside Microsoft. It will
involve Microsoft setting aside short-term gains in order to achieve
long-term goals. It's a difficult goal, and we believe that Microsoft can
do it. We hope that they remain committed.

Bruce Schneier is Chief Technology Officer of Counterpane Internet Security
Inc. Adam Shostack is Director of Technology at Zero-Knowledge Systems, Inc.


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Fri Feb 15 13:03:08 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Fri, 15 Feb 2002 13:03:08 -0500
Subject: "Free-space" optics
Message-ID: <p0510034cb892fd6222e7@[10.0.1.2]>

http://www.economist.com/printedition/PrinterFriendly.cfm?Story_ID=987690&CFID=301055&CFTOKEN=47471685&






Optical communications
Cutting the cable
Feb 14th 2002
>From The Economist print edition
"Free-space" optics requires no fibre. That may be an advantage

FIBRE optics revolutionised communication by abolishing the law that light
can travel only in a straight line. From that point on, light signals could
be treated in the same way as electrical ones, and bent round corners. Some
people, however, are never satisfied. And these dissatisfied engineers are
trying to turn the clock back by developing systems that use "free-space"
optics-in other words sending information from place to place by shining
laser beams through the air.

Free-space optics has three advantages. It is easy to install. It can
handle a technology known as wavelength division multiplexing (WDM)
without, as it were, blinking. And it seems suited to a new-and allegedly
uncrackable-encryption technique called quantum key distribution.

Speed of installation comes from not having to dig up the road to lay
conduits. Free-space optics may thus be an answer to the difficulty of
providing broadband connections to customers' homes and offices-the
so-called "last mile". Free-space links that operate at speeds of up to 20
gigabits a second-as good as fibre-have now been demonstrated. They can be
installed in hours rather than the weeks or months normally needed for
broadband access. And if they can be put into place quickly, they can be
upgraded quickly, too.

That matters in the context of WDM, a technique that allows a single
optical path to carry thousands of parallel channels, as long as each is
encoded in a slightly different colour. Upgrading a fibre network for WDM
is hard. First, individual fibres are each compatible with only a few WDM
schemes. The exact chemical composition of a fibre's glass determines how
transparent it is to different frequencies, and also its tendency to
disperse those frequencies even when it is transparent. Both restrictions
reduce the number of channels that can be carried. Moreover, even if a
particular fibre can be used with a particular scheme, the light sources,
amplifiers, switches and associated paraphernalia usually cannot.
Amplifiers, for instance, will not boost all colours equally, so special
devices are necessary to compensate.

Free-space optics suffers from none of these problems. Air is transparent
to a wide range of frequencies and has few dispersive tendencies (at least,
when the weather is good). And with the associated kit clustered together
in base stations, upgrades are easy to carry out.

The third advantage-for quantum key distribution-is more speculative. The
technique exploits the arcana of quantum mechanics to let two computers
swap a cryptographic key (and thus the means to decode a message) with
perfect security.

Quantum key distribution has been demonstrated successfully in fibres, but
it suffers from one major drawback: it requires a dedicated link, and so
cannot be implemented in a network. However, two experiments carried out in
the past few weeks have shown that it works with free-space optics. First,
researchers at QinetiQ, a British-government-owned company, and Ludwig
Maximilian University, in Munich, Germany, exchanged keys between two
alpine mountain-tops more than 23km apart, though they did so at night,
when sunlight could not confuse the signal. Then, another group of
researchers, from Los Alamos National Laboratory in New Mexico, announced
that they had performed a 10km key exchange in broad daylight.

These two groups are working towards military applications in which the key
is exchanged from the ground to a satellite. But both recognise that the
technology might be exploited commercially, and are part of a European
Union collaboration called QuComm that is encouraging this.

Free-space optics would have the odd drawback, such as flocks of birds,
showers of snowflakes or banks of fog interrupting the beams. But
message-encoding systems are already set up to cope with lost data. Many
customers might be willing to put up with a 99.999% available service that
could be installed straight away, rather than waiting indefinitely for the
100% availability of fibre.


Copyright ? 2002 The Economist Newspaper and The Economist Group. All
rights reserved.


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Fri Feb 15 20:56:12 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Fri, 15 Feb 2002 20:56:12 -0500
Subject: Uh, that's Gold*berg*...(was re: Freedom Network source code now
 available)
Message-ID: <p0510035ab8936bde182c@[10.0.1.2]>

http://www.theregister.co.uk/content/55/24094.html

  15 February 2002
  Updated: 23:15 GMT
------------------------------------------------------------------------
Freedom Network source code now available
By Andrew Orlowski in San Francisco
Posted: 15/02/2002 at 22:57 GMT

CodeCon Source code for ZeroKnowledge Systems' discontinued anonymous
Internet service has leaked onto the Web, apparently with the blessing of
ZKS' Chief Scientist Ian Goldman.

The announcement was made on Goldman's behalf at the CodeCon conference by
Len Sassaman, co-organizer of the three day grassroots P2P and crypto
conference .

Until early last October, Freedom Network offered anonymous web surfing and
email with a comprehensive, belt-and-braces approach to anonymity involving
dedicated servers, tricky routing tactics and the generation of noise
traffic. All packets were encrypted. ZKS discontinued the service but
denied that the decision was a consequence of the post-September 11
hysteria.

"Right now there simply isn't enough market buy-in on the premium services
to justify the network's operating costs....support for the Freedom network
offering was removed from the client code base well before the recent
tragedies of September 11," wrote Goldman.

According to the README, "Zero-Knowledge is releasing this code under an
RSAREF style license, to encourage academic research and other
non-commercial use." Other licenses are respected, and the release is
entirely unsupported.

The main tarballs is a 12.5MB download, PGP encrypted with the "traditional
magic words" (one of which is a big bird). You can find it here?


Related Stories
Zero-Knowledge bags anonymity service
Nortel helps stalk you on line


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Sat Feb 16 00:12:37 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Sat, 16 Feb 2002 00:12:37 -0500
Subject: World Wide Web Consortium Issues XML Signature as a W3C
 Recommendation
Message-ID: <p0510035eb8939a9c13a0@[10.0.1.2]>

http://www.w3.org/2002/02/xmlsignature-pressrelease




World Wide Web Consortium Issues XML Signature as a W3C Recommendation

Joint work with IETF produces XML-based solution for digital signatures,
foundation for Secure Web services

Contact America --
Janet Daly, <janet at w3.org>, +1.617.253.5884 or +1.617.253.2613
Contact Europe --
Marie-Claire Forgue, <mcf at w3.org>, +33.492.38.75.94
Contact Asia --
Saeko Takeuchi <saeko at w3.org>, +81.466.49.1170


(also available in French and Japanese)


Testimonials are also available.
------------------------------------------------------------------------

http://www.w3.org/ -- 14 February 2002 -- The World Wide Web Consortium
(W3C) has issued XML-Signature Syntax and Processing (XML Signature) as a
W3C Recommendation, representing cross-industry agreement on an XML-based
language for digital signatures. A W3C Recommendation indicates that a
specification is stable, contributes to Web interoperability, and has been
reviewed by the W3C Membership, who favor its widespread adoption.

"XML Signature is a critical foundation on top of which we will be able to
built more secure Web services," explained Tim Berners-Lee, W3C Director.
"By offering basic data integrity and authentication tools, XML Signature
provides new power for applications that enable trusted transactions of all
sorts."

Digital Signatures are Essential to Web Services

Digital signatures are created and verified using cryptography, the branch
of applied mathematics concerned with transforming messages into seemingly
unintelligible forms and then back again. Digital signatures are created by
performing an operation on information such that others can confirm both
the identity of the signer, and the fidelity of the information. This
capability is important to a growing number of XML protocol, publishing and
commerce applications.

XML Signature Combines Data Integrity with Extensibility

While there are technologies one can use to sign an XML file, XML Signature
brings two additional benefits.

First, XML Signature can be implemented with and use many of the same
toolkits one is using for XML applications.

Second, XML Signature can process XML as XML instead of a single large
document. This means multiple users may apply signatures to sections of
XML, not simply the whole document.

As more commercial applications are used to send XML documents through a
series of intermediaries, the ability to sign sections of a document
without invalidating other portions is invaluable, whether for invoices,
orders, or applications.

One may independently sign an XML payload from the XML envelope that
carries it for a short period. As a result, when you remove, add or change
the protocol envelope the signature on the payload itself is still valid.

Similarly, XML Signature provides flexibility when a signed XML form is
delivered to a user. If the signature were over the full XML form, any
change by the user to the default form values would invalidate the original
signature. XML Signature permits both the original form and user's entries
to be independently signed without invalidating the other.

And of course, while XML Signature is tailored to XML processing, it can be
used to sign any data, such as a PNG image.

XML Signature Supports XML Encryption and Key Management

XML Signature serves as the foundation for other ongoing W3C work including
XML Encryption, which provides a mechanism to secure parts of XML
documents, and XML Key Management, which provides a simple protocol for
lightweight XML applications to obtain the key necessary for signature and
encryption.

IETF/W3C Brings Together Industry Experts; Public Review

The XML Signature Working Group is the first joint W3C/IETF Working Group,
and is the first W3C technical Working Group to operate entirely as a
public group. This provided independent developers with a clear window on
the XML Signature work in all stages of development, and brought a wide
range of implementation experience. XML Signature already enjoys
significant support and deployment, as highlighted in the testimonials.

Participants in the joint IETF/W3C Working Group included representatives
from organizations whose lead research and commercial work in the area of
digital signatures and security, including Accelio, Baltimore, Capslock,
Citigroup, Corsec, Georgia State University, IAIK TU Graz, IBM, Microsoft,
Motorola, Pure Edge, Reuters Health, Signio, Sun Microsystems, University
of Siegen, University of Waterloo, VeriSign Inc., and XMLsec.

About the World Wide Web Consortium [W3C]

The W3C was created to lead the Web to its full potential by developing
common protocols that promote its evolution and ensure its
interoperability. It is an international industry consortium jointly run by
the MIT Laboratory for Computer Science (MIT LCS) in the USA, the National
Institute for Research in Computer Science and Control (INRIA) in France
and Keio University in Japan. Services provided by the Consortium include:
a repository of information about the World Wide Web for developers and
users, and various prototype and sample applications to demonstrate use of
new technology. To date, over 500 organizations are Members of the
Consortium. For more information see http://www.w3.org/


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

Press Release


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


Testimonials


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



-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From zefram at fysh.org  Sat Feb 16 17:15:02 2002
From: zefram at fysh.org (Zefram)
Date: Sat, 16 Feb 2002 22:15:02 +0000
Subject: theory: unconditional security
Message-ID: <E16cD6k-00005i-00@bowl.fysh.org>

I've been looking at cryptographic protocols that give unconditional
security -- I'm interested in some of the possibilities that go beyond
what a simple one-time-pad can achieve -- and I'm having difficulty
in finding published papers on the subject.  Applied Cryptography only
describes the classical one-time-pad, noting "a one-time-pad provides
no authenticity", and doesn't go any further.

I've found a description of a construction of a MAC giving unconditional
integrity: if we have a message M where 0<=M<p (p prime), and a key
K=(a,b) where 0<=a,b<p, then we can calculate a MAC m_K(M) = a + bM
(mod p).  That source suggested sending (M, m_K(M)) as a message which a
man in the middle cannot successfully fake (because he can't generate the
MAC); it suggested that to get secrecy as well one should have another
key k, 0<=k<p, and send (M+k mod p, m_K(M)), which is a one-time-pad
encrypted message plus MAC.

However, that MAC system misses the possibility that, if we add the
constraint b!=0, the message M can be recovered from m_K(M) by the
recipient (who knows K).  So it's actually possible to have unconditional
secrecy and integrity with the key only twice as long as the message,
transmitting only m_K(M) = a + bM (mod p), if one can detect a fake
message by it being nonsensical.  (Any modification to the transmitted
m_K(M) will cause the decryption process to generate garbage over which
the attacker has no influence, which seems a reasonable definition of
unconditional integrity.  One can make the chance of a successful spoof
arbitrarily small by making the message space arbitrarily sparse --
e.g., require that the message be a multiple of 2^42 -- and so this
is more flexible in the level of integrity it can provide than the
message-plus-MAC scheme is.)

I've not been able to find any paper that describes the use of this
algorithm to give unconditional secrecy and integrity at once.
Nor have I found any paper describing doing this (as MAC or as
secrecy-plus-integrity) in GF(2^n), which makes it convenient to operate
on bit strings.  This seems so stunningly useful that I'm surprised it's
not mentioned in AC.

Can anyone point me at references that I'm missing?

-zefram

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From perry at piermont.com  Sat Feb 16 17:56:52 2002
From: perry at piermont.com (Perry E. Metzger)
Date: 16 Feb 2002 17:56:52 -0500
Subject: 802.11x insecure?
Message-ID: <87eljldoi3.fsf@snark.piermont.com>


Various news stories have been noting that the 802.1x security
protocol seems to have flaws. See, for example:

http://www.theregister.co.uk/content/55/24091.html

and the actual paper at:

http://www.cs.umd.edu/~waa/1x.pdf

Perry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Sun Feb 17 16:42:57 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Sun, 17 Feb 2002 16:42:57 -0500
Subject: Report on a James Bamford Talk at Berkeley
Message-ID: <p051003a9b895d448eb82@[10.0.1.2]>

http://www.lewrockwell.com/orig2/bamfordreport.html


 
Report on a
James Bamford Talk at Berkeley

James Bamford is the author of The Puzzle Palace and Body of Secrets, books
about the National Security Agency. He is visiting Berkeley in the School
of Public Policy, and gave a talk entitled "Intelligence Failures that Led
to the September 11th Attacks."

He was introduced by the Dean of the School, who explained that the school
has a new emphasis on information technology and public policy. The Dean
explained that while it is generally true that "Those who know don't speak,
and those who speak don't know," James Bamford is the exception. The Dean
said that Bamford was working on a new book A Killing Sleep: Anatomy of
America's Greatest Intelligence Failure, a description of what happened
prior to Sept. 11.

Bamford started by providing lots of background. He was fresh out of law
school and didn't want to practice law, so he had the idea of writing about
the most secret agency in the US Government, the National Security Agency
(NSA). This led to the now twenty year-old book, The Puzzle Palace. NSA
eventually found out that he was writing, and tried very hard to stop him.
NSA twice arranged to have him criminally prosecuted for revealing secrets,
but he was able to show that he had used material in the public domain.
Bamford explained that he had become an expert in using the Freedom of
Information Act (FOIA) to get a lot of information. It's not so easy,
because the FOIA doesn't apply to the NSA since the NSA almost doesn't
exist. It was not created by Congress, but by a memorandum. When he wrote
his first book, the rule was that once a document was declassified, it
could not subsequently be reclassified (sort of a no ex post facto idea).
According to Bamford, Reagan changed those rules, allowing and in fact
doing a lot of reclassification, Clinton didn't change the Reagan rule but
didn't do reclassification, and the current Bush administration has adopted
the Reagan rules.

NSA was created after WWII from the code breaking activity that had
proceeded during the war. At the time it was created, no one but a couple
of people even knew it had been created. NSA stands for no such agency, or
never say anything, or after Puzzle Palace, not secret anymore. To
illustrate how secret NSA is, after Puzzle Palace was published, Bamford
went on a book tour. At one point he was scheduled onto a PBS show where
the other guest was Sen. Bill Bradley. Prior to the show, the Senator asked
Bamford why he was on the show, and he explained that he had written a book
on the NSA. Bradley asked him what that was, and Bamford explained. Then
Bradley went on the show to explain his ideas for the economy, or whatever,
and then the interview switched to Bamford. Bamford explained that the NSA
was a secret agency. The interviewer said "How secret?" And, naturally,
Bamford did not pass on the opportunity to say that it was so secret that
not even Sen. Bradley knew about it. Bradley was not pleased.

Years later, having worked on television news shows, Bamford did a second
NSA book. It also took three years. His first idea was to go to NSA and ask
for a tour, interviews, and documents. They were not accommodating, to say
the least. "Enemy of the state." "Not in your interest to proceed."
However, eventually NSA turned around, and eventually provided him with
access to lots of information, although they never provided documents.
Again, FOIA came through.

Bamford explained that he was amazed by some of the material he was able to
get. For example, he found a detailed 1962 plan to invade Cuba. In the wake
of the failed Bay of Pigs invasion, the US was embarrassed and wanted to
dump Castro some other way. The idea was to have the US Armed Forces invade
Cuba, deposed and kill the leadership, and establish a new government.
Basically do to Cuba what we just did to Afghanistan, Bamford explained.
However, there was a problem. The US needed a pretext to invade.
Unfortunately for the invasion plan, we didn't know of anything that Castro
was doing to the US besides sitting there being decidedly Communist. So, a
pretext had to be created. The plan Bamford found, through FOIA, sent a
chill down his back. The US would arranged to have Americans shot on the
streets of US cities, we would set off bombs in crowded areas of US cities,
and there was a detailed plan to blow up a commercial airliner over Cuba.
This plan was approved, in 1962, by every member of the Joint Chiefs,
including the chairman. [If this is true, the plan was never executed.]

About NSA: it is 38,000 people, 50 buildings, on a campus in Maryland, in
suburban Washington DC. The have the most powerful computers in the world,
1.6 million tapes in their tape library [tapes?]. Basically they do signals
intelligence, listening to phone calls, faxes, email, and any sort of
communication. To do this they have extensive facilities all around the
world. One technique that Bamford mentioned was how they capture microwave
signals. Microwave, unlike high frequency signals [HF are actually lower
frequency than microwave, in case you care], do not bounce off the
ionosphere and travel in a straight line. Towers must be line of sight from
each other. So how's the NSA going to listen to this? Answer is that some
of the radiation goes past the receiving station, and continues in its
straight line out into space. The NSA has satellites out there to grab the
signals. [Bamford described the satellites as geosynchronous, but that
wouldn't work.] NSA also makes and breaks codes. The big nasty secret
within NSA is that in the forty years or more that NSA spent billions of
dollars on breaking the Soviet codes, they made no progress. No important
Soviet code was ever broken by the NSA, or by anyone.

NSA has a whole bunch of listening posts around the world. There's one in
England. Each post captures about two million messages per hour. They cull
out the interesting ones in many ways - limiting prefixes, etc. The Soviets
had a listening post in Cuba for forty years (they are only just now
dismantling it) and they knew how to filter out the interesting stuff. For
example, any phone call to prefix 456 in the DC area code was a call to the
White House, any call to 688 is a call to NSA.

So what about NSA's involvement in Sept. 11. Some have compared the failure
to the "failure" at Pearl Harbor. Actually, Pearl Harbor was quite a
success for the predecessor agencies to NSA. The US had managed to
completely break the key Japanese codes (Purple), and the German codes
(Enigma) were also broken. In the case of Pearl Harbor, the US signals
people picked up the key message to the Japanese embassy in Washington,
decoded it (it said something like break off relations and destroy all your
crypto equipment) well in advance of the attack. The message did not say
where an attack would come, so the US sent the message to everyone saying
"Japanese attack expected." The weather was wrong over the Pacific so the
usual HF path did not work. Instead the message was sent to Honolulu via
Western Union, where it arrived a few hours after the attack.

In contrast, NSA did nothing to help prior to Sept. 11. No monitoring of
Osama Bin Laden (OBL) was done. The hijackers of the plane that would up
hitting the Pentagon lived in Laurel, MD, the same town that NSA was in.
When the hijackers drove from Laurel down US 1 toward Dulles, the traffic
in the other direction was mostly NSA employees on their way to work.
Rather embarrassing to the NSA, in fact a disaster of major proportions.
Realize that the primary goal of NSA, the justification for the billions of
dollars per year of our citizens money spent by the NSA, is simply to
prevent a surprise attack. Yet the US and NSA was caught totally
unprepared. Bush was reading to first graders in Sarasota, the head of NSA
was having breakfast in downtown Washington.

OBL moved his operations from the Sudan to Afghanistan. The infrastructure
there was insufficient for OBL's needs, so he contacted an intermediary in
London who in turn arranged for a student in the US to buy a satellite
phone. The phone was mailed to London, the service activated there, and the
phone mailed to OBL. It was an Inmarsat phone. So NSA has a billion
dollars, they figured this out and got good eavesdropping on OBL. NSA was
very proud of this, and would show off their abilities to distinguished
guests at NSA. They would laugh as he called his mother and talked to her.
Unfortunately, OBL seemed to sense something, because he never used the
satphone for operational material. Just used it for calls home. But this is
still useful: at least we know where he is, because the phone radiates, and
that radiation can be tracked. And we took advantage of that: Clinton
called for reprisals against OBL after the embassy bombings in E. Africa,
and we sent missiles to a training base in Afghanistan that we knew about
because of the satphone. Unfortunately, two bad things resulted: one, OBL
was not there when the missiles arrived, and two, OBL, no dummy, stopped
using the satphone when he realized it was being used to track him. The NSA
never heard from him again. Never. NSA went deaf.

NSA had other problems: only one or two (at the most) NSA people can speak
an Afghan language. And there were lots of other structural problems at
NSA. To understand this, understand that until ten years ago, NSA had
essentially a single mission: track the Soviets. NSA knew about Russian
missiles and submarines. They looked for the missiles, and set up very
advanced equipment that could provide early warning if a Soviet missile
were launched. To illustrate this capability, recall that a few months ago
an Israeli plane was shot down on its way from Israel to Russia. The US
immediately announced that a missile had shot down the plane. The guys who
did the deed denied it initially, but soon it came out that the US was
right. These are your NSA tax dollars at work. That's what we do, but
that's the wrong thing if you are worried about terrorists. Ten years after
the end of the cold war, the NSA still has the wrong technology in the
wrong places.

Technology has shifted under NSA's feet. For example, we could intercept
Russian communications. They used HF, and we had huge antennae that could
catch the stuff as it bounced around the world We had antennas, some called
Elephant Cages, that were a half mile wide, to intercept Russian HF
signals. Unfortunately, no one but the Russians used this.

Another technology used by potential adversaries was satellite. The use of
satellites for phone conversations declined dramatically in the last ten
years as other technologies (cable, fiber) replace satellite which had too
much delay (40,000 miles up and back) and was too expensive. That was too
bad for NSA because satellites are easy to eavesdrop on, fiber is tough.
Actually, NSA can tap fiber (no mean achievement) but the fiber is
underground or under the ocean, making it difficult to get to. Too bad for
NSA.

After the cold war, NSA's budget was cut by a third and targets increased.
There were targets in Africa, in the Balkans, in North Korea. NSA continued
to miss opportunities: NSA completely missed the atomic tests in India. NSA
completely missed the bombing of the Cole. In both cases the US was
surprised.. The bombing of the African embassies was missed. Once you know
the track record, it is no surprise that NSA completely missed Sept. 11.
It's what you'd expect.

Language skills continue as a problem. The US was involved in Haiti, the
NSA had one Creole speaker.

The other "intelligence" agency that might have helped with Sept 11 is the
Central Intelligence Agency (CIA). CIA missed Sept 11 completely too. This
not much of a surprise. CIA itself does not collect much information,
instead CIA specializes in analysis. What intelligence they do gather is
done in a peculiar way. The CIA has "case officers." They are assigned to
embassies around the world, typically as "cultural attaches." Their job is
to enlist spies from the area. They pay the spies to report back to them
periodically and tell them what's going on. This is called "human
intelligence" (humint) in contrast to the material that the NSA gathers.
Unfortunately, humint is very unreliable. You'll read that the "CIA needs
more case officers." For example, this point is made in a recent book on
the CIA by Robert Baer ("See No Evil: The True Story of a Ground Soldier in
the CIA's War on Terrorism"). Bamford disagrees with this message, and in
fact has recently published a review of the Baer book where he pans it.
Bamford gives an example of how crummy humint is: Recently the TV show 60
Minutes had found a guy who knew all about something [can't remember, maybe
about how the terrorists operate]. Before putting him on the air, 60
Minutes wanted to confirm that this source was legit, so they retained
Robert Baer to check him out (Baer had left the CIA). Baer certified him as
a good source. Only later did we learn that everything was made up?the
source just wanted his 15 minutes of fame. As we said, human sources are no
good, and Baer is no better than anyone at detecting the good ones.

A major justification for the CIAs modus operandi is that they can't get
their own people into various organizations. "They're all clan based, you
have to have been born there?., " the CIA argues. Let me ask one question:
how did a Marin county high school student get inside El Qaeda in less than
two years, learning major pieces of intelligence, meeting with OBL, etc.?
CIA couldn't do that?

Questions followed. Q: What about the Internet? A: That's another
technology they missed. OBL used email. OBL did not use encryption of any
sort on any communication. The best breakthrough in the whole intelligence
gathering surrounding Sept 11 was by the New York Times, who spent $1100
for a computer owned by one of the El Qaeda guys. The disk was encrypted,
but by a cheap encryption that the NYT broke easily, to find lots of info
about Al Qaeda plans. Another major failure of the CIA and NSA.

Q: Will NSA try to limit encryption? A: Yes, they'll try to place new
limits on encryption. And Clipper and key escrow will make a comeback. And
lots of other nonsense.

Q: Can we stop surprise attacks? A: No. We cannot avoid these kind of
attacks. We have to somehow explain to people that this is just one of the
hazards of life, like 50,000 Americans dying of colon cancer, or 50,000
Americans dying in car accidents every year. The government cannot bring
itself to say the truth, that terrorism is just one of the risks of life.

Q: What's your relationship with NSA? A: On the day the second book was
published, NSA held a book signing at NSA HQ. I teach a class at NSA. The
Defense Intelligence Agency used my first book as a textbook.

Q: What about the NSC. A: The National Security Council mostly has nothing
to do with NSA. Technically the NSA reports to the head of the NSC, but
besides some basic rules of engagement, there's no link. The difference
between them is remarkable: we've all heard of Condaleeza Rice, but who's
heard of the head of NSA, Gen. Mike Hayden?

Q: What about misinformation? A: It's a big problem. The FBI spy Robert
Hanssen worked closely with the NSA. Everything he knew about NSA's
progress or lack thereof was probably provided to the Russians. Also, the
Russians were provided with the names of all the CIA sources in Russia.
NET: the Russians knew everything we knew. Thus, we have to assume that
everything we got from the Russians or our spies was actually
misinformation. Or not. A "wilderness of mirrors."

Q: How does NSA work? A: Heavy use of polygraphs. Mandatory exams every
five years, plus random use of polygraphs, for every employee. NSA has more
PhDs in mathematics than any other organization in the western world. NSA
has a mental health unit for those who can't deal with the secrecy and
complexities of codes.

Q: Aren't most rules on government secrecy just ways to protect those in
power from looking like fools? A: Yes, pretty much. Best solution to this
is a diligent journalistic force (a free press) but today's press is
actually getting worse. Before Sept. 11 all the coverage was on Gary Condit
and on shark attacks, in spite of the fact that there are fewer shark
attacks every year. Sells papers.

Q: What should we do? A: Put national privacy at the same level as national
security. Support privacy groups.



February 11, 2002
------------------------------------------------------------------------

LRC needs your support. Please donate.

 
Back to LewRockwell.com Home Page

-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ggr at qualcomm.com  Sun Feb 17 19:38:26 2002
From: ggr at qualcomm.com (Greg Rose)
Date: Mon, 18 Feb 2002 11:38:26 +1100
Subject: theory: unconditional security
In-Reply-To: <E16cD6k-00005i-00@bowl.fysh.org>
Message-ID: <4.3.1.2.20020218113412.01d42910@127.0.0.1>

At 10:15 PM 2/16/2002 +0000, Zefram wrote:
>I've not been able to find any paper that describes the use of this
>algorithm to give unconditional secrecy and integrity at once.
>Nor have I found any paper describing doing this (as MAC or as
>secrecy-plus-integrity) in GF(2^n), which makes it convenient to operate
>on bit strings.  This seems so stunningly useful that I'm surprised it's
>not mentioned in AC.

Like One-Time Pads, it seems stunningly useful only until you consider the 
practicalities. You still need key material as long as (in fact, twice as 
long as) the message, and you still cannot ever reuse the key material.

>Can anyone point me at references that I'm missing?

The sci.crypt FAQ has some material about why OTPs are useless in practice, 
and might have some references.

Greg.

Greg Rose                                       INTERNET: ggr at qualcomm.com
Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,                http://people.qualcomm.com/ggr/
Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From cme at acm.org  Tue Feb 19 12:18:41 2002
From: cme at acm.org (Carl Ellison)
Date: Tue, 19 Feb 2002 09:18:41 -0800
Subject: theory: unconditional security
In-Reply-To: <4.3.1.2.20020218113412.01d42910@127.0.0.1>
References: <E16cD6k-00005i-00@bowl.fysh.org>
Message-ID: <3.0.5.32.20020219091841.01ce46d0@localhost>

At 11:38 AM 2/18/2002 +1100, Greg Rose wrote:
>At 10:15 PM 2/16/2002 +0000, Zefram wrote:
>>I've not been able to find any paper that describes the use of this
>>algorithm to give unconditional secrecy and integrity at once.
>>Nor have I found any paper describing doing this (as MAC or as
>>secrecy-plus-integrity) in GF(2^n), which makes it convenient to
>>operate on bit strings.  This seems so stunningly useful that I'm
>>surprised it's not mentioned in AC.
>
>Like One-Time Pads, it seems stunningly useful only until you
>consider the  practicalities. You still need key material as long as
>(in fact, twice as  long as) the message, and you still cannot ever
>reuse the key material.  
>
>>Can anyone point me at references that I'm missing?
>
>The sci.crypt FAQ has some material about why OTPs are useless in
>practice,  and might have some references.

Greg,

	OTPs were useless once.  Modern tapes can hold quite a few bits.  So
can a DVD-RAM disk, at 9.4GB.  You can secure quite a few messages
with bits from one disk.

Zefram,

	I suspect you find little written about OTP work because people have
always assumed the keys were impractical to distribute, store and
use.

 - Carl



+------------------------------------------------------------------+
|Carl M. Ellison         cme at acm.org     http://world.std.com/~cme |
|    PGP: 08FF BA05 599B 49D2  23C6 6FFD 36BA D342                 |
+--Officer, officer, arrest that man. He's whistling a dirty song.-+

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Tue Feb 19 13:19:54 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 19 Feb 2002 13:19:54 -0500
Subject: [Mojonation-devel] you are invited to mnet-devel
Message-ID: <p05100359b89847c36d2f@[10.0.1.2]>


--- begin forwarded text


Status:  U
To: mojonation-devel at lists.sourceforge.NET
From: Zooko <zooko at zooko.com>
Reply-to: Zooko <zooko at zooko.com>
Subject: [Mojonation-devel] you are invited to mnet-devel
Sender: mojonation-devel-admin at lists.sourceforge.net
List-Help: <mailto:mojonation-devel-request at lists.sourceforge.net?subject=help>
List-Post: <mailto:mojonation-devel at lists.sourceforge.net>
List-Subscribe:
<https://lists.sourceforge.net/lists/listinfo/mojonation-devel>,
	<mailto:mojonation-devel-request at lists.sourceforge.net?subject=subscribe>
List-Id: For developers hacking Mojo Nation code
<mojonation-devel.lists.sourceforge.net>
List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=mojonation-devel>
Date: Tue, 19 Feb 2002 10:00:56 -0800


Folks:

The mnet-devel list is picking up steam.  The archives are still small enough
that you can read them in their entirety in order to get on the same page
as everyone else.  See these web sites:

http://mnet.sf.net
http://sf.net/projects/mnet

See you there!

Regards,

Zooko


_______________________________________________
Mojonation-devel mailing list
Mojonation-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mojonation-devel

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Tue Feb 19 14:16:36 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 19 Feb 2002 14:16:36 -0500
Subject: theoretical results in watermarking
Message-ID: <p05100360b898550d8c76@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Tue, 19 Feb 2002 14:06:58 -0500
From: Richard Lethin <lethin at reservoir.com>
Organization: Reservoir Labs, Inc.
To: dcsb at reservoir.com
Subject: theoretical results in watermarking
Sender: bounce-dcsb at reservoir.com
Reply-To: Richard Lethin <lethin at reservoir.com>

YALE UNIVERSITY
DEPARTMENT OF ELECTRICAL ENGINEERING SEMINAR
Dr. Aaron S. Cohen
Research Laboratory for Electronics
Massachusetts Institute of Technology
will give a talk on
Communication with Side Information:
Watermarking and Writing on Dirty Paper
Wednesday, February 27
at
11:00 am
in
Room 500, Watson
Abstract
We consider two communication scenarios in which a transmitter must make
the input to a noisy
channel similar to some exogenous side information sequence. The first
such scenario is watermark-ing
for copyright protection. In watermarking, an original data sequence
(the side information) is
modified slightly in order to embed some extra information (e.g., the ID
number of the owner of
the data). The embedded information must be recoverable even if an
attacker has further modified
the data in order to make an illegal copy. Watermarking has become
increasingly important due to
the ease with which data can now be reproduced and transmitted around
the world. In this talk,
we answer some fundamental questions about watermarking system
performance. We first show
how much information a watermarking system can embed and how to design
good watermarking
systems. We also investigate whether it is better to have noisier data.
We finally compare the
optimal attack with lossy compression.
In the second scenario, the communication system has to be robust
against independent additive
noise instead of an attacker as in watermarking. Such a model is useful
when digitally enhancing
analog systems or when designing broadcast codes. Costa considered the
case where both the
side information and the additive noise are Gaussian, and dubbed it
?writing on dirty paper?.
Costa?s surprising result is that the maximum rate of information that
can be transmitted does not
depend on the variance of the side information. We extend Costa?s result
by considering general
distributions and showing that the maximum rate does not depend on the
statistics of the side
information if and only if (under certain conditions) the additive noise
is Gaussian. That is, the
side information need not be Gaussian but the additive noise must be
Gaussian in order for Costa?s
result to hold.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From JDCheesman at yahoo.es  Wed Feb 20 09:54:45 2002
From: JDCheesman at yahoo.es (Jim Cheesman)
Date: Wed, 20 Feb 2002 15:54:45 +0100
Subject: New Scientist: Peekabooty aims to banish internet censorship 
Message-ID: <4.3.1.2.20020220155414.042a8db8@lucas>



http://www.newscientist.com/news/news.jsp?id=ns99991948


Peekabooty aims to banish internet censorship
14:31 19 February 02
A long-awaited computer program that can circumvent government censorship 
of the internet has debuted at a computer conference in the US.The program 
- Peekabooty - promises to give people in countries such as China and Saudi 
Arabia safe access to the whole of the internet. In these countries, 
internet access is controlled by government-operated ISPs, which blacklist 
certain web sites. This may include news sites that are deemed 
unsympathetic to government policy.Peekabooty relies on users inside and 
outside a government-imposed "firewall" downloading software. Restricted 
content can then be delivered using volunteer "nodes" outside the 
restricted zone communicating with users within. The content is disguised 
as encrypted browser traffic, which is normally used to transmit credit 
card information or sensitive information such as passwords.
Hidden identity Peekabooty uses a complicated communications system to 
allow users to share information while revealing little about their 
identity. When a node receives a request for a web page it randomly decides 
whether to pass this on or access the page itself. It also only knows the 
address of its nearest partner. This makes it difficult to determine who 
requested what information and is designed to protect users from anyone 
trying to infiltrate the system from inside."Many people live under fear of 
repression," says Malcom Hutty of the UK's Campaign Against Censorship of 
the Internet in Britain. "Ultimately these things will work, because people 
want and need them."In the past, some internet sites could be used to beat 
internet censorship. These sites, such as SafeWeb and Anonymizer, acted as 
go-betweens, delivering censored content indirectly. But government censors 
became wise to this, and blocked access to these sites. Because content 
viewed using Peekabooty is disguised, government agencies should not be 
alerted to uncensored internet use. SafeWeb launched another program 
designed to route content through volunteer computers called Triangle Boy 
in 2001. But this does not maintain the anonymity of users.Peekabooty was 
demonstrated at the CodeCon 2002 conference, in California.
Will Knight

--

                           *   Jim Cheesman   *
             Trabajo: 
jchees at msl.es - (34)(91) 724 9200 x 2360
            It was all so 
different before everything changed.



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From JDCheesman at yahoo.es  Wed Feb 20 09:59:44 2002
From: JDCheesman at yahoo.es (Jim Cheesman)
Date: Wed, 20 Feb 2002 15:59:44 +0100
Subject: New Scientist: UK bill would "infringe scientists' freedom" 
Message-ID: <4.3.1.2.20020220155802.0428a120@lucas>

http://www.newscientist.com/news/news.jsp?id=ns99991944



UK bill would "infringe scientists' freedom"
14:30 18 February 02
...
For decades, controls have existed on the transfer of physical goods on the 
"dual-use" list - a list, recognised by the international community, of 
technologies that could have both civilian and military uses.
...
"The problem of the dual list is that it contains anything that the MOD 
thinks is high-tech," explains Anderson. This can include anything from 
semiconductor testing equipment and hard composites to certain types of 
catalyst, he says. It would also include types of software that many 
researchers have posted on their websites, such as cryptoanalytic or 
code-breaking programmes. Such postings could become illegal overnight.
...




--

                           *   Jim Cheesman   *
             Trabajo: 
jchees at msl.es - (34)(91) 724 9200 x 2360
            It was all so 
different before everything changed.



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ben at algroup.co.uk  Wed Feb 20 12:04:01 2002
From: ben at algroup.co.uk (Ben Laurie)
Date: Wed, 20 Feb 2002 17:04:01 +0000
Subject: "Cloak", or Cloaca? :-)
References: <p05100374b898d49c84ae@[10.0.1.2]>
	 <3C738262.542B538D@algroup.co.uk> <p0510039ab8997eac7993@[10.0.1.2]>
Message-ID: <3C73D701.92E23FB2@algroup.co.uk>

"R. A. Hettinga" wrote:
> 
> At 11:02 AM +0000 on 2/20/02, Ben Laurie wrote:
> 
> > Hmm. Keyring. Strip. Free. Been around for ages.
> 
> Sorry, a little too terse here. No idea what you're talking about...
> 
> In the meantime, I'm talking about Chaum's requirement, as stated at FC98
> and elsewhere, for a small, portable, secure device, with its own biometric
> or shared secret capability, requiring on-board I/O, to do things like
> (blind :-)) signatures with, store keys on, and so on.
> 
> So, this "Cloak" stuff seems to point that way, though, from what I
> remember hearing here and elsewhere, the Palm OS is too insecure even if
> you're running some encryption on it to be much good for Chaum's purposes...

Keyring and Strip are both programs that provide secure DBs on Palms.
Keyring, at least, is free and open source.

However, since Palms have no MMU, there's no security against hostile
other apps, which makes them pretty useless devices for this kind of
purpose.

The right answer, IMO, is EROS on an MMUed handheld device (not sure
about the biometric aspect - as I've stated at tedious length before, I
like my appendages and don't want to give people incentive to steal
them), such as that thing that runs Linux whose name temporarily escapes
me, or the new Sharp gadget. Or a Jornada if they ever make one small
enough.

We have the technology. All we need is someone to finance it.

Cheers,

Ben.

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

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Wed Feb 20 10:44:25 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 20 Feb 2002 10:44:25 -0500
Subject: [ISN] Tinfoil Hat Linux
Message-ID: <p05100390b89974cf281f@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Wed, 20 Feb 2002 02:16:14 -0600 (CST)
From: InfoSec News <isn at c4i.org>
To: isn at attrition.org
Subject: [ISN] Tinfoil Hat Linux
Sender: owner-isn at attrition.org
Reply-To: InfoSec News <isn at c4i.org>

http://tinfoilhat.cultists.net/

What is Tinfoil Hat Linux?

It started as a secure, single floppy, bootable Linux distribution for
storing PGP keys and then encrypting, signing and wiping files. At
some point it became an exercise in over-engineering.

Tinfoil hat is useful if:

* You're using a computer that could have a keystroke logger
  installed. http://www.keyghost.com is an example of a tiny &
  cheap hardware logger.

* You need to use your personal GPG keys at work, school or a web
  hosting facility where you don't trust or own the equipment.

* If you maintain a PGP Certificate Authority or signing key and have
  to have a safe place to use the CA key.

* If you simply don't want to risk putting a PGP key on a hard drive
  where someone else might have access to it.

* The Illuminati are watching your computer, and you need to use morse
  code to blink out your PGP messages on the numlock key.

[...]



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo at attrition.org with 'unsubscribe isn' in the BODY
of the mail.

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Wed Feb 20 21:43:37 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 20 Feb 2002 21:43:37 -0500
Subject: Censor-buster Peek-A-Booty goes public
Message-ID: <p051003bdb89a0f15dd5b@[10.0.1.2]>

http://www.theregister.co.uk/content/6/24099.html


  19 February 2002
  Updated: 10:00 GMT

Censor-buster Peek-A-Booty goes public
By Andrew Orlowski in San Francisco
Posted: 18/02/2002 at 08:36 GMT

Peek-A-Booty, cDc's much vaunted anonymity app, is vaporware no more - it
went public at the landmark CodeCon conference in San Francisco's DNA
Lounge on Sunday.

Peek-A-Booty is designed to let surfers access sites blocked by government
restrictions, and is essentially, a distributed proxy network. It uses a
peer-to-peer model, masking the identity of each node. So the user can
route around censorship that blocks citizens' access to specific IP
addresses, because the censor doesn't know they're going there. If you're a
Peek-A-Booty node, you might be doing it on their behalf. So the software
isn't itself a browser, but simply requires the user to use localhost in
the proxy field of their preferred browser.

Working out the general architecture was the easy bit. The tricky bit,
explained cDc developers Paul Baranowski and Joey deVilla (and relax,
they're happy to use their own names now), was anticipating and thwarting a
wide variety of the attack measures, from outside or inside the
Peek-A-Booty network itself. The design process took six months, beginning
in July 2000, but coding only started in earnest six months ago, after a
hiatus.

Peek-A-Booty nodes send out standard SSL, so the censorware can't
distinguish the request from any other secure electronic transaction: the
authors describe this as a form of steganography. But a rogue node inside
such a network could harvest the addresses of all the other nodes, so
Peek-A-Booty deploys a "virtual circuit", borrowing ideas from the Crowds
anonymous web browser.

"Most P2P systems really want their nodes to be found, our problem is that
you want to be found, but you really don't want to be found," said
Baronowski. So Peek-A-Booty uses random forwarding based on probability -
no one knows where the connection originated except the originator - and
eschews time to live packets. For security, there's no attempt at initial
discovery - you'll get sent details of a node by word of mouth, or from
some other secure source. Baranowski and deVilla expect that citizens
groups (NGOs) will become trusted servers. But as a one-time operation, you
can use Peek-A-Booty to download Peek-A-Booty.

The demo - of version 0.75 running on Windows XP- showed off the web-based
configuration management tool and the centerpiece, the Peekabear screen
saver. Which is very cute. (We've been promised screenshots and will add
them to this story as soon as they arrive).

Joey told us that the code was pretty standard Unix code (on the wxWindows
[and not Cygnus Windows, as earlier reported] environment), so a Linux and
even a Mac OS X port should be trivial. But Windows is on most desktops,
and for Peek-A-Booty to work effectively - like SETI - it needs
participating nodes, so that's where the numbers are.

It's a single threaded architecture right now, and grabs one link at time,
but the authors say it runs pretty well on a low-end PII, and the demo
proved this. "This will be fixed," they promise.

The pair are working on the code full time, so they need funding. There's a
basic website, [note the .org TLD - there's erm, booty of the regular kind
at the .com] but you'll need to mail the authors to get access to CVS tree.

The pair got a tremendous ovation from third day CodeCon attendees, and if
it withstands attack, will be a boost for human rights. Bravo. ?


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From amir at beesites.co.il  Thu Feb 21 04:28:14 2002
From: amir at beesites.co.il (Amir Herzberg)
Date: Thu, 21 Feb 2002 11:28:14 +0200
Subject: theory: unconditional security
In-Reply-To: <3.0.5.32.20020219091841.01ce46d0@localhost>
Message-ID: <000401c1baba$17f37880$323cfea9@newgenpay>

> 	I suspect you find little written about OTP work because people
have
> always assumed the keys were impractical to distribute, store and
> use.

Another concern with OTP and other unconditionally-secure schemes is
that they usually require limited number of applications of the key
(usually, use once). This introduces a substantial synchronization /
reliability / security problem for many applications. 

Notice that unconditionally secure authentication and signatures are in
fact used in scenarios where the limited use can be easily assured, such
as in online/offline signatures, used e.g. for micropayments and for
multicast encryption. In these cases, a `regular` offline signature
(e.g. RSA) is used to sign in advance (offline) the public key of the
one-time signature scheme. The one-time signature is applied when
processing online the message to be signed (with very little time). Of
course, the reason one-time signatures are used for these applications
is because they are faster, not because they are unconditionally secure.


Regards, Amir Herzberg
See http://amir.beesites.co.il/book.html  for lectures and
draft-chapters from book-in-progress, `secure communication and commerce
using cryptography`; feedback welcome!



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Thu Feb 21 10:52:33 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 21 Feb 2002 10:52:33 -0500
Subject: I will not comply!
Message-ID: <p051003cfb89ac8265876@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Wed, 20 Feb 2002 21:44:15 -0800
To: cypherpunks at einstein.ssz.com
From: Steve Schear <schear at lvcm.com>
Subject: I will not comply!
Approved: LISTMEMBER CPUNK
Sender: owner-cypherpunks at lne.com

I'm not sure how many of you made it to RSA, but their authentication
requirements rubbed me the wrong way for a conference originally dedicated
to both privacy and security.  From the looks of things its gone beyond big
"S" and little "p" to all "S" and no "p".

To test their resolve and have a bit of fun while at it I decided to show
up wearing Groucho glasses.  At first the processors greeted me with a
nervous giggle, but when I insisted I be photographed with the glasses on
the said I had to appear as I do on my driver's license.  So, I removed it
from my wallet and 'lo I was wearing Groucho glasses on my DL as well
(amazing what a photo-realistic printer and adhesive paper can do).  At
this point they knew they either had to call security or let me enter in
disguise.  They decided the latter and I entered mustachioed.  They asked
that I continue to wear the glasses after entering.

When I approached the door monitors they challenged me and my
credentials.  After inspecting the picture ID and verifying its likeness
they stepped aside.  A few of you may have seen me on the show floor so
attired.  My Groucho glasses were a hoot. I brought lots of smiles to
people's faces. I think I had the best time ever at a conference.

If you'd like a .jpg of my ID card let me know.

steve

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Thu Feb 21 10:54:23 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 21 Feb 2002 10:54:23 -0500
Subject: Smart Card Cracker at RSA tradeshow - Cool!
Message-ID: <p051003d1b89ac8a676ac@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Thu, 21 Feb 2002 00:46:08 -0800
To: cypherpunks at lne.com
From: Bill Stewart <bill.stewart at pobox.com>
Subject: Smart Card Cracker at RSA tradeshow - Cool!
Sender: owner-cypherpunks at lne.com

Most of the exhibits at the RSA show looked like such things usually do.
But one exhibit was really cool - Datacard Group, near the back around the
middle.
If you're there, you absolutely have to see these guys.

They were cracking smart cards using Differential Power Analysis and
Differential Fault Analysis - they have a stack of equipment with
an oscilloscope and some magic boxes and a PC display, and they were
showing "see these 16 vertical lines?  That's 16 rounds of DES.
Let's zoom in - this shape here is an S-box.  I'll start the cracking program,
and we'll have the key in a minute or two", and sure enough they did.
Triple-DES only takes about 3 times as long...

Finding the two primes from an RSA key took a similar amount of time -
it's not doing some magic factoring technique, it's watching a card
that has the two primes in it signing stuff.  I think that demo was
Differential Fault Analysis, where they hand the card some voltages
and frequencies that are much different than it's designed for,
and look at the different results they get depending on what parts they poke.

I've seen Paul Kocher's descriptions in the past about how this stuff
is possible - it's not the same impact as watching it done,
and seeing how amazingly fast it can be.
They're set up to do a couple formats of cards, including contactless
as well as the standard contact-based things.

Of course, there are also a few dozen smartcard vendors at the show,
talking about how their authentication systems will make
health care and banking and biometric citizen-unit-tracking perfectly
secure :-)

  =================
One other pleasant product was @Stake's bootable linux business-card-CD,
with lots of network analysis tools on it - ethereal, snort, VNC, a few
dozen others.
All the things you'd expect from them, if you dare to put it in your
machine....
They said there really weren't any "remote system administration" tools
on the disk that they don't document being there :-)

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Thu Feb 21 10:55:09 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 21 Feb 2002 10:55:09 -0500
Subject: RSA Tradeshow Wants Photo ID to register, the bums
Message-ID: <p051003d2b89ac8d681db@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Thu, 21 Feb 2002 00:59:56 -0800
To: cypherpunks at lne.com
From: Bill Stewart <bill.stewart at pobox.com>
Subject: RSA Tradeshow Wants Photo ID to register, the bums
Sender: owner-cypherpunks at lne.com

I suppose it probably was splattered all over their registration materials,
but I certainly didn't notice.
The RSA trade show insists on a picture ID to register, even for exhibits.
Then they take a digital picture of you at registration and print it on
your badge,
so you're not able to switch off badges with other people;
they're mainly checking pictures to get into the paid sessions,
which doesn't bother me much (though it's pretty typical for companies who have
multiple people attending a show and also doing booth bunny duty to switch
off.)

But it's especially annoying when you've registered several dummy names
for the free exhibits since you didn't know which co-worker would be there.
I'll have to see about printing a fake ID at work this morning before
I head back there (or else go back in and see if our lame booth has any
spare exhibit badges.)

Joel Cypherpunk and Dr. Fred M'bogo, you're both pre-registered,
so remember to bring picture ID of some sort with you :-)

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Thu Feb 21 10:56:35 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 21 Feb 2002 10:56:35 -0500
Subject: Other things I saw at RSA trade show.
Message-ID: <p051003d3b89ac928952c@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Thu, 21 Feb 2002 01:53:46 -0800
To: cypherpunks at lne.com
From: Bill Stewart <bill.stewart at pobox.com>
Subject: Other things I saw at RSA trade show.
Sender: owner-cypherpunks at lne.com

Lots of VPN/firewall boxes.
Fewer PKI vendors than in the past, mostly now aligned with other products.
A variety of SSL accelerator hardware - the higher-end boxes
claim to have ~10K transactions/second now, with ~50-100K on their next rev.
Some are more general, some more SSL-customized.
At least one has two GigEthernet interfaces, and integrates the
SSL with the TCP/IP stack, so you don't have to run the traffic through
your CPU to decrypt, saving a lot of copying.  It feeds the output
to the private-side computer using a different TCP port for each
certificate you use.
One has been integrated with FreeS/WAN IPSEC as an RSA / 3DES processor.

One VPN-like box which uses SSL instead of IPSEC, from Neoteris.
The nice things that it does are to support access from any SSL-capable
browser
(doesn't have to be your own laptop, as long as you trust it enough),
and to support access to various file system types, so you can use NFS
or other file servers behind it as well as disk-based servers.
It also has a little installable shim program for telnet-over-SSL.

A few secure mail products, such as Zixmail (who also give away screwdrivers.)
Several email-firewall products, with virus checking and spam blocking.
Ironmail sounded like they did a good job.

A number of people with USB key-dongles.  Most are small-memory versions,
e.g. 16KB-32KB, which require a driver rather than emulating a disk drive,
so they're not susceptible to general-purpose viruses, though you could
probably wedge a custom virus onto one.

One company using Java I-Buttons.  Their name was something SSOthinglike -
they do a Single Sign-On application using the I-Button as a token,
and there are now several new mounting hardwares for the buttons.
Dallas Semiconductor just recently merged with Maxim Semiconductor
( www.maxim-ic.com and also www.ibutton.com )

Not much in the way of tchochkes; a few squishballs, pens, T-shirts.
CDROMs are the main giveaway other than brochures.
Be sure to get the one from @Stake.

A few companies were obviously hiring, though not many.

EFF booth has a clunky Secret Decoder Ring.
The NSA booth has some cardboard decoder wheels, and an Enigma.
There's at least one encrypting GSM phone.

Smaller show than in the past.
Looks like IBM's not sponsoring the big party Thursday at the art museum.

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Thu Feb 21 13:29:55 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 21 Feb 2002 13:29:55 -0500
Subject: Email Search: The latest weapon in anti-terror arsenal
Message-ID: <p051003efb89aecc6f37c@[10.0.1.2]>

 http://www.timesofindia.com/Articleshow.asp?art_id=1670765

The Times of India Online
Printed from origin.timesofindia.com > India
------------------------------------------------------------------------


The latest weapon in anti-terror arsenal
SIDDHARTH SRIVASTAVA
TIMES NEWS NETWORK [ THURSDAY, FEBRUARY 21, 2002  4:59:02 PM ]
EW DELHI: According to senior officials, tracking e-mails of arrested
terrorists has become a foolproof method of gaining hard evidence.

"There can be no fooling around with an e-mail IDs and passwords," says an
official of the Intelligence Bureau, "Once a terrorist is caught his e-mail
IDs can be cross-checked immediately. So, he better be telling the truth.
Phone records or other statements require a time lag before they can be
confirmed," he adds.

Of course, the fact that the modern generation terrorist is generally
educated and tech-savvy helps.

Officials say, whether it is Aftab Ansari or Omar Sheikh or for that
matter, even a Dawood Ibrahim or a Chhota Shakeel, the kind of information
that has been generated now would not have been possible without accessing
their e-mails.

Investigators are still grappling with more information about the attackers
on the Parliament, as they have not been able to break into their e-mails
as yet.

"Most of the current lot of criminals have become extremely chary of using
their phones given the past record of tapping by intelligence agencies.
However, they felt free exchanging critical information on the Internet,"
says the official.

It is through a series of e-mail exchanges between Ansari and Sheikh that
the involvement of the two in the WTC attack has been confirmed.
Interrogators of Ansari here got hold of several of his e-mail IDs,
farhanmalik at hotmail.com, aftabansari169 at hotmail.com to connect to the
series of e-mail exchanges between him and Sheikh.

The CBI and the IB used e-mail interception technology to track Ansari by
tracing his e-mails in January, first to servers in Dubai and then to
Islamabad. The local Internet service provider was roped in to determine
the exact location from which Ansari had sent an e-mail which turned out to
be Islamabad.

Even in the case of Sheikh, the police in Karachi, helped by a
cyber-tracking team from the FBI, traced the three men who had sent the
e-mails about Pearl's abduction to the media. The arrested men lead them on
to Sheikh. The authorities then picked up Sheikh's in-laws from Lahore,
exerting pressure on him to surrender.

Earlier, Intelligence agencies had cracked into the e-mail IDs of Dawood
Ibrahim and Chhota Shakeel to confirm their presence in Pakistan post
December 13.
? Bennett, Coleman and Co., Ltd. All rights reserved.
------------------------------------------------------------------------




-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From bear at sonic.net  Thu Feb 21 14:10:46 2002
From: bear at sonic.net (bear)
Date: Thu, 21 Feb 2002 11:10:46 -0800 (PST)
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
In-Reply-To: <C1256B57.0055C706.00@>
Message-ID: <Pine.LNX.4.40.0202211105161.4987-100000@newbolt.sonic.net>



On Tue, 5 Feb 2002, Eugene Leitl wrote:

>Things have been quiet on the "new algorithms" front for a few years.
>But at Crypto last August, Dan Bernstein announced a new design for a
>machine dedicated to NFS using asymptotically fast algorithms and
>optimising memory, CPU power and amount of parallelism to minimize
>asymptotic cost.  His conclusion, recently detailed in a paper, should
>be a bombshell, but apparently everyone is asleep:
>
>DB:
>>This reduction of total cost [...] means that a [approx 3d-digit]
>>factorization with the new machine has the same cost as a d-digit
>>factorization with previous machines.
>
>Knowledge is pretty fuzzy about its runtime and practicality, but it
>means that it may well be much easier than previously believed to
>break 1024 bits.  You may need, say, 3000 bits to be safe.


I really want to read this paper; if we don't get to see the
actual mathematics, claims like this look incredibly like
someone is spreading FUD. Is it available anywhere?

				Ray



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From pzakas at toucancapital.com  Thu Feb 21 15:15:15 2002
From: pzakas at toucancapital.com (Phillip H. Zakas)
Date: Thu, 21 Feb 2002 15:15:15 -0500
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
In-Reply-To: <Pine.LNX.4.40.0202211105161.4987-100000@newbolt.sonic.net>
Message-ID: <000901c1bb14$7ae17320$16c89c8d@PHZ>

> >On Tue, 5 Feb 2002, Eugene Leitl wrote:
> >Things have been quiet on the "new algorithms" front for a few years.
> >But at Crypto last August, Dan Bernstein announced a new design for a
> >machine dedicated to NFS using asymptotically fast algorithms and
> >optimising memory, CPU power and amount of parallelism to minimize
>
> Bear responds:
> I really want to read this paper; if we don't get to see the
> actual mathematics, claims like this look incredibly like
> someone is spreading FUD. Is it available anywhere?
> 
> 				Ray

The paper is located here: http://cr.yp.to/papers.html
I've not evaluated yet but I'm interested in hearing if he received his
grant to try it out.
Phillip


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From adam at zeroknowledge.com  Thu Feb 21 15:38:35 2002
From: adam at zeroknowledge.com (Adam Shostack)
Date: Thu, 21 Feb 2002 15:38:35 -0500
Subject: Privacy Enhancing Technologies 2002
Message-ID: <20020221203835.GB9138@zeroknowledge.com>



Privacy Enhancing Technologies 2002
April 14-15, 2002
San Francisco, CA

Call for Participation


Registration for Privacy Enhancing Technologies 2002 is now open.
Details and online registration can be found at http://www.pet2002.org/
along with the program and hotel information.

Privacy and anonymity are increasingly important in the online
world. Corporations and governments are starting to realize their power
to track users and their behavior, and restrict the ability to publish
or retrieve documents. Approaches to protecting individuals, groups,
and even companies and governments from such profiling and censorship
have included decentralization, encryption, and distributed trust.

Building on the success of the first anonymity and unobservability
workshop (LNCS 2009, held in Berkeley in July 2000), PET2002 addresses
the design and realization of such anonymity and anti-censorship services
for the Internet and other communication networks. The program consists
of peer reviewed papers, an invited talk, and a panel discussion on
policy. The proceedings will be published in the Springer-Verlag Lecture
Notes in Computer Science series.





Preliminary PET2002 program:

  David Chaum: Invited Talk

  "Privacy-enhancing technologies for the Internet, II: Five years later"
  Ian Goldberg

  "Detecting Web Bugs With Bugnosis: Privacy Advocacy Through Education"
  Adil Alsaid, David Martin

  "Private authentication"
  Martin Abadi

  "Towards an Information Theoretic Metric for Anonymity"
  Andrei Serjantov, George Danezis

  "Towards Measuring Anonymity"
  Claudia Diaz, Stefaan Seys, Joris Claessens, Bart Preneel

  "The Platform for Enterprise Privacy Practices -- Privacy-enabled
  Management of Customer Data"
  G{\"u}nter Karjoth, Matthias Schunter, Michael Waidner
 
  "Privacy Enhancing Profile Disclosure"
  Peter Dornbach, Zoltan Nemeth

  "Privacy Enhancing Service Architectures"
  Tero Alamaki, Margareta Bjorksten, Peter Dornbach, Casper Gripenberg,
  Norbert Gyorbiro, Gabor Marton, Zoltan Nemeth, Timo Skytta, Mikko
  Tarkiainen

  Policy Panel, moderated by John Borking

  "Dummy Traffic Against Long Term Intersection Attacks"
  Oliver Berthold, Heinrich Langos

  "Protecting Privacy during On-line Trust Negotiation"
  Kent E. Seamons, Marianne Winslett, Ting Yu, Lina Yu, Ryan Jarvis

  "Prototyping an Armored Data Vault: Rights Management on Big Brother's
  Computer"
  Alex Iliev, Sean Smith

  "Preventing Interval-based Inference by Random Data Perturbation"
  Yingjiu Li, Lingyu Wang, and Sushil Jajodia

  "Fingerprinting Websites Using Traffic Analysis"
  Andrew Hintz

  "A Passive Attack on the Privacy of Web Users Using Standard Log
  Information"
  Thomas Demuth

  "Covert Messaging Through TCP Timestamps"
  John Giffin, Rachel Greenstadt, Peter Litwack, Richard Tibbetts

  "Almost Optimal Private Information Retrieval"
  Dmitri Asonov, Johann-Christoph Freytag

  "Unobservable Surfing on the World Wide Web: Is Private Information
  Retrieval an alternative to the MIX based Approach?"
  Dogan Kesdogan, Mark Borning, Michael Schmeink


(please distribute widely)

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Thu Feb 21 15:41:30 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 21 Feb 2002 15:41:30 -0500
Subject: VRSN MITM
Message-ID: <p05100305b89b0bcd3d8a@[10.0.1.2]>

http://online.wsj.com/article_print/0,4287,SB1014167284826456880,00.html




February 20, 2002
E-COMMERCE
VeriSign's Blueprint Will Facilitate
Online Authentication Developments

By NICK WINGFIELD
Staff Reporter of THE WALL STREET JOURNAL


VeriSign Inc. announced a new plan to act as a neutral party between rival
factions in the market for online authentication services.

The plan involves a technical blueprint, introduced Tuesday by Mountain
View, Calif.-based VeriSign, that the company is pushing as a way to
simplify the creation of sophisticated Web applications that require
high-levels of security. A broad range of companies agreed to support
VeriSign's technologies and specifications in their software programming
tools and other products -- including two companies that have put forth
competing proposals for online authentication services, Microsoft Corp. and
Sun Microsystems Inc.

Microsoft and Sun have been working separately to set technical ground
rules that will allow users of personal computers and other devices to get
access to Internet resources by logging on just once, rather than having to
fumble with multiple passwords. Microsoft's Passport technology is already
in use on sites across the Internet. Sun last year founded, along with more
than two dozen companies, a consortium called the Liberty Alliance to
create an alternative set of authentication specifications for Web sites,
though the group hasn't produced a product for consumers to use. Some
Liberty representatives have signaled an eagerness to get Microsoft to join
the alliance, and Microsoft executives haven't ruled out that possibility.

VeriSign, meanwhile, says it sees an opportunity to help broker personal
information between competing online identity services by acting as a kind
of independent hub for the various plans. The company's technologies and
services will also make it easier for businesses to create applications
that need to verify someone's identity. For instance, a health-care
provider could make an application that verifies medical claims by checking
a database of doctors, all of whose identities have been verified by
VeriSign.

In addition to Microsoft and Sun, International Business Machines Corp.,
Oracle Corp., Hewlett-Packard Co., BEA Systems Inc. and others also agreed
to support the VeriSign framework in their products. "We'll be the
underpinnings across all of them," said Anil Pereira, a senior vice
president at VeriSign.

Write to Nick Wingfield at nick.wingfield at wsj.com1
URL for this article:
http://online.wsj.com/article/0,,SB1014167284826456880.djm,00.html
Hyperlinks in this Article:
(1) mailto:nick.wingfield at wsj.com

Updated February 20, 2002 3:15 p.m. EST

Copyright 2002 Dow Jones & Company, Inc. All Rights Reserved
Printing, distribution, and use of this material is governed by your
Subscription agreement and Copyright laws.
For information about subscribing go to http://www.wsj.com
-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at ibuc.com  Thu Feb 21 16:09:16 2002
From: rah at ibuc.com (R. A. Hettinga)
Date: Thu, 21 Feb 2002 16:09:16 -0500
Subject: [IBUC Friends] Geodesic Capital 2002: Call for Participants
Message-ID: <p05100307b89b120fb601@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Wed, 20 Feb 2002 15:17:58 -0500
To: Digital Bearer Settlement List <dbs at philodox.com>, dcsb at ai.mit.edu
From: "R. A. Hettinga" <rah at shipwright.com>
Subject: Geodesic Capital 2002: Call for Participants
Sender: <dbs at philodox.com>
List-Subscribe: <mailto:dbs-on at philodox.com>

We've been talking about this event for months (if not years, now),
and have asked you to save the dates, rescheduled it, well, twice.
But, finally, here's what you've been saving the date for...



                        CALL FOR PARTICIPANTS

              THE FIRST IBUC SYMPOSIUM ON GEODESIC CAPITAL:
        "GC02 -- Internet Bearer Finance in a Transparent World"

                          April 3-4, 2002
                 The Downtown Harvard Club of Boston
                     Boston, Massachusetts, USA


AN INVITATION

The Internet Bearer Underwriting Corporation invites its friends in
finance, cryptography, and in internet security, infrastructure, and
commerce to Boston for an informal two-day symposium to discuss
bearer finance on a ubiquitous geodesic .



WHAT IS GEODESIC CAPITAL?

"A Fine Kettle of Fish."

Ever since the bottom fell out of the internet finance and digital
goods markets in the Spring of 2000, and especially since the
terrorist events of the Fall of 2001, there has been a considerable
amount of discussion on the net and in the press about the economic
efficacy, if not the actual political wisdom, of using specific kinds
of putatively anonymous financial cryptography protocols to
instantaneously execute, clear, and settle financial and commercial
transactions on the internet.

And yet, the need for these transactions is greater than ever before:

 -- THE MARKET FOR DIGITAL GOODS AND SERVICES, which require
instantaneous cheap peer-to-peer transactions to survive as
stand-alone businesses, has been left in limbo, if not in absolute
disarray. There are increasingly ruinous fights over digital property
rights, which leave the producers and even distributors of internet
content in the position of not producing or distributing content at
all in a medium where content distribution is orders of magnitude
cheaper than in any other.

 -- In spite of commercial assurances to the contrary, THE VERY RIGHT
TO DECRYPT OR REVERSE ENGINEER ENCRYPTION OR SECURITY METHODS IS NOW
VERY MUCH IN DOUBT, with restraining orders and subpoenas flying like
chaff, and the odd theatrical arrest of conference participants for
publishing any software which does even the simplest crypt analysis
of an ostensibly trade-secret protocol.

 -- We are at the point of REQUIRING AN ACTUAL "FINANCIAL PANOPTICON"
BY THE COMING MARKET FOR INTERNET SERVICES, which, at the moment,
depends completely on on "is-a-person" identification of its users,
primarily because current financial transaction settlement technology
requires the identification and apprehension of people who lie about
a book-entry in a database somewhere instead of failing potentially
fraudulent transactions before they even execute.

 -- INTERNET INFRASTRUCTURE FIRMS like ISPs and co-location
facilities are getting over their dot-com bubble hangovers by merging
and filing bankruptcy, while, at the same time, their administrative
costs, caused primarily by the overhead of the billing and payment
process, and moreover, their marketing costs, caused at least
indirectly by the same, keep going up. An auction priced cash-settled
internet infrastructure market would go a long way to restructuring
these markets into something which would be, by definition,
profitable, efficient, and, more to the point, dynamically scalable
without the waste, fraud, and abuse of the current system.

 -- Most important, ANY REDUCTION IN SETTLEMENT RISK AND TRANSACTION
COST which these protocols could bring to the capital markets
themselves IS NOW AT A COMPLETE STANDSTILL, and at a time when costs
are being severely controlled, even to the point of threatening the
existence of several very good firms, and the increasing possibility
of regulatory scrutiny, including the forced divestiture of various
business units, raising financial firms' cost structures even more.

-- The paradox is, CONFLICT OF INTEREST ARISES DIRECTLY BY SHARED
OWNERSHIP OF CONFLICTING BUSINESS UNITS, such as professional
services and auditing, or even underwriting, securities analysis, and
market-making. In order to have smaller firms, microeconomics tells
us that we *must* lower transaction costs. If transactions are less
transparent but considerably cheaper, then firms get smaller, become
more specialized, and the need for transaction transparency is
reduced. Reduced, in fact, to the point where TRANSPARENCY WOULD BE,
like privacy now is, completely ORTHOGONAL TO TRANSACTION COST.


Into this chaos steps a class of deliberately *anonymous* transaction
protocols, originally designed by decidedly left/liberal academics to
prevent corporate control of personal data, and championed on the
internet by anarchist/libertarians ideologues as a way to prevent
state control of the same information. Yet, the actual *financial*
use of these protocols is now being advocated by researchers in
financial operations as a way to substantially lower risk-adjusted
transaction costs below those currently available with book-entry
transactions, probably even greater a reduction than that caused by
book-entry transactions themselves.


Book-entry vs. Bearer Transactions

Book-entry transactions originated first between individuals and
firms on telegraphic networks as a way to reduce the physical
handling of physical bearer certificates and execution orders, and is
now done on proprietary networks like SWIFT, FedWire, the various ATM
and EFT networks, NACHA and so on, and cleared through various
member-only clearinghouses, securities depositories, and financial
institutions around the world. Checks, credit cards, bank-wires,
virtually all stock, bond, derivative, and institutional currency
transactions are book-entry transactions.  In other words, all
finance but the bills in your wallet and change in your pockets is
book-entry finance.

And yet, the most popular *internet* equivalent to using book-entry
methods for settlement and clearing (the exchange of consumer debt
for cash, for instance) so far have involved tunneling credit-card
*execution* requests over the net using TLS/SSL, as is done with the
vast majority internet commerce.

Though, on a considerably smaller though growing scale, tunneled
SSL/TLS is also being used for the actual clearing and settlement of
peer-to-peer book-entry transactions using a single
database/clearinghouse, like PayPal does for national currencies, or,
even, for gold-denominated transactions, like GoldMoney and E-Gold
do.


Internet Bearer Finance

For several years now, many researchers in financial operations,
cryptography, security and internet architecture have come to believe
that that Moore's Law, coupled with internet financial cryptography,
creates something at the same vastly simpler, but capable of
significantly more complex and efficient results: an economy based on
increasingly smaller, cheaper and highly distributed *bearer*
transactions; executed, cleared and settled by increasingly smaller,
cheaper, and highly distributed financial intermediaries.

Instead of a hierarchical system of interlocking book-entries,
requiring law, and force, to clear and settle without fraud, these
researchers see a *geodesic* system of single-use bearer
certificates, cash for debt, equity, and derivative instruments, from
statistically-tested streaming millidollars to single-certificate
gigadollar currency derivatives, all of which would execute, clear
and settle instantaneously, but only if cryptographic and internet
protocols are adhered to by the buyer, seller, and underwriter of a
given bearer certificate.

Not only is the actual transaction risk of such internet bearer
protocols probably reduced to near zero, but, paradoxically, the
resulting the lack of audit trails -- the lack of existence of the
book-entries themselves -- would reduce the mechanical costs of
transactions using these protocols on the internet by more than
book-entry settlement did in replacing physical delivery of paper
bearer certificates starting a century ago.

And so, use of these protocols to underwrite financial instruments,
on what Peter Huber observed is an increasingly geodesic global
communications architecture itself caused by increasingly falling
switching prices, observed at least indirectly by Gordon Moore, is
what IBUC has come to call "Geodesic Capital", and the research in
and development of markets which use Geodesic Capital is the theme of
this Symposium.


THE SYMPOSIUM

Participants are requested to send their suggestions for content,
proposals to talk, etc., to Robert Hettinga of the Internet Bearer
Underwriting Corporation at <mailto://rah at ibuc.com>. What follows is
a brief outline of the Symposium's agenda as it now stands.


CURRENT AGENDA

 THE FIRST IBUC SYMPOSIUM ON GEODESIC CAPITAL:
"Internet Bearer Finance in a Transparent World"


Wednesday Morning, April 3, 2002

08:00 Breakfast/Registration

09:00 Welcome and Keynote
Welcome, Introduction: Robert Hettinga, IBUC
Keynote: (TBA)

10:00 Break (Coffee, Tea, snacks)

10:15 Morning Session: The Origins of Geodesic Finance

History of networks, finance, cryptography. The invention of internet
bearer transaction settlement. The promise -- and consequences -- of
bearer settled capital markets. Experience so far in researching and
developing these markets.

12:15 Lunch

13:15 Early Afternoon Session: First Steps -- Simple Bearer Markets

Depository and Custodial Receipts. Simple debt instruments. Simple
Cash.

15:15 Break (Coffee, Tea, snacks)

15:30 Late Afternoon Session: Internet Finance

Markets for internet content and services, bandwidth, etc. Recursive
auctions for content and software. Streaming Cash. Machine to Machine
markets.

17:30 Reception, Cocktails and finger-food

19:00 See You in the Morning...

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

Thursday Morning, April 4, 2002

08:00 Breakfast

08:30 Early Morning Session: Advanced Capital Markets

Equity. Derivatives. Price Discovery. Exchange Protocols.
Intercustodial Settlement Networks. Managing bearer market trading
staff. Paying Stamp Duty and  other taxes.

10:00 Break (Coffee, Tea, snacks)

10:15 Late Morning Session: Advanced Capital Markets, cont'd

12:15 Lunch

13:15 Early Afternoon Session: Regulation and Governance

Regulatory Issues. Policy implications. Internet-Based Market
Governance.

15:15 Break (Coffee, Tea, snacks)

15:30 Late Afternoon Session: Getting There From Here

Market Analyses. Development Planning. Market Entry Scenarios.
Meeting the regulatory burden. The market for capital. What's next?

17:30 Conference Close, Reception, Cocktails and finger-food



ADMINISTRIVIA

What to Bring:

Your laptop: We've managed to have at least bonded dial-up access to
the net in the past. It's possible we'll do better than that this
time.

Your talking points: We're leaving plenty of air time for people to
present their ideas and opinions. Contact Robert Hettinga
<rah at ibuc.com>, about your proposed presentations and any collateral
material you would be bringing. In addition, the chair will probably
recruit some attendees to present some of a session's content and
moderate the discussion.

Your ideas, and, most important, your enthusiasm and energy: After
the events of  the last year, we have a lot of work to do.
Fortunately, like the apocryphal Chinese ideograph, disaster and
opportunity are very closely related, and, like the troubles we've
had recently, the opportunities we now face are quite considerable.

Dress Code

The dress code at the Harvard Club of Boston is Business Casual, but
the suit ratio approaches 100% these days in light of the dot-bomb...


REGISTRATION AND FEES

Fees

The Symposium includes Breakfast, breaks, lunch, and a reception in
the evening.

The Symposium fee is $875 if received by IBUC before March 1st, 2002.
Between March 1st and 15th, the fee is $1062.50. After March 15th,
the fee is $1250.

Payment

Payment should be in the form of a bank wire, or a corporate or
cashier's check payable to The Internet Bearer Underwriting
Corporation sent to:

IBUC
44 Farquhar Street
Boston, MA 02131

Contact Mr. Hettinga, <rah at ibuc.com>, for wire instructions.

Include the registrants' names and email addresses. Confirmation of
receipt will be sent by digitally signed E-Mail.


Discounts and Scholarships

Depending on circumstances, there may be discounts and complementary
admission for services rendered in kind, and for students and
academics, at the discretion of the Symposium Chair.

SPONSORSHIP OPPORTUNTIES

In addition, sponsorship opportunities are available, in particular
for a keynote speaker, or dinner on either evening. Sponsors would
receive two complementary symposium seats, and reserved table space
for promotional material. Email Mr. Hettinga for details.


SEE YOU IN BOSTON!

If you would like to help create world where the internet
dramatically reduces the cost of moving money, of the transfer of the
ownership of financial assets, digital goods, and internet services,
then Boston is where you should be on April 3rd and 4th, 2002.

We hope to see you there.

Cheers,
Robert A. Hettinga,
Chairman/CEO,
The Internet Bearer Underwriting Corporation




-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Fri Feb 22 09:11:44 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Fri, 22 Feb 2002 09:11:44 -0500
Subject: Terror talk stalks RSA Conference
Message-ID: <p0510032fb89c0022a567@[10.0.1.2]>


http://www.theregister.co.uk/content/55/24164.html

The Register

  21 February 2002
  Updated: 21:02 GMT
------------------------------------------------------------------------
Terror talk stalks RSA Conference
By Kevin Poulsen
Posted: 21/02/2002 at 21:02 GMT


The official theme of the eleventh annual RSA Conference evokes the
Elizabethan Era -- complete with costumed minstrels and acrobats wandering
the San Jose, Calf. convention center. Unofficially, the security event
opened Tuesday with a more serious theme, with U.S. cyber security czar
Richard Clarke warning about the potential for terrorist hack attacks, and
a panel of noted cryptographers fretting over lost liberties in the wake of
the real terrorist attacks of September 11.

In a keynote address kicking off the conference, Clarke repeated the
message that he's delivered around the country since his appointment as the
White House's Special Advisor for Cyber Security last fall, evoking
patriotic duty and September 11 to urge companies to make computer security
a top priority, and arguing that future terrorists may exploit glaring
weaknesses in U.S. computer systems.

"This industry runs the same risk that the aviation industry ran," Clarke
said. "For years, people in the aviation industry knew that there were
security vulnerabilities. They convinced each other and convinced
themselves that these vulnerabilities would never be used."

Citing a Forrester Research report that found companies spend on average
.0025 percent of their revenue on information security, Clarke chided, "If
you spend more money on coffee than IT security, you will be hacked. And
moreover, you deserve to be hacked."

Govnet redux
In contrast, Clarke said, the Bush administration has proposed increasing
federal cyber security funding by sixty-four percent to $4 billion -- eight
percent of the government's $50 billion IT budget.

Clarke also defended his proposal for the creation of a private network
exclusively for sensitive government computers. The administration received
167 comments on the proposal to create a "Govnet" that would be isolated
from the public Internet, Clarke said. Those proposals are being reviewed
by sixteen federal agencies.

The cyber security czar professed surprise at learning from the comments
that other segregated wide area networks already exist, within federal
agencies and private companies. "What we discovered is that the idea of
having a separate air-gapped network... is in fact an old idea," said
Clarke. "There are already such networks out there."

Some security experts had criticized the Govnet proposal, arguing that such
a network would itself be vulnerable to attack, and would represent a
government abandonment of the Internet. Clarke countered Tuesday that he
didn't expect Govnet to provide perfect security, but that it makes sense
to remove critical government functions from the public network. "I don't
know where it was ever written that everything has to be connected to
everything else," said Clarke.

Clarke's talk -- a mix of fiery rhetoric and pragmatic analysis -- was
generally well received, though observers disagreed with Clarke on some key
points.

"He seems to say that out of the goodness of our hearts we should spend
more and more and do the right thing, and I don't think that's going to
happen," said Bruce Schneier, CTO of Counterpane Internet Security. "If you
want to make them do the right thing, make it illegal to do the wrong
thing."

"I really believe terrorists are more interested in physical mayhem," said
former hacker Kevin Mitnick, also attending the conference. "A lot of
people don't take notice if the phone system goes down in Miami."

Cryptographer's Panel
The terrorism theme carried over into the Cryptographer's Panel -- an
annual tradition at the conference that brings together the world's most
well known cryptography experts. But the panel was less concerned with the
purported threat of cyber terrorism, than with the corporate and
governmental responses to physical attacks.

Adi Shamir, professor at the Weizmann Institute of Science, criticized the
hodgepodge of security measures that went into effect following September
11, including airport screeners that sometimes prohibited innocuous items
like fingernail clippers, while allowing materials that could be converted
into weapons. "I think that in computer security we know the importance of
multiple lines of defense," said Shamir. "They should use ethical computer
hackers in order to think of ways that airline security could be breached."

Privacy was an issue for MIT professor Ronald Rivest, who was particularly
concerned about plans to make widespread use of small, inexpensive
radio-frequency tags as security tools. "Everything you own might have one
of these tags on them," said Rivest. "I might be able to tell how much
money you're carrying just by putting out a radio probe."

The technology could backfire, said Rivest, with terrorists using the tags
as a proximity fuse for an explosive, so that a bomb would go off when a
particular person came within range. The cryptographer suggested that laws
may be needed to prevent companies or the government from tying such tags
to personally identifiable information.

Whitfield Diffie, another cryptography legend, worried about growing
restrictions on the free flow of information. "The more we impose controls
on ourselves, the more they can be taken over to support some else's
information control policies," said Diffie.

The cryptographer drew applause for condemning intrusive new surveillance
practices. "This kind of very un-American watching of people is something
we should watch very carefully."


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Fri Feb 22 10:45:31 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Fri, 22 Feb 2002 10:45:31 -0500
Subject: [ISN] Profitable privacy
Message-ID: <p05100338b89c180f446e@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Fri, 22 Feb 2002 02:53:51 -0600 (CST)
From: InfoSec News <isn at c4i.org>
To: isn at attrition.org
Subject: [ISN] Profitable privacy
Sender: owner-isn at attrition.org
Reply-To: InfoSec News <isn at c4i.org>

http://www.computerworld.com/storyba/0,4125,NAV47_STO68354,00.html

By PATRICK THIBODEAU
February 18, 2002

Privacy is an important part of Royal Bank Financial Group's customer
relationship management (CRM) system.  Employees explain Web cookies
to customers; the bank offers cell phones with special encryption
chips for wireless transactions; and it has a pilot program through
which it gives away firewalls and other security products to
customers. That's right, for free.  So where's the profit in that?

For Peter Cullen, chief privacy officer at Toronto-based Royal Bank,
there's profit in privacy. "It is one of the key drivers of a
customer's level of commitment and has a significant contribution to
overall demand," he says.

As more countries adopt stricter privacy laws, companies have to adapt
their CRM systems to comply. But Royal Bank clearly sees privacy as
more than a legal issue -- it's also a pathway to a customer's loyalty
and spending.

"We are very much in a relationship business," Cullen says, adding
that privacy "plays a measurable part in how customers decide [to]
purchase products and services from us. It brings us more share of the
customer's wallet."

Many companies are reluctant to offer customers more privacy choices,
such as opt-in features that require getting customer permission to
collect or transfer personal information. Businesses fear they'll lose
their ability to leverage customer data and share such information
with affiliates.

Dennis Behrman, an analyst at Meridien Research Inc. in Newton, Mass.,
sums up the prevailing attitude: "You won't lose customers if you
offer privacy options, but you may lose access to your ability to gain
information."

But before companies can ask how privacy fits into a CRM strategy,
they need systems that can handle privacy compliance. New domestic and
international laws are arriving rapidly. Australia, which enacted its
new privacy law in December, is a good example.

A section in Australia's law requires companies to destroy customer
data or make it anonymous once it's no longer needed. That includes
backup files, says Andrew Handelsmann, an attorney at Deacons, a law
firm in Sydney. Compliance will involve more than simple deletion to
ensure that files are really erased from drives, he says.

Complying with laws of this type, as well as integrating privacy into
a CRM strategy, requires changes in IT systems and management. "It's
keeping the system smaller, and it's more controlled," says Greta
Ostrovitz, IT director at Cadwalader, Wickersham & Taft, an
international law firm in New York. "We don't have these huge, huge
databases that just have a life of their own and no one knows what's
in it."

Tighter control is important to CRM strategies and legal compliance,
Ostrovitz says. For instance, when her firm wants to send online and
print mailings to clients in England, it must first get client
permission for the mailings, according to U.K. privacy regulations.
"In building a system, the key is maintaining an audit trail so you
know exactly when something gets entered, who entered it, when was
something mailed, what exactly got mailed," says Ostrovitz.

The Gramm-Leach-Bliley Financial Services Modernization Act, which
took effect in the U.S. July 1 (see story), was one of the reasons
Cleveland-based KeyBank revamped its massive customer databases.

KeyBank pulled about 50 million customer records held by various
business units and distilled them into a single database of 11 million
records.

"We wanted a customer-centric approach, where the customer just came
to us once -- at any entry point in the company -- and we could then
identify the rest of their relationships in the organization," says
Angela Maynard, chief privacy officer at the Fortune 500 bank.

In going through the 50 million customer records, KeyBank also
"cleaned" the data held by different business units to improve
accuracy. It did this in part by matching the data against 200 million
credit records maintained by Experian Inc. in Orange, Calif.

>From a CRM perspective, this single view of the database means that if
a customer asks to be excluded from certain forms of information
sharing, as allowed under the Gramm-Leach-Bliley law, this privacy
request can be consistently applied across all business units, Maynard
says.

"If you don't have all those [records] collected and connected
together, there's a risk you are going to miss a record or two,"
Maynard says.

Although privacy issues present technical challenges to data
management, a well-designed CRM system is much better suited to
privacy controls than a hodgepodge of separate legacy systems, says
Michael Beresik, national director of the privacy practice at New
York-based PricewaterhouseCoopers.

Keeping Data Sacred

Most affected by privacy law compliance is the health care industry,
which, under the Health Insurance Portability and Accountability Act
(HIPAA), must have strict access controls for records.

Providence Health System, a Beaverton, Ore.-based health care provider
with about 780,000 members, is developing a system that limits access
to medical records on a need-to-know basis. A financial analyst, for
instance, would see only the customer data pertinent to his work, says
Chris Apgar, Providence's data security and HIPAA compliance officer.

These changes, although not directed at customers, are nonetheless a
form of CRM because customers expect their health care records to be
confidential. "One of the big selling points is how well you are
taking care of my health data -- that's one of those things that's
sacred," Apgar says.

But many industries are worried about the unsettled nature of privacy
laws. In addition to various privacy initiatives in Congress, states
are free to adopt their own privacy standards. Some, such as
California, may require a customer opt-in policy for financial record
sharing, instead of the federal opt-out approach, which requires
consumers to take action if they want to stop record sharing.

"We are holding our breath that [lawmakers] don't change direction,
and we will have to build something totally new," says Maynard.

Internationally, U.S. firms that transfer customer and personnel data
out of Europe have to comply with European privacy laws. These laws
allow customers access to data that's held about them, and let them
determine how that information is used.

Some U.S. firms, such as consumer products giant Procter & Gamble Co.
in Cincinnati, have adopted as their global business rule the European
privacy standard, which is gradually being followed by other
countries. This approach creates uniformity and reduces potential
compliance costs, the company says.

Analysts say e-commerce companies can lose business if consumers don't
trust that personal information will be carefully guarded. Forrester
Research Inc. in Cambridge, Mass., estimates that total online
spending last year of $47.6 billion would have been $15 billion higher
had it not been for consumer privacy concerns. Companies can increase
sales by making their privacy policies clearer and easily
understandable and accessible to consumers, says Christopher Kelly, a
Forrester analyst.

On the other hand, active online consumers don't seem to pay much
attention to privacy policies, according to data compiled by
WebSideStory Inc., a company that analyzes Web site data. In its
analysis of page views, "the privacy page rarely makes the top 100" of
anyone's site, says Randy Broberg, chief privacy officer at the San
Diego-based company.

"The opinion polls that say that everybody in America is frightened to
death about privacy overstate the reality of people who are actually
surfing the Internet," Broberg says.

But based on its internal studies, Royal Bank is convinced that
privacy keeps customers coming back, says Cullen. The secret to
effective CRM is delivering value to the customer, he says.

If a customer starts turning off the information flow, does that
indicate that he's concerned about his privacy, "or does it say that
we haven't generated enough value to them?" asks Cullen.

"We have a high level of trust with our customers right now. It's ours
to lose," he says. "But there are huge benefits to doing things that
continue to reinforce that trust."



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo at attrition.org with 'unsubscribe isn' in the BODY
of the mail.

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From reinhold at world.std.com  Fri Feb 22 13:34:04 2002
From: reinhold at world.std.com (Arnold G. Reinhold)
Date: Fri, 22 Feb 2002 13:34:04 -0500
Subject: Report on a James Bamford Talk at Berkeley
In-Reply-To: <p051003a9b895d448eb82@[10.0.1.2]>
References: <p051003a9b895d448eb82@[10.0.1.2]>
Message-ID: <v04210103b89811a681dc@[192.168.0.2]>

At 4:42 PM -0500 2/17/02, R. A. Hettinga wrote:
>http://www.lewrockwell.com/orig2/bamfordreport.html
>
>
>Report on a
>James Bamford Talk at Berkeley
>
>James Bamford is the author of The Puzzle Palace and Body of Secrets, books
>about the National Security Agency. He is visiting Berkeley in the School
>of Public Policy, and gave a talk entitled "Intelligence Failures that Led
>to the September 11th Attacks."
>
...
>NSA was created after WWII from the code breaking activity that had
>proceeded during the war. At the time it was created, no one but a couple
>of people even knew it had been created. NSA stands for no such agency, or
>never say anything, or after Puzzle Palace, not secret anymore. To
>illustrate how secret NSA is, after Puzzle Palace was published, Bamford
>went on a book tour. At one point he was scheduled onto a PBS show where
>the other guest was Sen. Bill Bradley. Prior to the show, the Senator asked
>Bamford why he was on the show, and he explained that he had written a book
>on the NSA. Bradley asked him what that was, and Bamford explained. Then
>Bradley went on the show to explain his ideas for the economy, or whatever,
>and then the interview switched to Bamford. Bamford explained that the NSA
>was a secret agency. The interviewer said "How secret?" And, naturally,
>Bamford did not pass on the opportunity to say that it was so secret that
>not even Sen. Bradley knew about it. Bradley was not pleased.

Nonsense! The NSA's existence and purpose hasn't been much of a 
secret since the early 60's, long before The Puzzle Palace was 
published in 1982.  Kahn has a chapter on NSA in The Codebreakers, 
which came out in 1967, and that chapter wasn't much of a revelation 
even back then. No wonder Bradley was not pleased. He'd been 
sandbagged.

>...
>
>About NSA: it is 38,000 people, 50 buildings, on a campus in Maryland, in
>suburban Washington DC. The have the most powerful computers in the world,
>1.6 million tapes in their tape library [tapes?].

The helical scan system, later commercialized as the video tape 
recorder, was invented for NSA so they could record whole swaths of 
the radio spectrum for later analysis. Instead of monitoring each 
station, they could go back and replay the tapes once they knew what 
to look for. I believe they attempted to record the entire HF 
spectrum continuously from multiple locations. 1.6 million tapes 
sounds low if anything.

>Basically they do signals
>intelligence, listening to phone calls, faxes, email, and any sort of
>communication.

Other signals as well, such as missile telemetry, satellite control, 
unintended emissions and all types of radar. (I believe one of the 
arms control treaties prohibits the U.S. and Russian from encrypting 
missile test telemetry.)

>To do this they have extensive facilities all around the
>world. One technique that Bamford mentioned was how they capture microwave
>signals. Microwave, unlike high frequency signals [HF are actually lower
>frequency than microwave, in case you care], do not bounce off the
>ionosphere and travel in a straight line. Towers must be line of sight from
>each other. So how's the NSA going to listen to this? Answer is that some
>of the radiation goes past the receiving station, and continues in its
>straight line out into space. The NSA has satellites out there to grab the
>signals. [Bamford described the satellites as geosynchronous, but that
>wouldn't work.]

I think Bamford got it close to right on this one.  Aviation Week has 
reported on NSA geosynchronous satellite launches from time to time. 
See also 
http://users.ox.ac.uk/~daveh/Space/Military/milspace_sigint.html and 
http://www.fas.org/spp/military/program/sigint/androart.htm

There are several problems with low earth orbit satellites as 
listening systems. First, they only able to monitor any given spot 
for a short time. Target countries can shut off systems of interest 
while the satellite is overhead.  The second is that low earth orbit 
satellites can be attacked more easily and quickly in time of war. 
The U.S. at one time had an air launched missile that could do this. 
Geosynchronous orbit takes more energy and a longer time to get to.

Finally, a directional antenna on a low earth orbit satellite has to 
be steered very rapidly as the satellite moves over its target. That 
is very hard to do mechanically, and electronically steered antennae 
have narrow bandwidths, not what NSA wants for monitoring.  A 
geosynchronous monitoring satellite can have a huge, light weight 
parabolic mesh pointed at Earth. It only needs to steer very slowly, 
if at all. Remember that while signal strength drops as the square of 
the distance, a parabolic antenna's gain grows as the square of its 
diameter.  Geosynchronous orbit is about 50 times higher than typical 
low earth orbits used by NSA, so a 50 times wider antenna gets you to 
beak-even on signal strength.

NSA also uses satellites in 12-hour semi-synchronous elliptical 
orbits for the same reason that the Soviets put their "Molniya" 
communications satellites in similar orbits: the northern portions of 
Russia are not visible from synchronous orbit.

>NSA also makes and breaks codes. The big nasty secret
>within NSA is that in the forty years or more that NSA spent billions of
>dollars on breaking the Soviet codes, they made no progress. No important
>Soviet code was ever broken by the NSA, or by anyone.

Umm, what about Venona? The NSA has lots of info on that break on its 
home page. http://www.nsa.gov/docs/venona/index.html  In that case, 
the Soviets were sloppy in manufacturing onetime pads. Soviets 
undoubtedly used mechanical crypto systems in the 50's and maybe 60's 
whose key length is short by modern standards.  Some of these must 
have been broken by now. The lack of any reports about such breaks 
suggests that the NSA is able to keep such info secret.

This raises an interesting question. How far back does NSA go in 
recovering communications that are only of historic interest? Would 
they release ciphertext of 1950's messages so amateurs could try?

>
>NSA has a whole bunch of listening posts around the world. There's one in
>England. Each post captures about two million messages per hour. They cull
>out the interesting ones in many ways - limiting prefixes, etc. The Soviets
>had a listening post in Cuba for forty years (they are only just now
>dismantling it) and they knew how to filter out the interesting stuff. For
>example, any phone call to prefix 456 in the DC area code was a call to the
>White House, any call to 688 is a call to NSA.

There is no way anyone is going to intercept DC phone calls from a 
station in Cuba. On the other hand, a PC with a UHF receiver card can 
do a great job of monitoring cell phones from the Russian embassy in 
DC. NSA was very upset when the State Department let the USSR build 
its new embassy on a hilltop. Thanks to the none-to-poor encryption 
used by cell phones, any foreign government can afford to monitor 
these calls from their embassies, consular offices or even staff 
apartments.

>
>So what about NSA's involvement in Sept. 11. Some have compared the failure
>to the "failure" at Pearl Harbor. Actually, Pearl Harbor was quite a
>success for the predecessor agencies to NSA. The US had managed to
>completely break the key Japanese codes (Purple), and the German codes
>(Enigma) were also broken. In the case of Pearl Harbor, the US signals
>people picked up the key message to the Japanese embassy in Washington,
>decoded it (it said something like break off relations and destroy all your
>crypto equipment) well in advance of the attack.

About 12 hours.

>The message did not say
>where an attack would come, so the US sent the message to everyone saying
>"Japanese attack expected."

The message (sent in 12 parts) instructed the Japanese Ambassador to 
deliver a note breaking off negotiations at exactly 1 pm  Washington 
time. That was just after dawn in Hawaii. The Emperor wanted a 
legally colorable declaration of war to be delivered just before the 
attack. The Navy got the significance of the timing and specifically 
wanted to warn Pearl Harbor. An earlier message (Nov. 27, 1941) 
warned all bases that war could break out at any time.

>The weather was wrong over the Pacific so the
>usual HF path did not work. Instead the message was sent to Honolulu via
>Western Union, where it arrived a few hours after the attack.

The Navy wouldn't use an Army circuit that was up.  The message 
arrived at Western Union Honolulu in time but was sent to the base by 
bicycle. A teletype link between Pearl and the Honolulu WU office was 
being installed but wasn't up yet. Note that even an hour or two's 
warning would have been enough to get planes and anti-aircraft 
batteries on the ready to put up enough resistance to reduce the 
attacks effectiveness.  Here's a photo showing the clear field the 
Japanese enjoyed that morning: 
http://www.history.navy.mil/photos/images/h50000/h50930.jpg

>
>In contrast, NSA did nothing to help prior to Sept. 11. No monitoring of
>Osama Bin Laden (OBL) was done. The hijackers of the plane that would up
>hitting the Pentagon lived in Laurel, MD, the same town that NSA was in.
>When the hijackers drove from Laurel down US 1 toward Dulles, the traffic
>in the other direction was mostly NSA employees on their way to work.
>Rather embarrassing to the NSA, in fact a disaster of major proportions.
>Realize that the primary goal of NSA, the justification for the billions of
>dollars per year of our citizens money spent by the NSA, is simply to
>prevent a surprise attack. Yet the US and NSA was caught totally
>unprepared. Bush was reading to first graders in Sarasota, the head of NSA
>was having breakfast in downtown Washington.


The parallels between September 11, 2001 and December 7, 1945 are striking:

    o  Both attacks were extremely well planned to preserve surprise.

    o  We had general knowledge that an attack was likely but no 
specific details.

    o  There were bits and pieces of intelligence that were overlooked.

    o  Low tech protection measures were available that could have 
reduced the damage, but were not deployed (torpedo nets in 1941, 
strong cockpit doors in 2001).

    o  There was no command follow up to the general warning to verify 
that preparations were being made.

    o  In both attacks our enemy maintained radio silence. (Admiral 
Yamamoto's orders were delivered by courier to the fleet in Edo 
harbor. Bin Laden team leader in the U.S.  apparently traveled to 
Europe for briefings).

    o  The attacks were far more audacious than anything we expected.

    o  Inter-organizational barriers and communication failures 
diminished our effectiveness.

After both attacks, attempts were made to put the blame on 
intelligence. The failure of military leaders to act on the general 
warnings that intelligence did provide was down played. Admiral 
Kimmel, in charge of Pearl harbor,  explained the presence of nearly 
the entire fleet in port by claiming he wanted the troops to have as 
much rest as possible prior to war. We have yet to hear the excuses 
for 9/11, but there are lots of questions:

    o  What preparations had the Air Force made for dealing with 
suicide aircraft hijackers? (We had been attacked by car bombs, truck 
bombs and a boat bomb.  A small plane had already crashed into the 
White House during the Clinton years. How hard was this to foresee?

    oo  The FAA was initially uncertain as to whether the first flight 
was diverting because it was hijacked or had merely suffered a radio 
failure. Why didn't the FAA have better procedures for dealing with 
loss of radio communication? All it takes is publishing a phone 
number for pilots to call on their cell phones. Do they have one now?

    oo  Why didn't the FAA contact the Air Force immediately when the 
first flight diverted from its flight plan? We were on alert for a 
possible major terrorist action and having a fighter jet along side 
could be helpful to a pilot in an ordinary emergency.

    oo  Why wasn't the first flight of F-15's, scrambled to NYC from 
Otis AFB in Massachusetts, ordered to fly supersonic? They knew at 
that point an attack was in progress. There was enough time to 
intercept the second jet to hit the WTC if they had.

    oo  Why didn't the Air Force scramble fighters to cover Washington 
after the second plane hit the World Trade Center (or sooner). There 
would have been enough time stop the Pentagon attack at least if they 
had. Instead they waited until they a report came in that a third jet 
was missing. By then it was too late.


>
>OBL moved his operations from the Sudan to Afghanistan. The infrastructure
>there was insufficient for OBL's needs, so he contacted an intermediary in
>London who in turn arranged for a student in the US to buy a satellite
>phone. The phone was mailed to London, the service activated there, and the
>phone mailed to OBL. It was an Inmarsat phone. So NSA has a billion
>dollars, they figured this out and got good eavesdropping on OBL. NSA was
>very proud of this, and would show off their abilities to distinguished
>guests at NSA. They would laugh as he called his mother and talked to her.
>Unfortunately, OBL seemed to sense something, because he never used the
>satphone for operational material. Just used it for calls home. But this is
>still useful: at least we know where he is, because the phone radiates, and
>that radiation can be tracked. And we took advantage of that: Clinton
>called for reprisals against OBL after the embassy bombings in E. Africa,
>and we sent missiles to a training base in Afghanistan that we knew about
>because of the satphone. Unfortunately, two bad things resulted: one, OBL
>was not there when the missiles arrived, and two, OBL, no dummy, stopped
>using the satphone when he realized it was being used to track him. The NSA
>never heard from him again. Never. NSA went deaf.

A big issue in WW II cryptanalysis was haw much the fruits of the 
intercepts could be used in battle, with the attendant risk of the 
enemy realizing their codes were broken. According to Kahn, the then 
rule was that results could be used to win a major battle. One 
exception was the assassination of Adm. Yamamoto. His skills were so 
respected that his death was considered as important as winning a 
major battle. The same considerations apply here. The U.S. military 
thought they could use the signals intelligence to deliver a 
devastating blow against Bin Laden. They didn't.

>
>NSA had other problems: only one or two (at the most) NSA people can speak
>an Afghan language. And there were lots of other structural problems at
>NSA. To understand this, understand that until ten years ago, NSA had
>essentially a single mission: track the Soviets. NSA knew about Russian
>missiles and submarines. They looked for the missiles, and set up very
>advanced equipment that could provide early warning if a Soviet missile
>were launched. To illustrate this capability, recall that a few months ago
>an Israeli plane was shot down on its way from Israel to Russia. The US
>immediately announced that a missile had shot down the plane. The guys who
>did the deed denied it initially, but soon it came out that the US was
>right. These are your NSA tax dollars at work. That's what we do, but
>that's the wrong thing if you are worried about terrorists. Ten years after
>the end of the cold war, the NSA still has the wrong technology in the
>wrong places.
...

There are many steps in using signal intelligence to thwart a surprise attack:

1. The attacker must send messages that reveal his intentions is some way.
2. Those communications must be intercepted and deemed important 
enough for further processing.
3. The message must be decrypted and translated, if necessary.
4. The message must be interpreted correctly in the context of other 
intelligence.
6. A effective action plan must be formulated and ordered. This 
includes weighing the risk of not acting with the risk of revealing 
sources.
7. The actions must be communicated to the field.
8. The actions must be executed in time.

Note that cryptography only plays a role in steps 3 and 2 (stego). 
Yamamoto and Bin Laden short circuited this process at step 1. 
Relying on signals intelligence, or any intelligence, as the sole 
defence against terrorism is folly. A layered approach is needed.

The failures at Pearl harbor were thoroughly investigated and the 
U.S. learned a lot. I hope the failures on and before September 11 
will be looked at unblinkingly, and not covered over to spare the 
feelings and careers of those who missed opportunities.

Arnold Reinhold


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Sat Feb 23 10:06:08 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Sat, 23 Feb 2002 10:06:08 -0500
Subject: UK bill would "infringe scientists' freedom"
Message-ID: <p0510030fb89d60413f02@[10.0.1.2]>

http://www.newscientist.com/news/print.jsp?id=ns99991944

 
 
UK bill would "infringe scientists' freedom"

 
14:30 18 February 02
Duncan Graham-Rowe and Will Knight

 
British scientists could soon face a ten-year jail sentence for sending an
email or failing to ask for permission before teaching a foreign student.

New legislation, which will be reviewed by UK House of Lords in March,
would even give the government the right to "prior review" of scientific
papers - effectively allowing ministers to censor academic research if they
so choose.

"It potentially affects every type of science and technology and a fair
amount of medicine too," says Ross Anderson, computer scientist at
Cambridge University and cofounder of the Foundation for Information Policy
Research.

The Export Control Bill is designed to curb the spread of scientific
knowledge on how to make weapons of mass destruction. It is being touted as
a modernisation of existing controls, following a UK government report in
1996 that found British intelligence had been illegally selling weapons to
Iraq.


Journal threat


For decades, controls have existed on the transfer of physical goods on the
"dual-use" list - a list, recognised by the international community, of
technologies that could have both civilian and military uses.

These controls have allowed scientists to carry out research with relative
freedom, provided they do not try to physically carry it overseas.

But the new powers will extend these controls to apply to "intangibles",
such as software, emails, designs and presentation slides. This will
subject much more scientific activity to controls, says Nicholas Bohm, a
member of the Law Society's electronic law committee.

Even more worrying is that the bill covers internal communications within
the UK - not just "exported" communications. Anyone submitting their
research for publication in a British journal could be subjected to the
controls. This, say critics, could prevent scientists from assessing and
replicating their colleagues' work, and threatens to undermine the very
fabric of the scientific process.

"The problem of the dual list is that it contains anything that the MOD
thinks is high-tech," explains Anderson. This can include anything from
semiconductor testing equipment and hard composites to certain types of
catalyst, he says. It would also include types of software that many
researchers have posted on their websites, such as cryptoanalytic or
code-breaking programmes. Such postings could become illegal overnight.


Fundamental freedom


The Department of Trade and Industry, which drafted the bill, say the
exemptions will be brought in to protect academic interests as secondary
legislation, after the bill has passed. But such reassurances are little
comfort, since secondary legislation cannot be amended once it has been
drafted by ministers.

Universities UK, which represents the heads of British Universities, is
concerned that the Bill could have dire consequences for collaborative
research, both within the UK and overseas.

"We believe that there should be some direct reference to the protection of
routine academic activity in the text of the bill," a spokesman for
Universities UK told New Scientist. The potential power to give government
the right to prior review of scientific publications could infringe
scientists' fundamental academic freedom, he adds.

The DTI claim that the bill will merely bring the UK into line with
European regulations, introduced in 2000, which extend export controls to
include intangibles. "But the UK was a prime mover in pushing for these
extensions in the first place," says Bohm. "The European regulations don't
require the UK to impose domestic transfer or publications controls."

 
14:30 18 February 02
 

Return to news story

 
 ? Copyright Reed Business Information Ltd.

 

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From udhay at pobox.com  Sun Feb 24 07:05:13 2002
From: udhay at pobox.com (Udhay Shankar N)
Date: Sun, 24 Feb 2002 17:35:13 +0530
Subject: [humor] Security
Message-ID: <4.2.0.58.20020224173342.00b4e4d0@202.54.12.17>

On Wed, 13 Feb 2002 19:30:00 PST, in rec.humor.funny surfcow at hawaii.rr.com 
(=brian) wrote:

 >Them: Important user, NT box, lost admin password, sad, sad, sad.
 >
 >Me: No problem, change password with magic linux disk, offline NT password
 >editor.
 >
 >Them: No, no, no. Never work. NT secure. Get real.
 >
 >Me: Watch. (reboot)
 >
 >Them: Gasp! This floppy is dangerous! Where did you get it?
 >
 >Me: Internet. Been around forever.
 >
 >Them: How do we keep students from using this?
 >
 >Me: Can't. Migrate. Linux. Mac.
 >
 >Them: No, no, no. Just make NT safe.
 >
 >Me: Can't. NT inherently unsafe.
 >
 >Them: Must be safe. NT good. We have never seen problems.
 >
 >Me: You just saw one now.
 >
 >Them: No, no, no. NT good. Win2k better.
 >
 >Me: Win2k is NT. Same thing. Should I give this floppy to a student?
 >
 >Them: No, no, no. Give here.
 >
 >Me: Whatever. What do you want me to do?
 >
 >Them: Change admin password.
 >
 >Me: Fine. To what?
 >
 >Them: "p-a-s-s-w-o-r-d"
 >
 >Me: No, no, no.
 >
 >--
 >Selected by Jim Griffith.  MAIL your joke to funny at netfunny.com.
 >
 >Read about The Internet Joke Book -- the best of RHF at
 >http://www.netfunny.com/inetjoke.html
 >
 >This joke's link: http://www.netfunny.com/rhf/jokes/02/Feb/nt.html


--
((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com))
      God is silent. Now if we can only get Man to shut up.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Mon Feb 25 00:46:18 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Mon, 25 Feb 2002 00:46:18 -0500
Subject: Jail Cell Cipher (modified RC4)
Message-ID: <p0510036db89f801b05b8@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Sun, 24 Feb 2002 20:35:06 -0800
From: AARG! Anonymous <remailer at aarg.net>
Comments: This message did not originate from the Sender address above.
  It was remailed automatically by anonymizing remailer software. Please
  report problems or inappropriate use to the remailer administrator at
  <abuse at aarg.net>.
To: cypherpunks at lne.com
Subject: Re: Jail Cell Cipher (modified RC4)
Sender: owner-cypherpunks at lne.com

Paul Crowley has shown that Schneier's Solitaire cipher is insecure.
See http://www.ciphergoth.org/crypto/solitaire/.  Repetitions occur with
frequence 1/22.5 rather than 1/26 as they should.  Also, the state
machine is not reversible, contrary to the design intent.

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Mon Feb 25 07:19:48 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Mon, 25 Feb 2002 07:19:48 -0500
Subject: US firms move to hardware-based security
Message-ID: <p0510036eb89fdc3eab7b@[10.0.1.2]>



South China Morning Post

Monday, February 25, 2002
US firms move to hardware-based security


REUTERS

Technology providers are adopting methods of embedding security features
into microprocessors and other hardware, with several announcements made at
a computer security conference last week.

Experts said hardware-based security systems were much harder to break than
security software, from which hackers can extract passwords or steal other
sensitive data. By using both existing security software and new
hardware-based systems, computer users will be better able to protect their
data from loss or theft.

At the RSA Conference, hosted by security company RSA Security,
International Business Machines and Targus Systems unveiled a new biometric
fingerprint reader that is built into a PC Card and slides into a card slot
of new IBM ThinkPad laptops.

When the fingerprint readers are available in March, they will allow
computer users to authenticate themselves and access data using a
fingerprint rather than a password.

In another announcement at the conference, which ended on Friday, VeriSign
and Phoenix Technologies said they would be offering later this year a way
to tie a computer user's identity to a specific computer.

The companies will integrate VeriSign's so-called "root key" software into
the next version of Phoenix's FirstBIOS (basic input/output system).
Phoenix's BIOS, used in the majority of PCs manufactured, is software in
the microprocessor that starts, configures and shuts down the computer.

Stolen user names and passwords are useless on any other machine, and if
the computer gets stolen no one else but the authorised user can be
authenticated on the computer, according to Bob Pratt, technology
evangelist at VeriSign.

"Normally the key is stored on the hard drive, but a file can be copied off
the disk and a password can be cracked," making that method less secure, he
said.

IBM also announced a new version of its IBM Client Security Software, which
allows people to protect their data with encryption and other technology.

IBM Client Security Software Version 3.0 now operates with the RSA SecurID
authentication system used for accessing virtual private networks, which
provide secure channels between remote users and corporate networks.

With SecurID, people need a password and a separate token to get onto the
network. Now, IBM's Embedded Security Subsystem, which is included in
certain versions of ThinkPad notebooks and NetVista desktops, eliminates
the need for a separate token.

The IBM Client Security Software also can communicate with a wireless
proximity badge, made by XyLoc, that computer users can carry separately.
The credit card-sized badge locks the computer when the user steps away
from it.

IBM launched the first PCs installed with a hardware-based embedded
security chip in 1999.
------------------------------------------------------------------------
SCMP.com is the premier information resource on Greater China. With a
click, you will be able to access information on Business, Markets,
Technology and Property in the territory. Bookmark SCMP.com for more
insightful and timely updates on Hong Kong, China, Asia and the World.
Voted the Best Online newspaper outside the US and brought to you by the
South China Morning Post, Hong Kong's premier English language news source.
------------------------------------------------------------------------

Published in the South China Morning Post. Copyright ? 2002. All rights
reserved.

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From bear at sonic.net  Mon Feb 25 14:49:26 2002
From: bear at sonic.net (bear)
Date: Mon, 25 Feb 2002 11:49:26 -0800 (PST)
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
In-Reply-To: <000901c1bb14$7ae17320$16c89c8d@PHZ>
Message-ID: <Pine.LNX.4.40.0202251101050.31441-100000@newbolt.sonic.net>

[Moderator's inquiry: Any third parties care to comment on this? --Perry]

On Thu, 21 Feb 2002, Phillip H. Zakas wrote:

>> >On Tue, 5 Feb 2002, Eugene Leitl wrote:

>> >But at Crypto last August, Dan Bernstein announced a new design for a
>> >machine dedicated to NFS using asymptotically fast algorithms and
>> >optimising memory, CPU power and amount of parallelism to minimize
>>
> Bear Responds:
>> I really want to read this paper; if we don't get to see the
>> actual mathematics, claims like this look incredibly like
>> someone is spreading FUD. Is it available anywhere?
>>
>
>The paper is located here: http://cr.yp.to/papers.html
>I've not evaluated yet but I'm interested in hearing if he received his
>grant to try it out.

Holy shit.  The math works.  Bernstein has found ways of
using additional hardware to eliminate redundancies and
inefficiencies which appear in any linear implementation of the
Number Field Sieve.  We just never noticed that they were
inefficiencies and redundancies because we kept thinking in
terms of linear implementations.  This is probably the biggest
news in crypto in the last decade.  I'm astonished that it
hasn't been louder.

Note that there have been rumors of an RSA cracker built by a
three-letter agency in custom silicon before this, but until
analyzing Bernstein's paper I had always dismissed them as
ridiculous paranoid fantasies.  Now it looks like such a device
is entirely feasible and, in fact, likely.

This work demonstrates a lack of security in a bunch of PGP Keys.
All previous estimations of security level as a function of bit
length, should be applied as though the bit length were one-third
of its actual length.  This means that effectively all PGP RSA
keys shorter than 2k bits are insecure, and the 2kbit keys are
not nearly as secure as we thought they were.

I remember there was one version of PGP that allowed RSA keys
longer than 2kbits - I don't remember what version it was right
now, but someone is sure to remind us now that I've said so. :-)
Anyway, probably very few people are using 4kbit or 8kbit PGP
RSA keys anyhow, due to lack of cross-version compatibility.

The "secure forever" level of difficulty that we used to believe
we got from 2kbit keys in RSA is apparently a property of 6kbit
keys and higher, barring further highly-unexpected discoveries.

Recommendation to all implementors:  Future applications should
not offer to create RSA keys shorter than 2048 bits, and should
allow users to specify keys of up to *at least* 8 kbits in length.
Remember, backward compatibility is inappropriate where it
compromises security.

Recommendation to all crypto users: discontinue use of RSA keys
shorter than 2048 bits, NOW.  Issue a revocation if the software
you use allows it.  If the software you use is restricted to
RSA keys shorter than 2048 bits, get rid of it and find something
better.

I predict that Elliptic-Curve systems are about to become more
popular.

				Bear



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From pzakas at toucancapital.com  Mon Feb 25 15:25:59 2002
From: pzakas at toucancapital.com (Phillip H. Zakas)
Date: Mon, 25 Feb 2002 15:25:59 -0500
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
In-Reply-To: <Pine.LNX.4.40.0202251101050.31441-100000@newbolt.sonic.net>
Message-ID: <000c01c1be3a$a3582cd0$16c89c8d@PHZ>

> -----Original Message-----
> From: bear [mailto:bear at sonic.net]
> Sent: Monday, February 25, 2002 2:49 PM
> 
> On Thu, 21 Feb 2002, Phillip H. Zakas wrote:
> 
> >> >On Tue, 5 Feb 2002, Eugene Leitl wrote:
> 
> >> >But at Crypto last August, Dan Bernstein announced a new design
for a
> >> >machine dedicated to NFS using asymptotically fast algorithms and
> >> >optimising memory, CPU power and amount of parallelism to minimize
> >>
> > Bear Responds:
> >> I really want to read this paper; if we don't get to see the
> >> actual mathematics, claims like this look incredibly like
> >> someone is spreading FUD. Is it available anywhere?
> >>
> >
> >The paper is located here: http://cr.yp.to/papers.html
> >I've not evaluated yet but I'm interested in hearing if he received
his
> >grant to try it out.
> 
> Holy shit.  The math works.  Bernstein has found ways of
> using additional hardware to eliminate redundancies and
> inefficiencies which appear in any linear implementation of the
> Number Field Sieve.  We just never noticed that they were
> inefficiencies and redundancies because we kept thinking in
> terms of linear implementations.  This is probably the biggest
> news in crypto in the last decade.  I'm astonished that it
> hasn't been louder.

It does seem doable and for not very much money. Is anyone attending the
Intl. Financial Cryptography Association meeting in Bermuda from March
11-15th?  Perhaps we could arrange an informal get-together for this
list.
Phillip 



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From thing at thing.dyndns.org  Mon Feb 25 18:25:57 2002
From: thing at thing.dyndns.org (thing)
Date: Tue, 26 Feb 2002 12:25:57 +1300
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
References: <Pine.LNX.4.40.0202251101050.31441-100000@newbolt.sonic.net>
Message-ID: <3C7AC805.C9CF6B41@thing.dyndns.org>

Being a numb skull in such things does it mean IPSEC VPN is not secure?

At present im running 1024bit the cpu hit is high, going to 2048 i
suspect / told its even higher

:(

regards,

Thing

bear wrote:
> 
> [Moderator's inquiry: Any third parties care to comment on this? --Perry]
> 
> On Thu, 21 Feb 2002, Phillip H. Zakas wrote:
> 
> >> >On Tue, 5 Feb 2002, Eugene Leitl wrote:
> 
> >> >But at Crypto last August, Dan Bernstein announced a new design for a
> >> >machine dedicated to NFS using asymptotically fast algorithms and
> >> >optimising memory, CPU power and amount of parallelism to minimize
> >>
> > Bear Responds:
> >> I really want to read this paper; if we don't get to see the
> >> actual mathematics, claims like this look incredibly like
> >> someone is spreading FUD. Is it available anywhere?
> >>
> >
> >The paper is located here: http://cr.yp.to/papers.html
> >I've not evaluated yet but I'm interested in hearing if he received his
> >grant to try it out.
> 
> Holy shit.  The math works.  Bernstein has found ways of
> using additional hardware to eliminate redundancies and
> inefficiencies which appear in any linear implementation of the
> Number Field Sieve.  We just never noticed that they were
> inefficiencies and redundancies because we kept thinking in
> terms of linear implementations.  This is probably the biggest
> news in crypto in the last decade.  I'm astonished that it
> hasn't been louder.
> 
> Note that there have been rumors of an RSA cracker built by a
> three-letter agency in custom silicon before this, but until
> analyzing Bernstein's paper I had always dismissed them as
> ridiculous paranoid fantasies.  Now it looks like such a device
> is entirely feasible and, in fact, likely.
> 
> This work demonstrates a lack of security in a bunch of PGP Keys.
> All previous estimations of security level as a function of bit
> length, should be applied as though the bit length were one-third
> of its actual length.  This means that effectively all PGP RSA
> keys shorter than 2k bits are insecure, and the 2kbit keys are
> not nearly as secure as we thought they were.
> 
> I remember there was one version of PGP that allowed RSA keys
> longer than 2kbits - I don't remember what version it was right
> now, but someone is sure to remind us now that I've said so. :-)
> Anyway, probably very few people are using 4kbit or 8kbit PGP
> RSA keys anyhow, due to lack of cross-version compatibility.
> 
> The "secure forever" level of difficulty that we used to believe
> we got from 2kbit keys in RSA is apparently a property of 6kbit
> keys and higher, barring further highly-unexpected discoveries.
> 
> Recommendation to all implementors:  Future applications should
> not offer to create RSA keys shorter than 2048 bits, and should
> allow users to specify keys of up to *at least* 8 kbits in length.
> Remember, backward compatibility is inappropriate where it
> compromises security.
> 
> Recommendation to all crypto users: discontinue use of RSA keys
> shorter than 2048 bits, NOW.  Issue a revocation if the software
> you use allows it.  If the software you use is restricted to
> RSA keys shorter than 2048 bits, get rid of it and find something
> better.
> 
> I predict that Elliptic-Curve systems are about to become more
> popular.
> 
>                                 Bear
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From FrogRemailer at bigfoot.com  Mon Feb 25 21:04:16 2002
From: FrogRemailer at bigfoot.com (Frog3)
Date: 26 Feb 2002 02:04:16 -0000
Subject: No subject
Message-ID: <ML6F6WUJ37313.127962963@frog.gilgamesh.org>

x8MjcT6TNxhcVyLEUs7Ljax3sqXTDPdZfpPCNTzO

k?
	 <root at hackserv.saiknes.lv>.
Subject: Bernstein's NFS machine
Message-ID: <6a8f1c4391892fa485ed43c718c7377c at disastry.dhs.org>

Analysis of Bernstein's NFS machine when applied to a 1024 bit RSA key
See http://cr.yp.to/papers.html#nfscircuit.

We will ignore O(1) terms to get some ballpark concrete results.

The main parameter for a 1024 bit modulus size:
L = 2^45.  (All powers of 2 are rounded to integers.)

The normal NFS would take time 2^86 and space 2^43 for this size.

Bernstein's NFS takes time 2^53 and space 2^36.

The speedup is (in part) by using ECM in parallel to find smooth numbers.
Also the matrix reduction is done in parallel as well.

For the optimal design balancing these two parts, the numbers we are
checking are of size 2^46.  We are checking for smoothness against a
bound of 2^36.  We need to do two smoothness checks per element.

The parallel ECM machine has 2^36 simultaneous units each checking
smoothness against a bound of 2^36.  Each will do 2^36 tests in time 2^36,
for a total throughput of 2^71 in time 2^36.  Actually this is wrong;
each test will take 2^18, which is counted as negligible, but in fact
it makes the time be 2^54.  This part is hidden in an O(1) but it is a
significant slowdown.

We need to do 2^89 tests at an estimated rate of 2^72 tests per 2^36
time for an estimate of 2^53 time.  Applying the correction that ECM
test time is not negligible gives us an estimate of 2^71 time.

The cost is the need to build a machine that can do 53 billion
simultaneous, independent ECM factorizations for smoothness testing.
It's not clear how amenable this would be to hardware implementation.

A time of 2^71 is considerably less threatening than 2^53.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From reinhold at world.std.com  Tue Feb 26 09:12:01 2002
From: reinhold at world.std.com (Arnold G. Reinhold)
Date: Tue, 26 Feb 2002 09:12:01 -0500
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
In-Reply-To: <Pine.LNX.4.40.0202251101050.31441-100000@newbolt.sonic.net>
References: <Pine.LNX.4.40.0202251101050.31441-100000@newbolt.sonic.net>
Message-ID: <v04210107b8a140c9e530@[192.168.0.2]>

At 11:49 AM -0800 2/25/02, bear wrote:
>...
>The "secure forever" level of difficulty that we used to believe
>we got from 2kbit keys in RSA is apparently a property of 6kbit
>keys and higher, barring further highly-unexpected discoveries.

Highly-unexpected?   All of public key cryptography is build on 
unproven mathematical assumptions. Why should this be the last 
breakthrough? If you plot the curve of what key length was considered 
long enough as a function of time, it doesn't look very good.

Perhaps it is time to stop claiming "secure forever" altogether until 
solid mathematical proofs of security are available.

>...
>I predict that Elliptic-Curve systems are about to become more
>popular.
>

I'm not completely comfortable with Elliptic-Curve systems. The 
mathematics is relatively young and has seen a lot of progress. Yet 
typical EC key length recommendations are based on the assumption 
that there is no way to calculate discrete logs in EC groups that is 
any faster than the general algorithm that applies to all finite 
groups. That sounds pretty aggressive to me.

If we are going to have to upgrade OpenPGP standards in light of the 
Bernstein paper, I would suggest a standard that combines RSA, EC 
and, if possible, a third PK system whose algorithm is based on an 
apparently independent problem.  The advantage of double or triple 
encryption is that a breakthrough in one problem area does not 
immediately compromise all your previously encrypted data. And you 
can upgrade the component key in question and distribute it signed 
with the old key, without have to start from scratch in establishing 
trust. Most personal computers are capable of this level of security. 
Why settle for less?


Arnold Reinhold

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Tue Feb 26 10:11:03 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 26 Feb 2002 10:11:03 -0500
Subject: U.S. Agency's Computers Didn't Protect Indian Fund
Message-ID: <p051003ebb8a155aa5844@[10.0.1.2]>

This is the not-really-9/11 case that shut down *all* Department of the
Interior access to the net this fall...

Cheers,
RAH
------


http://www.nytimes.com/2002/02/26/technology/26INDI.html?todaysheadlines=&pagewanted=print



February 26, 2002


U.S. Agency's Computers Didn't Protect Indian Fund


By JOHN MARKOFF


nstructed by a federal district judge to determine whether the computer
network at the Bureau of Indian Affairs was secure from malicious
intruders, Alan Balaran decided to infiltrate it.

He did this not once, but three times, and determined among other things
that skilled hackers would be able to bilk Indian funds in trust at the
bureau by having checks sent to themselves.

First Mr. Balaran went to a bureau building in Virginia, walked in through
a loading platform and asked directions to the computing nerve center,
where he plucked from a shredder a lengthy printout of data on some of the
trust fund accounts that the agency manages for half a million Indians.
Nobody stopped him.

Then he hired a team of hackers to break into the bureau's computers, using
commonly available software.

Finally, after the bureau complained that the computer assault had been
unfair because it relied on inside knowledge of the agency's network, Mr.
Balaran's team broke in again, without such help, even setting up a trust
fund account in his name.

Mr. Balaran is no computer rogue. He is a Washington lawyer appointed as a
special master by the federal judge, Royce C. Lamberth, who, hearing the
largest class-action suit ever filed by Indians, has already determined
that for more than a century the government has mismanaged accounts held in
trust for them. Judge Lamberth, who sits in Washington, will now determine
whether the government should be held in contempt for failure to abide by
past orders to repair its work.

Mr. Balaran, appointed by the judge in 2000 to oversee a variety of issues
related to the suit, began looking into computer security at the bureau
early last year. The effort intensified when a group of plaintiffs
discovered, in the April 2001 issue of Government Executive magazine, an
interview in which the agency's chief information officer, Dominic Nessi,
confessed that its systems were vulnerable to hacking.

"For all practical purposes, we have no security," Mr. Nessi said in that
interview.

Computer security experts say that although the problems at the bureau are
particularly striking, they are not isolated. Many federal agencies are
vulnerable, they say, despite years of public concern.

Mr. Balaran declined to comment publicly on his investigation, citing his
continuing role in the court case. But the report on what he found, filed
with the court in November, is a litany of security lapses stemming from
what the report portrays as official neglect for over a decade.

A spokesman for the Interior Department, parent of the Bureau of Indian
Affairs, defended the bureau's computer security efforts, saying it had
tried to deal with vulnerabilities long before the report. "I don't propose
to defend all of the shortcomings," said the spokesman, John Wright. But
"it's not like they didn't try to fix the problems. There were a number of
attempts. We were led to believe" by consultants that the bureau's systems
worked, "and they didn't work."

Mr. Balaran's infiltration began last February, when, accompanied by a
Justice Department lawyer, he drove to the bureau's supposedly secure data
processing center in Reston, Va. After Mr. Balaran asked his companion to
remove his tie so as to attract less attention, they entered the building
from the loading dock. Although they wore no badges, they were able to walk
past a guard at the entrance - twice, simply to make the point - without
being questioned.

Once inside and searching for the secure computing area responsible for
processing and storing data related to Indian trust funds, Mr. Balaran
asked directions from a passer-by. He was escorted to the computing room on
the second floor. There he was able to walk to a shredder and pick up a
voluminous computer printout with detailed information about trust funds -
money controlled by the government for the benefit of Indians whose
property, descended from a system of tribal ownership and managed by
Washington, is generally leased to oil, gas or timber companies.

Mr. Balaran filed a report in March alerting the court to the break-in and
the outcome, and then struck again a few months later. He hired Predictive
Systems Inc. (news/quote), a computer security company based in New York,
to perform a "pen test" - industry jargon for any electronic effort to
penetrate the defenses of a computer system. When the Predictive Systems
team examined the bureau's network, it was immediately apparent that it
would be possible to gain access to sensitive data via the Internet using
readily available software tools.

Once the company penetrated the network and reported its findings to Mr.
Balaran, the bureau protested the results, saying that the pen test
ordinarily would have failed but that the Predictive Systems penetration
team, as part of the exercise, had had detailed information about the
agency's network.

So Mr. Balaran asked the company on Aug. 30 to attack the agency's
computers again. This time he authorized the consultants to create a trust
account in his name.

In October, Predictive Systems supplied a report reiterating its findings
that the bureau's computer systems were vulnerable to attack. In the second
test, conducted without any prior reference material, the consultants used
a completely different computer network to gain access.

As instructed, they also set up an account in Mr. Balaran's name. Since the
attack took place during the middle of the trust fund billing cycle, no
check was issued. But Mr. Balaran said the group had proved to his
satisfaction that it would be possible to send money to any address.

After reading Mr. Balaran's report, Judge Lamberth forced the entire
Interior Department in December to shut down virtually all its computer
systems, since access to the systems of the Indian affairs bureau could be
gained through the systems of other Interior agencies. This month, with Mr.
Balaran's oversight and the help of Predictive Systems, the department
finally began restoring the interrupted operations, among other things
sending checks to thousands of Indians to whom trust-fund payments had been
suspended as a result of the shutdown.

Mr. Wright, the Interior Department spokesman, says that 52 percent of the
department's systems are now back online and that Interior is working with
Mr. Balaran, system by system, to return to complete operation. He could
not say when that would be.

Mr. Balaran's report noted that there had been at least four earlier ones
indicating computer security weaknesses at the bureau. Those warnings date
from 1989, when the accounting firm of Arthur Andersen first raised
concerns.

Most recently, in late 1999, Mr. Nessi, then special adviser to the
assistant interior secretary for Indian affairs, commissioned such a report
from SeNet International, a computer security company. The evaluation,
completed in the spring of 2000, cost nearly $1 million and identified
hundreds of weaknesses.

But Mr. Balaran noted in his report that when he interviewed Mr. Nessi in
June of last year, he discovered that the SeNet report had been read by
neither Mr. Nessi nor any other Indian affairs official.

Mr. Balaran's report quoted Mr. Nessi as saying, "You know, with all the
duties that I have, I would not be able to get to each of them."

Reached last night at his Virginia home, Mr. Nessi, who now has another job
at Interior, said he had in fact read part of the report and in any case
had been briefed by SeNet on all of it. He said he had spent his time at
the bureau trying to address the very problems Mr. Balaran ultimately
identified.


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From bear at sonic.net  Tue Feb 26 11:40:40 2002
From: bear at sonic.net (bear)
Date: Tue, 26 Feb 2002 08:40:40 -0800 (PST)
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
In-Reply-To: <v04210107b8a140c9e530@[192.168.0.2]>
Message-ID: <Pine.LNX.4.40.0202260832330.18597-100000@newbolt.sonic.net>



On Tue, 26 Feb 2002, Arnold G. Reinhold wrote:

>>I predict that Elliptic-Curve systems are about to become more
>>popular.
>>
>
>I'm not completely comfortable with Elliptic-Curve systems. The
>mathematics is relatively young and has seen a lot of progress.

Right.  I'm not very comfortable with Elliptic-Curve yet, either.
I haven't been able to work out exactly how, but I have a gut
feeling that there may be some translation or transformation of
the Elliptic-Curve problem that simplifies to integer factoring,
and as a result I'm not comfortable with EC key lengths shorter
than factorable numbers. However, I'm just a hobby mathematician.
I'm going to let the real mathematicians pound on it for a decade
or so and see what they come up with.

>If we are going to have to upgrade OpenPGP standards in light of the
>Bernstein paper, I would suggest a standard that combines RSA, EC
>and, if possible, a third PK system whose algorithm is based on an
>apparently independent problem.

This is probably a good idea - but independent keys for those
systems are going to make the keys *long*. Still, disk space is
cheap now, so yeah, that's probably the way to go.

Isn't Elliptic-Curve patent-encumbered?


				Bear


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Tue Feb 26 12:49:15 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 26 Feb 2002 12:49:15 -0500
Subject: [camram-spam] distributed checksum clearing house
Message-ID: <p05100313b8a17b100350@[10.0.1.2]>


--- begin forwarded text


Status:  U
Mailing-List: contact camram-spam-help at camram.org; run by ezmlm
Reply-To: camram-spam at camram.org
Date: Mon, 25 Feb 2002 21:24:59 +0000
From: Robin Benson <rob at hammerheadmedia.co.uk>
To: <camram-spam at camram.org>
Subject: [camram-spam] distributed checksum clearing house

Don't know if people here have seen this already.

http://www.rhyolite.com/anti-spam/dcc/

"The DCC or Distributed Checksum Clearinghouse is a system of clients and
servers that collects and count checksums related to mail messages. The
counts can be used by SMTP servers and mail user agents to detect and
reject or filter unsolicited bulk mail or spam. DCC servers can exchange
common checksums. The checksums include values that are constant across
common variations in bulk messages, including "personalizations."

[...]

-
hammerhead media
rob at hammerheadmedia.co.uk
tel +44 7967 354544
fax +44 7977 439551


---------------------------------------------------------------------
To unsubscribe, e-mail: camram-spam-unsubscribe at camram.org
For additional commands, e-mail: camram-spam-help at camram.org

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Tue Feb 26 13:40:00 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 26 Feb 2002 13:40:00 -0500
Subject: InfoSpace Buys ECash Technologies
Message-ID: <p0510031ab8a186a0baae@[10.0.1.2]>

...and the music plays one more time, with one less chair...

Cheers,
RAH

--- begin forwarded text


Status:  U
Date: Tue, 26 Feb 2002 10:30:02 -0800
Subject: Don't know how you missed this one ;-)
From: Somebody
To: R. Hettinga <rah at shipwright.com>

 http://www.businesswire.com/cgi-bin/cnn-storydisplay.cgi?story=/www/bw/webbox/bw.021902/220500186.htm&textcolor=%23000000&linkcolor=000099&vlinkcolor=purple&pre=0&strip=1&nohrule=1&notimestamp=1&noeditor=0&nocontact=0&nobackground=1&story_textcolor=%23000000&story_linkcolor=000099&header=%2Fwww%2Fbw%2Finsp%2Finsp_storyheader.shtml&footer=%2Fwww%2Fbw%2Finsp%2Finsp_storyfooter.shtml&bgcolor=%23343399

BELLEVUE, Wash.--(BUSINESS WIRE)--Feb. 19, 2002--

    With acquisition of eCash Technologies' assets, InfoSpace plans to
    bring merchants and financial institutions secure e-debit card
    processing and online and off-line stored value services such as
    pre-paid cards, loyalty programs and gift certificates

    InfoSpace, Inc. (Nasdaq:INSP), a provider of wireless and Internet
software and application services, today announced that the Company has
acquired substantially all of the technology and intellectual property of
eCash Technologies, Inc. which include electronic debit and stored value
transaction technologies.
    Terms of the deal were not disclosed.
    These innovative technologies are built on an intellectual property
portfolio of more than 20 patents issued in the US and overseas. InfoSpace
plans to offer merchants additional payment mechanisms that are expected to
reduce processing costs, while providing exciting opportunities for
merchants to drive new revenue streams and strengthen their relationships
with valued customers.
    InfoSpace plans to add electronic debit functionality to its existing
credit card and electronic-check processing services that would give
merchants the ability to accept debit card payments. Through advanced
encryption and digital signature technology, the debit solution is being
designed to be able to authenticate the consumer and merchant, and
authorize the payment via secure protocols developed by leading debit card
associations. In addition, the solution is being designed to provide
consumer identification and real-time verification of funds, allowing
merchants to enjoy the equivalent of a "card present" transaction without
certain of the fraud and charge-back concerns of "card not present"
payments.
    In addition, InfoSpace plans to offer merchants stored value coupon,
incentive, loyalty and promotion services that can be redeemed both online
and offline. Stored value programs can be used in a variety of ways by
merchants to lower costs and build customer loyalty. These programs allow
cash, points, etc. to be placed on a physical card or in an online account
that can be redeemed for goods and services at the point of sale by the
customer. For merchants with existing paper-based loyalty programs such as
pre-paid cards and gift certificates, InfoSpace plans to develop these new
technologies to extend these programs into the online world, enabling these
programs to be redeemed interchangeably online and offline.
    InfoSpace plans to offer these services to its broad network of
merchant resellers including leading financial institutions and other
merchant service providers.
    In the fourth quarter of 2001, InfoSpace Merchant services processed
more than $1 billion in transactions, up from $700 million reported in the
previous quarter. The total number of transactions processed was more than
12 million, up from 9 million reported in the third quarter.
    "Merchants today want innovative payment solutions giving them higher
cost savings and increased fraud protection for both online and offline
transactions. In addition, consumers want secure and convenient payment
solutions that can be used both online and offline," said Prakash
Kondepudi, InfoSpace executive vice president, merchant. "The acquisition
of innovative technologies from eCash will enhance our payment technologies
offered through leading merchant service providers and financial
institutions with stored value payment services that address the needs of
today's merchant businesses."

    About InfoSpace, Inc.

    InfoSpace, Inc. (Nasdaq:INSP) provides wireless and Internet software
and application services. The Company develops software technologies that
enable customers to efficiently offer a broad array of network-based
services under their own brand to any device.

    This release contains forward-looking statements relating to the
development of InfoSpace, Inc.'s products and services and future operating
results, including statements regarding InfoSpace's purchase of assets from
eCash Technologies, Inc., that are subject to certain risks and
uncertainties that could cause actual results to differ materially from
those projected. The words "believe," "expect," "intend," "anticipate,"
variations of such words, and similar expressions identify forward-looking
statements, but their absence does not mean that the statement is not
forward-looking. These statements are not guarantees of future performance
and are subject to certain risks, uncertainties and assumptions that are
difficult to predict. Factors that could affect InfoSpace's actual results
include the progress and costs of the development of our products and
services and the timing of market acceptance of those products and
services. A more detailed description of certain factors that could affect
actual results include, but are not limited to, those discussed in
InfoSpace's Annual Report on Form 10-K, in the section entitled "Factors
Affecting Our Operating Results, Business Prospects and Market Price of
Stock." Readers are cautioned not to place undue reliance on these
forward-looking statements, which speak only as of the date of this
release. InfoSpace undertakes no obligation to update publicly any
forward-looking statements to reflect new information, events or
circumstances after the date of this release or to reflect the occurrence
of unanticipated events.


    --30--cla/se*

    CONTACT: InfoSpace, Inc.
             Adam Whinston, 425/201-8946
             adam.whinston at infospace.com

    KEYWORD: WASHINGTON
    INDUSTRY KEYWORD: E-COMMERCE INTERNET NETWORKING SOFTWARE
TELECOMMUNICATIONS MERGERS/ACQ
    SOURCE: InfoSpace, Inc.

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From paul at ciphergoth.org  Tue Feb 26 14:32:56 2002
From: paul at ciphergoth.org (Paul Crowley)
Date: 26 Feb 2002 19:32:56 +0000
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
In-Reply-To: "Enzo Michelangeli"'s message of "Tue, 29 Jan 2002 09:26:09 +0800"
References: <Pine.SOL.4.33.0201272117220.13380-100000@sun3.lrz-muenchen.de> <kjsn8rqv9w.fsf@romeo.rtfm.com> <008e01c1a864$d781f9a0$0200000a@noip.com>
Message-ID: <87664k2g47.fsf@saltationism.subnet.hedonism.cluefactory.org.uk>

"Enzo Michelangeli" <em at who.net> writes:
> Well, a nice characteristic that RSA doesn't have is the ability of using as
> secret key a hash of the passphrase, which avoids the need of a secret
> keyring

All PK algorithms have this property; seed a CSPRNG with the
passphrase and use the CSPRNG as the source of randomness in key
generation. 

> and the relative vulnerability to dictionary attacks.

The protection against dictionary attacks seems to be that checking
whether a given passphrase is the correct one is slow, because you
have to check it against the public key.  However, the minimum time to
check passphrase validity can be made arbitrarily slow whatever PK
algorithm is used, with techniques such as key stretching.

http://www.counterpane.com/low-entropy.html

Your proposal makes a system *more* vulnerable to dictionary attacks,
since the attack can be mounted without the need to seize the secret
keyring.
-- 
  __  Paul Crowley
\/ o\ sig at paul.ciphergoth.org
/\__/ http://www.ciphergoth.org/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From mkb at black-ice.org  Tue Feb 26 16:38:03 2002
From: mkb at black-ice.org (Mike Brodhead)
Date: Tue, 26 Feb 2002 13:38:03 -0800
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd) 
In-Reply-To: Your message of "Tue, 26 Feb 2002 08:40:40 PST."
             <Pine.LNX.4.40.0202260832330.18597-100000@newbolt.sonic.net> 
Message-ID: <200202262138.g1QLc3G02331@valis.black-ice.org>


> Isn't Elliptic-Curve patent-encumbered?

I think we went through this a few weeks ago.  Nope.  Fortunately, ECC
per-se is not patent encumbered.  Scott Vanstone makes much of that
in his ECC dog and pony show.  

Of course, free ECC does not mean some nice optimizations aren't
patented.  

--mkb



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From berke at altern.org  Tue Feb 26 17:14:51 2002
From: berke at altern.org (Berke Durak)
Date: Tue, 26 Feb 2002 23:14:51 +0100
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
In-Reply-To: <Pine.LNX.4.40.0202260832330.18597-100000@newbolt.sonic.net>; from bear@sonic.net on Tue, Feb 26, 2002 at 08:40:40AM -0800
References: <v04210107b8a140c9e530@[192.168.0.2]> <Pine.LNX.4.40.0202260832330.18597-100000@newbolt.sonic.net>
Message-ID: <20020226231451.A29000@gogol.zorgol>

On Tue, Feb 26, 2002 at 08:40:40AM -0800, bear wrote:
> >I'm not completely comfortable with Elliptic-Curve systems. The
> >mathematics is relatively young and has seen a lot of progress.
> 
> Right.  I'm not very comfortable with Elliptic-Curve yet, either.
> I haven't been able to work out exactly how, but I have a gut
> feeling that there may be some translation or transformation of
> the Elliptic-Curve problem that simplifies to integer factoring,
[...]

Plus, I'd remind everyone that no-one managed to prove that breaking
RSA is as hard as factoring (cf. ``Breaking RSA may be easier than
factoring'' D.Boneh & R.Venkatesan, where they show that if you manage
to show that breaking RSA is algebraically as hard as factoring,
then you've got for free a factoring algorithm).
-- 
Berke Durak

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From sidney at sidney.com  Tue Feb 26 19:06:19 2002
From: sidney at sidney.com (Sidney Markowitz)
Date: 26 Feb 2002 16:06:19 -0800
Subject: Bernstein's fast factorization
In-Reply-To: <Pine.LNX.4.40.0202260832330.18597-100000@newbolt.sonic.net>
References: <Pine.LNX.4.40.0202260832330.18597-100000@newbolt.sonic.net>
Message-ID: <1014768380.1381.6.camel@siddhasana>

Someone on another mailing list pointed me to this posting by Dan
Bernstein on sci.crypt newsgroup:

http://groups.google.com/groups?hl=en&selm=2002Jan1608.53.39.5497%40cr.yp.to

[begin quote]

 From: D. J. Bernstein (djb at cr.yp.to)
 Subject: Re: Strength of PGP vs SSL
 Newsgroups: comp.security.pgp.discuss, sci.crypt, alt.security.pgp
 Date: 2002-01-16 01:00:11 PST

Protecting against the http://cr.yp.to/papers.html#nfscircuit speedup
means switching from n-bit keys to f(n)-bit keys. I'd like to emphasize
that, at this point, very little is known about the function f. It's
clear that f(n) is approximately (3.009...)n for _very large_ sizes n,
but I don't know whether f(n) is larger than n for _useful_ sizes n.

I'd also like to emphasize that special-purpose hardware is useful for
much more than factorization. In fact, it's much easier to reduce cost
this way for secret-key cryptanalysis or elliptic-curve discrete log
than for factorization.

[end quote]

 -- sidney



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Tue Feb 26 19:23:20 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 26 Feb 2002 19:23:20 -0500
Subject: Can the World Be Copyrighted?
Message-ID: <p05100306b8a1d748ae0f@[10.0.1.2]>

http://www.wired.com/news/print/0,1294,50658,00.html



Can the World Be Copyrighted?
By Brad King

2:00 a.m. Feb. 26, 2002 PST
Two treaties taking effect this spring would expand the reach of
controversial American legislation designed to regulate the Internet.

The World Intellectual Property Organization, an international body of
government representatives that globalizes laws, announced new guidelines
to crack down on digital piracy. The WIPO Copyright Treaty and the WIPO
Performance and Phonograms Treaty, which go into effect over the next three
months, extend copyright protection to computer programs, movies and music.



The treaties, hammered out in 1996, give a general framework for countries
to develop standard copyright laws.

However, it took several years for each to be ratified by 30 countries, the
minimum required before they can formally take effect. In the interim, the
agreements became the basis for America's Digital Millennium Copyright Act,
the first legislation designed to protect intellectual property on the
Internet.

Several watchdog organizations believe the DMCA, which domestic media
companies touted as the treaties' best practical application, give media
conglomerates and copyright holders too much control over digital
distribution.

The Electronic Frontier Foundation's (EFF) primary beef with the DMCA is
the legalization of rights management that gives copyright holders the
ability to dictate how people can listen, read and watch digital files. Two
prominent legal disputes drew the battle lines between the watchdog
organization and media companies.

2600 Magazine, a hacker publication, was barred from posting links to Jon
Johansen's DeCSS decryption application, which allows computer users to
watch DVDs on their PCs. The software breaks the digital security on the
disks, an act that violates the DMCA's anti-circumvention provisions.
Johansen, a Norwegian teenager, was charged with violating his country's
copyright laws and faces two years in prison.

Russian programmer Dimitri Sklyarov faced 25 years in prison after being
arrested in Las Vegas last July. He was released six months later after
being charged with distributing software that broke the copy protection on
electronic books, an act that violated America's DMCA but not his own
country's laws.

The EFF has fought to dismantle the DMCA and now the group is taking the
fight abroad, said Fred von Lohmann, EFF senior staff attorney.

"There are some people that argue that American laws were already compliant
with that law," von Lohmann said. "If you need to crack copy protected
work, you need to make a copy of it first and those reproduction rights
were already protected. But (DMCA author) Bruce Lehman and the other folks
expanded the copyright owner's protections to make the U.S. the banner
carrier for intellectual property.

"The DMCA satisfies the WTC treaty and then goes way beyond its scope. The
U.S. actually adopted the DMCA long before we were required to by
international law and now we're going overseas and telling people they need
to enact a DMCA-like law."

The EFF hopes to head off legislation in other countries since the treaties
offer a general framework that individual countries use to craft national
laws. The EFF has teamed with Electronic Frontier Canada, filed comments in
New Zealand, and worked with England's Eurorights.org as well as with
German groups.

Though 30 countries ratified the treaty, some of the world's biggest
economies are not on board. The European Union (comprising 15 countries,
including Germany and Italy) Japan and China haven't agreed to adopt the
framework.

The large, international, media companies, however, urge that the treaties
not only be ratified but also enforced.

Companies, such as Japan's Sony and Germany's Bertelsmann, have a growing
concern with the international flavor that these lawsuits have taken, said
Neil Turkewitz, the Recording Industry Association of America's executive
vice president and the music industry's representation at the WIPO
gathering in Geneva six years ago.

"Right now, copyright is national," Turkewitz said. "There is no such thing
as international copyright law. It's a little oversimplified, but these
treaties help harmonize the laws and the protections as much as possible.
It will take away the reasons for these companies to be moving around
because there will be a consistent level. The Internet is only as strong as
its weakest link."

Sklyarov wasn't arrested until he came to America, but that could change if
Russia adopts the two treaties. Then, copyright organizations in that
country could go after a programmer like Sklyarov.

The agreements would also make it easier to hunt down country hoppers such
as Niklas Zennstrom, the Dutch entrepreneur who licensed decentralized,
file-trading software to United States companies and later sold his company
Kazaa to an Australian investment firm.

Zennstrom faces separate lawsuits in the Netherlands and the United States
that were brought by national music copyright organizations. The
Buma/Stemra, a Dutch copyright watchdog organization, is suing Kazaa for
distributing a software application that allows people to connect to a
file-trading network. In its suit, the RIAA named Consumer Empowerment, the
licensing arm of Zennstrom's company, for selling the software to American
companies.

The reason these treaties need to be enacted, Turkewitz said, is that cases
such as these leave U.S. and Dutch copyright holders with little recourse.
The problem was exacerbated in January when Zennstrom sold Kazaa to Sharman
Networks Limited, a small privately held Australian company.

The new investors remain quiet, making it difficult for authorities to
track them down. However, Internet users still downloaded 2.2 million
applications through Kazaa last week, making it the leading file-trading
service.

That leaves copyright holders trying to coordinate lawsuits against at
least five companies in three countries.

This is a serious problem for record companies that claim piracy caused a
massive decline in album shipments last year, costing the major labels $600
million in sales. The explosive growth of peer-to-peer services and the
increase in CD-burning were the main culprits, said RIAA CEO Hilary Rosen.

"This past year was a difficult year in the recording industry, and there
is no simple explanation of the decrease in sales," Rosen said. "The
economy was slow and 9/11 interrupted the fourth quarter plans, but a large
factor contributing to the decrease in overall shipments last year is
online piracy and CD burning."

The problem looms much larger outside of America, where the industry
estimates physical piracy siphons off between $2 and $4 billion each year.
The advent of new technology is expected to increase that figure, Rosen
said.

Hollywood studios and the developers of video games and software are
expected to support the treaties as well.

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From bram at gawth.com  Tue Feb 26 19:49:30 2002
From: bram at gawth.com (Bram Cohen)
Date: Tue, 26 Feb 2002 16:49:30 -0800 (PST)
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
In-Reply-To: <v04210107b8a140c9e530@[192.168.0.2]>
Message-ID: <Pine.LNX.4.21.0202261425380.748-100000@ultra.gawth.com>

Arnold G. Reinhold wrote:

> At 11:49 AM -0800 2/25/02, bear wrote:
> >...
> >The "secure forever" level of difficulty that we used to believe
> >we got from 2kbit keys in RSA is apparently a property of 6kbit
> >keys and higher, barring further highly-unexpected discoveries.
> 
> Highly-unexpected?   All of public key cryptography is build on 
> unproven mathematical assumptions. Why should this be the last 
> breakthrough? If you plot the curve of what key length was considered 
> long enough as a function of time, it doesn't look very good.

Indeed, the only PK primitive I *really* trust is secure hash based
signatures -

http://bitconjurer.org/CheapSignaturesBeta.py

Going one step below that, most of the practical breaks we've had have
been from protocol screwups rather than key length problems, and I've
never seen a list purporting to be definitive of all the gotchas in RSA,
so the only fancy math primitive I feel confident to design a protocol
with is diffie-hellman.

So there you have it - the only really confidence-inspiring piece of
public key cryptography was the first one ever invented.

-Bram Cohen

"Markets can remain irrational longer than you can remain solvent"
                                        -- John Maynard Keynes


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Wed Feb 27 01:31:13 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 27 Feb 2002 01:31:13 -0500
Subject: FC: David Chaum's new project: Voting booths with secure receipts
Message-ID: <p05100314b8a22d92f400@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Tue, 26 Feb 2002 23:49:25 -0500
To: politech at politechbot.com
From: Declan McCullagh <declan at well.com>
Subject: FC: David Chaum's new project: Voting booths with secure receipts
Cc: david at surevote.com
Sender: owner-politech at politechbot.com
Reply-To: declan at well.com

[David Chaum is a remarkable fellow who pioneered digital cash. He's
recently been working on secure voting projects. See www.chaum.com and
Steven Levy's _Crypto_ book. --Declan]

---

Date: Fri, 22 Feb 2002 15:36:24 -0800
To: Declan McCullagh <declan at well.com>
From: David Chaum <david at surevote.com>
Subject: Breakthrough allows first receipts from voting booths!

FOR IMMEDIATE  RELEASE
Breakthrough allows receipts from voting booths:
First-ever legal receipts are surprisingly powerful
-- and may be just in time!

Los Angles, CA - Receipts showing exactly who you voted for, just what
people want and expect these days, are generally outlawed to protect
against vote selling and other abuses; a scientist has, however, come up
with the first receipt that cannot be used for any such abuse and yet can
ensure that your vote is actually included in the final tally.
    The new type of receipt, which can be printed by a modified version of
familiar receipt printers, contains your vote -- but in a coded form. You
can read it clearly in the booth, when it is still printed on two layers.
When the layers are separated, either one you choose to take has the vote
information you saw coded in it, but it cannot be read (except by computers
run by election officials).
    When the votes have to be added up for the final tally, the actual
receipts posted on an official public website are the input to the process.
The results of the process are then subject to a public audit. A lotto-like
draw selects which items must be decrypted, but never enough to compromise
privacy. Anyone with a pc can then check all the decryptions published on
the website and thereby verify that the final tally must be correct. The
audit is so strong that it cannot be fooled by breaking any code or
malicious software running on voting machines.
    The cryptographer, Dr. David Chaum, known for inventing eCash and his
pioneering company DigiCash, who came up with the receipt system said "The
more you look into how elections are actually run, even in this country,
the clearer the gap becomes between the way it is done and what we could
and really should be doing". Chaum also said "Today's trusted black-box
mentality has led to very high costs, meaning computerized voting mainly
for rich counties, an utter lack of real control and no way to re-deploy
the hardware for schools and libraries."
    At a time when the House has passed the first ever federal subsidy, at
$2.65b, and a similar bill is on the Senate floor with a $3.5b price tag,
one has to wonder: Will receipts and other new solutions have a chance, or
will the subsides backfire and put currently-certified computerized systems
in place on such a scale that major change will be a very long way off?
There is a complex interlocking of state and federal laws, agencies, and
quasi-governmental bodies that has erected a set of design specifications
and time-consuming steps that only new systems must navigate, first at the
federal level and then for most states separately. "When this was all first
set up more than a decade ago" Chaum quipped, "the rationale was to keep
unscrupulous vendors out, now it may just keep innovation out."

Contact: David Chaum, SureVote:
(818) 512-1024 (cellular/voicemail) david at survote.com
Jim Dolbear, Larkin Associates:
(310) 621-3580 (cellular/voicemail) jim at larkin.com




-------------------------------------------------------------------------
POLITECH -- Declan McCullagh's politics and technology mailing list
You may redistribute this message freely if you include this notice.
Declan McCullagh's photographs are at http://www.mccullagh.org/
To subscribe to Politech: http://www.politechbot.com/info/subscribe.html
This message is archived at http://www.politechbot.com/
-------------------------------------------------------------------------

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From shamrock at cypherpunks.to  Wed Feb 27 03:22:27 2002
From: shamrock at cypherpunks.to (Lucky Green)
Date: Wed, 27 Feb 2002 00:22:27 -0800
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
References: <000c01c1be3a$a3582cd0$16c89c8d@PHZ>
Message-ID: <013801c1bf67$e490b4f0$b83a080a@LUCKYVAIO>

Philip,
If we can at all fit it into the schedule, IFCA will attempt to offer a
colloquium on this topic at FC. Based on the countless calls inquiring about
this issue that I received just in the last few days, the customers of
financial cryptography are quite concerned about the Bernstein paper, albeit
the paper raises a number of open issues that still would need to be
investigated before one should assert that the sky is falling.

See you all at FC,

--Lucky, IFCA President

----- Original Message -----
From: "Phillip H. Zakas" <pzakas at toucancapital.com>
To: "'bear'" <bear at sonic.net>
Cc: "'Eugene Leitl'" <Eugene.Leitl at lrz.uni-muenchen.de>; "'Cryptography
List'" <cryptography at wasabisystems.com>
Sent: Monday, February 25, 2002 12:25 PM
Subject: RE: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)


> > -----Original Message-----
> > From: bear [mailto:bear at sonic.net]
> > Sent: Monday, February 25, 2002 2:49 PM
> >
> > On Thu, 21 Feb 2002, Phillip H. Zakas wrote:
> >
> > >> >On Tue, 5 Feb 2002, Eugene Leitl wrote:
> >
> > >> >But at Crypto last August, Dan Bernstein announced a new design
> for a
> > >> >machine dedicated to NFS using asymptotically fast algorithms and
> > >> >optimising memory, CPU power and amount of parallelism to minimize
> > >>
> > > Bear Responds:
> > >> I really want to read this paper; if we don't get to see the
> > >> actual mathematics, claims like this look incredibly like
> > >> someone is spreading FUD. Is it available anywhere?
> > >>
> > >
> > >The paper is located here: http://cr.yp.to/papers.html
> > >I've not evaluated yet but I'm interested in hearing if he received
> his
> > >grant to try it out.
> >
> > Holy shit.  The math works.  Bernstein has found ways of
> > using additional hardware to eliminate redundancies and
> > inefficiencies which appear in any linear implementation of the
> > Number Field Sieve.  We just never noticed that they were
> > inefficiencies and redundancies because we kept thinking in
> > terms of linear implementations.  This is probably the biggest
> > news in crypto in the last decade.  I'm astonished that it
> > hasn't been louder.
>
> It does seem doable and for not very much money. Is anyone attending the
> Intl. Financial Cryptography Association meeting in Bermuda from March
> 11-15th?  Perhaps we could arrange an informal get-together for this
> list.
> Phillip
>
>
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
majordomo at wasabisystems.com
>


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From shamrock at cypherpunks.to  Wed Feb 27 03:50:27 2002
From: shamrock at cypherpunks.to (Lucky Green)
Date: Wed, 27 Feb 2002 00:50:27 -0800
Subject: theory: unconditional security
References: <E16cD6k-00005i-00@bowl.fysh.org> <3.0.5.32.20020219091841.01ce46d0@localhost>
Message-ID: <01e301c1bf6b$cdb96610$b83a080a@LUCKYVAIO>

Carl wrote:
> I suspect you find little written about OTP work because people have
> always assumed the keys were impractical to distribute, store and
> use.

While distribution of OTP's has become feasible amongst tightly-knit groups
of non-governmental actors, the rate at which OTP's can be generated has
fallen behind the rate at which data needs to be communicated between the
nodes. To give an example, creating  OTP's  to encrypt messages along the
lines of "the attack will take place at dawn on Thursday" was easy with WWII
technology and is even easier now. However, the sheer volume of data
transmitted between even small nodes today requires vastly larger OTP's than
was required for military or diplomatic communications in the past.

I am not aware of any RNG design in the open literature that would even come
close to generating the sheer volume of random numbers required by current
civilian communication patterns. I trust that I don't need to elucidate on
this list as to why a "solution" that would require the sender to limit the
use of OTPs to sending critical data while other data would be encrypted
using a different system will invariably lead to COMSEC failures.

--Lucky




---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From horns at ipjur.com  Wed Feb 27 06:24:28 2002
From: horns at ipjur.com (Axel H Horns)
Date: Wed, 27 Feb 2002 12:24:28 +0100
Subject: [FYI] Encryption in Company Networks Foiled  
Message-ID: <3C7CCFFC.24863.ACE1B@localhost>

http://www.heise.de/english/newsticker/data/anw-26.02.02-007/

-------------------------------- CUT ---------------------------------

Encryption in Company Networks Foiled  

The encrypting of e-mails in company networks is foiled if it is done 
in a Microsoft Exchange/Outlook 9x/200x environment. In a POP3/IMAP4 
environment this is not the case. In answer to a question by heise 
online Microsoft confirmed that appended files encrypted with crypto 
plug-ins are transmitted in an unencrypted form from client to server 
even when the encryption function of the plug-in has been activated.  

[...]  

-------------------------------- CUT ---------------------------------



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From ptrei at rsasecurity.com  Wed Feb 27 09:52:23 2002
From: ptrei at rsasecurity.com (Trei, Peter)
Date: Wed, 27 Feb 2002 09:52:23 -0500
Subject: "Cloak", or Cloaca? :-)
Message-ID: <F504A8CEE925D411AF4A00508B8BE90A01E90C70@exna07.securitydynamics.com>

> Ben Laurie[SMTP:ben at algroup.co.uk]
> 
> 
> Keyring and Strip are both programs that provide secure DBs on Palms.
> Keyring, at least, is free and open source.
> 
> However, since Palms have no MMU, there's no security against hostile
> other apps, which makes them pretty useless devices for this kind of
> purpose.
> 
I'm coming into this a bit late, but the security situation on PalmOS is not
quite as dire as you make out (at least thru OS 3.5, maybe later). The
reason
is that the OS is single-threaded, and does not have preemptive
multitasking.
The OS sends the current app a message, saying, essentially 'Shut down
now and let something else happen'. The app can take it's sweet time about
this, and delay things long enough to zeroize or encrypt any sensitive data.

Peter Trei

> The right answer, IMO, is EROS on an MMUed handheld device (not sure
> about the biometric aspect - as I've stated at tedious length before, I
> like my appendages and don't want to give people incentive to steal
> them), such as that thing that runs Linux whose name temporarily escapes
> me, or the new Sharp gadget. Or a Jornada if they ever make one small
> enough.
> We have the technology. All we need is someone to finance it.
> Cheers,
> Ben.
> 
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From bear at sonic.net  Wed Feb 27 18:40:52 2002
From: bear at sonic.net (bear)
Date: Wed, 27 Feb 2002 15:40:52 -0800 (PST)
Subject: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
In-Reply-To: <013801c1bf67$e490b4f0$b83a080a@LUCKYVAIO>
Message-ID: <Pine.LNX.4.40.0202271533580.26547-100000@newbolt.sonic.net>



On Wed, 27 Feb 2002, Lucky Green wrote:

>Philip,
>If we can at all fit it into the schedule, IFCA will attempt to offer a
>colloquium on this topic at FC. Based on the countless calls inquiring about
>this issue that I received just in the last few days, the customers of
>financial cryptography are quite concerned about the Bernstein paper, albeit
>the paper raises a number of open issues that still would need to be
>investigated before one should assert that the sky is falling.
>
>See you all at FC,
>
>--Lucky, IFCA President

Hmmm.  According to Bernstein,  It's better and worse than
it first appeared.  On the one hand, the "o(1)" term may
be quite large and cancel much of the speedup for keys of
practical size, and even with reduced costs, that's still
a lot of single-purpose hardware to build for a practical
keysize.  On the other hand, RSA is not the only system
affected.  The technique may work on Elliptic Curve systems
as well. Which of these sides is "better" and which "worse"
is something that you will have to work out depending on
your own perspective.

				Bear




---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Wed Feb 27 20:49:32 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 27 Feb 2002 20:49:32 -0500
Subject: What's going on with factorization
Message-ID: <p05100377b8a33d1fd123@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: 28 Feb 2002 01:33:48 -0000
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <djb at cr.yp.to>
To: fork at xent.com
Subject: What's going on with factorization
Sender: fork-admin at xent.com
List-Id: Friends of Rohit Khare <fork.xent.com>

1. It has been widely known since the 1970s that special-purpose
hardware has a smaller cost _exponent_ than traditional architectures
for many interesting computations. (Certainly not for all computations:
consider, for example, computing the nth iterate of a secure hash, for
large n.)

Improvements in _exponent_ go far beyond saying ``Of course you can get
an improvement from special-purpose hardware.'' The speedup grows with
the problem size.

2. It has been widely known since 1994 (van Oorschot and Wiener) how to
build fast parallel special-purpose hardware for generic, and nearly
generic, discrete-log computations. Current elliptic-curve discrete-log
computations are nearly generic discrete-log computations.

My paper doesn't have any effect on the cost of elliptic-curve
discrete-log computations.

3. What my paper shows is that the number field sieve can be done with
very little memory per processor and a surprisingly small (though still
quite noticeable) amount of work per processor, including communication
costs. Consequently special-purpose hardware for the number field sieve
has a smaller cost exponent than traditional architectures. The new cost
exponent is within 4% of the obvious lower bound.

The conventional wisdom was that the number field sieve required a large
chunk of memory per processor (many megabytes for recent factorizations,
much more for future factorizations), and that communication with memory
was a bottleneck, so special-purpose hardware wouldn't help much. The
Georgia Cracker and TWINKLE designs didn't change the cost exponent.

4. At this point, nobody knows what the cost of this computation will be
for 1024-bit or 1536-bit or 2048-bit factorizations. All that is known
is the cost exponent.

Let's say the new machine handles f(b)-bit keys in the same time that
previous machines handled b-bit keys. It is known that f(b) is slightly
larger than 3b for _very large_ values of b. It is, however, not known
how close f(512) is to 1536. It is not even known whether f(512) is
larger than 512.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago


http://xent.com/mailman/listinfo/fork

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Wed Feb 27 20:23:33 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 27 Feb 2002 20:23:33 -0500
Subject: IP: Tech CEOs oppose SSSCA, tell Hollywood to try 	"market
 solutions"
Message-ID: <p05100371b8a33706625e@[10.0.1.2]>


--- begin forwarded text


Status:  U
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Wed, 27 Feb 2002 18:01:25 -0500
Subject: IP: Tech CEOs oppose SSSCA, tell Hollywood to try
	"market solutions"
From: Dave Farber <dave at farber.net>
To: ip <ip-sub-1 at majordomo.pobox.com>
Sender: owner-ip-sub-1 at admin.listbox.com
Reply-To: farber at cis.upenn.edu

"

http://www.politechbot.com/p-03195.html


Date: Wed, 27 Feb 2002 16:49:26 -0500
From: Declan McCullagh <declan at well.com>
Subject: FC: Tech CEOs oppose SSSCA, tell Hollywood to try "market
solutions"

Politech archive on Sen. Hollings' SSSCA:
http://www.politechbot.com/cgi-bin/politech.cgi?name=sssca

Witness list for Thursday's hearing:
http://www.politechbot.com/docs/hollings.sssca.hearing.022602.html

Draft text of the SSSCA:
http://www.politechbot.com/docs/hollings.090701.html

---

http://www.wired.com/news/politics/0,1283,50716,00.html

   High-Tech: U.S. Out of Hollywood
   By Declan McCullagh (declan at wired.com)

   11:49 a.m. Feb. 27, 2002 PST
   WASHINGTON -- America's largest and most powerful tech firms have
   agreed on one point: Keep Congress far away from digital content
   standards.

   In a 600-word letter sent to movie studios on Wednesday afternoon, the
   chief executives of IBM, Microsoft, Motorola, Intel and five other
   corporations said they were eager to work with Hollywood to find
   "technically feasible, cost effective solutions" for protecting
   entertainment delivered in digital form.

   The letter ostensibly went to the chief executives of Walt Disney, AOL
   Time Warner, MGM, Sony Pictures and so on -- but the real audience was
   Senate Commerce chairman Fritz Hollings (D-South Carolina), who is
   convening a hearing Thursday morning on whether the U.S. government
   should require that copy protection be embedded in nearly all PCs and
   consumer electronic devices.

   Hollings has drafted, but has not introduced, legislation called the
   Security Systems Standards and Certification Act (SSSCA). A draft of
   the SSSCA obtained by Wired News prohibits creating, selling or
   distributing "any interactive digital device that does not include and
   utilize certified security technologies."

   [...]

---

http://www.politechbot.com/docs/sssca.opponents.letter.022702.html

February 27, 2002

Michael Eisner                                  Sumner Redstone
Chairman & Chief Executive Officer              Chairman & Chief Executive
Offi
cer
The Walt Disney Company                         Viacom
500 South Buena Vista Street                    1515 Broadway
Burbank, CA 91521                               New York, NY 10036

Jean-Marie Messier                              Gerald M. Levin
Chairman & Chief Executive Officer              Chief Executive Officer
Vivendi Universal                               AOL Time Warner
375 Park Avenue                                 75 Rockefeller Plaza
New York, NY 10152-0192                         New York, NY 10019

Alex Yemenidjian                                John Calley
Chairman & Chief Executive Officer              Chairman & Chief Executive
Offi
cer
Metro-Goldwyn-Mayer, Inc.                       Sony Pictures Entertainment
2500 Broadway Street                            10202 W. Washington
Boulevard
Santa Monica, CA 90404                          Culver City, CA 90232

K. Rupert Murdoch
Chairman & Chief Executive Officer
News Corporation
1211 Avenue of Americas, 3rd Floor
New York, NY 10036


Dear Sirs:

We write to you to urge inter-industry cooperation to ensure that
digital content can be distributed to consumers efficiently through a
variety of means.  Each of our companies is in the business of
developing the hardware and software that will make e-commerce thrive.
Constant access to information, through comprehensive broadband
deployment and availability, we expect will in time be widely
available.  It is clear that your companies' entertainment products
will form an important part of a thriving on-line economy.  Digital
television is also an important development, and we expect it will
soon become widely available.

Business models are only beginning to be developed for supplying
consumers' on-demand entertainment.  We recognize the critical
importance of effective anti-piracy tools in this changing market
environment, and that the absence of such tools may affect the
development of new product offerings.  To address this concern, our
companies have worked diligently, voluntarily and cooperatively with
producers of entertainment content, as well as consumer electronics
companies, to develop systems that will foster the legitimate
distribution of digital content.  The Copy Protection Technology
Working Group (CPTWG) and the Moving Picture Experts Group (MPEG) have
been highly productive fora for developing consensus among the many
disparate businesses that must work together to build a robust
infrastructure for the secure dissemination of digital content. We
have found these voluntary multi-industry standards setting efforts to
be optimally effective in reaching workable market solutions.

For instance, these voluntary groups have successfully formed
consensus on key technologies, making it possible to distribute movies
in protected environments such as in DVD format, and developing
effective technologies for protecting content distributed over cable
and satellite.  An inter-industry group is now working diligently
within CPTWG to develop a consensus on a means to limit the unlawful
redistribution of digital content delivered through unprotected
over-the-air broadcast channels. This task force (the Broadcast
Protection Discussion Group, or BPDG) is working to identify the
workable technical and business solutions.

The information technology industry is committed to doing its part in
the shared multi-industry development and deployment of effective
solutions for the protection of digital content through a variety of
distribution channels and an array of settings. We understand this
will be an ongoing undertaking, requiring responses as distribution
methods and technology evolve and progress.  Our goal is to work with
you in a consensus-based and cooperative fashion. We urge you to work
with us to find technically feasible, cost effective solutions.

We look forward to a fruitful collaboration to achieve our common goal
of providing consumers with new and exciting digital entertainment
products.

Sincerely,

Michael D. Capellas
Chairman and CEO
Compaq Computer Corporation

Michael S. Dell
Chairman of the Board and CEO
Dell

Louis V. Gerstner, Jr.
Chairman of the Board and CEO
IBM Corporation

Craig Barrett
Chief Executive Officer
Intel Corporation

Steve Bennett
President and CEO
Intuit Inc.

Steven A. Ballmer
CEO
Microsoft Corporation

Christopher B. Galvin
Chairman of the Board and CEO
Motorola

John S. Chen
Chairman, CEO and President
Sybase, Inc.

Lawrence A. Weinbach
Chairman of the Board and CEO
Unisys Corporation


Cc:  Jack Valenti




-------------------------------------------------------------------------
POLITECH -- Declan McCullagh's politics and technology mailing list
You may redistribute this message freely if you include this notice.
Declan McCullagh's photographs are at http://www.mccullagh.org/
To subscribe to Politech: http://www.politechbot.com/info/subscribe.html
This message is archived at http://www.politechbot.com/
-------------------------------------------------------------------------


------ End of Forwarded Message

For archives see:
http://www.interesting-people.org/archives/interesting-people/

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Wed Feb 27 21:40:47 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 27 Feb 2002 21:40:47 -0500
Subject: Duncan Frissell: 20 Questions to Ask National ID Supporters
Message-ID: <p0510037cb8a348be8bff@[10.0.1.2]>

 
http://www.sierratimes.com/02/02/27/eddf022702.htm



20 Questions to Ask National ID Supporters by Duncan Frissell: 02.27.02
------------------------------------------------------------------------

Here are some questions to ask supporters of a modern "enhanced" ID system
for the United States.

1. Under your system, can one's ID fail online verification for any reasons
other than authentication failure (ID is not in the database or biometrics
don't match) or expiration? Can a valid ID be cancelled for any reason
(beyond expiration)?

2. Does your ID system have protections to prevent legislators and
bureaucrats from adding other conditions to ID use? For example blocking ID
authentication for failure to pay fines, failure to pay taxes, criminal
arrest or conviction, etc.? The drivers licence system currently allows
suspension for many such acts or omissions.

3. Will your ID system supply risk assessment services in addition to ID
verification services. That is, will it provide a "credit score", "fraud
score" or "criminal risk score" in addition to ID. What information beyond
ID validity will the system supply to users.

4. If your system supplies risk assessment services, will it accept foreign
government criminal, civil, or administrative records and apply them to the
IDs of US citizens? If so, how can these records be challenged, how do you
assure that the alleged acts would be crimes or civil wrongs if committed
in the US (e.g. hate speech), and how do you deal with differing due
process standards in different nations?

5. Should government subsidize wealthy financial corporations by supplying
them with free or low-cost ID authentication and risk assessment services?

6. How can people challenge the accuracy of these assessments?

7. Will one's ID be the sole ID accepted for any goods or services? If so,
which goods or services?

8. The Supreme Court has repeatedly ruled that anonymity and refusal to
identify oneself to the police are constitutionally protected actions. Do
you favor a constitutional amendment to reverse these court decisions?

9. Four million US citizens are not residents of the US. Since they cannot
be denied entry to the US and do not require visas to enter the US, what ID
are they supposed to use in the US? They currently use a US passport, a
foreign drivers license, and domestic or foreign credit cards.

10. Do you favor the end to the visa waiver program which allows citizens
of many OECD countries to enter the US without visas? If so, what ID are
they supposed to use in the US? They currently use a foreign passport, a
foreign drivers license, and domestic or foreign credit cards.

11. Do you favor the abrogation of the North American Free Trade Agreement
and other treaties which allow citizens of other North American countries
and some Caribbean countries to enter the US without passports or visas? If
so, what ID are they supposed to use in the US? They currently use a
foreign passport, a foreign drivers license, and domestic or foreign credit
cards.

12. Have you warned the American people that once these passport and/or
visa waiver programs are cancelled, foreign countries are likely to require
passports and visas to enter their countries making international travel
(including Canadian, Mexican, and Caribbean vacations) much more difficult
to prepare for?

13. Passport design is not under US control but under the control of the
International Civil Aviation Organization (ICAO). Do you favor the
replacement of the current passport with an "enhanced" identity document?
How are poor counties supposed to afford the infrastructure necessary to
support high-tech online-verifiable ID documents?

14. If your ID system is based on the state ID system, will any
non-residents of the individual states be able to receive the new state IDs?

15. Do you favor cleaning up the existing ID system? Will you require all
Americans to reverify their identity to receive the "enhanced" ID? If so,
what documents or other proof of ID will they have to present? For example,
will entries in a family bible be acceptable as proof of identity?

16. What provision have you made for persons who present themselves for
identification but who have no (or inadequate) identification documents and
whose biometric identifiers are not yet in the system? [The current system
allows the testimony of others to establish identity for such purposes as
passport issuance].

17. Do you favor requiring address registration (the requirement that all
residents to register their address with police or local government) as
part of your new ID system?

18. Will the homeless be able to obtain ID without a fixed address?

19. What do you envision happening to the millions of US residents who fail
to qualify for the new IDs (or whose IDS are cancelled) or who refuse to
apply for them for religious or political reasons?

20. Does your system envision any controls on false IDs intentionally
issued by foreign (or US) governments for intelligence or witness
protection purposes?



Permission to reprint/republish granted, as long as you include the name of
our site, the author, and our URL. www.SierraTimes.com All Sierra Times
news reports, and all editorials are ? 2002 SierraTimes.com (unless
otherwise noted)
------------------------------------------------------------------------
SierraTimes.com? A Subsidiary of J.J. Johnson Enterprises, Inc.

 


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From reinhold at world.std.com  Wed Feb 27 21:22:47 2002
From: reinhold at world.std.com (Arnold G. Reinhold)
Date: Wed, 27 Feb 2002 21:22:47 -0500
Subject: theory: unconditional security
In-Reply-To: <01e301c1bf6b$cdb96610$b83a080a@LUCKYVAIO>
References: <E16cD6k-00005i-00@bowl.fysh.org>
 <3.0.5.32.20020219091841.01ce46d0@localhost>
 <01e301c1bf6b$cdb96610$b83a080a@LUCKYVAIO>
Message-ID: <v0421010ab8a33ea1badf@[192.168.0.2]>

At 12:50 AM -0800 2/27/02, Lucky Green wrote:
>Carl wrote:
>> I suspect you find little written about OTP work because people have
>> always assumed the keys were impractical to distribute, store and
>> use.
>
>While distribution of OTP's has become feasible amongst tightly-knit groups
>of non-governmental actors, the rate at which OTP's can be generated has
>fallen behind the rate at which data needs to be communicated between the
>nodes. To give an example, creating  OTP's  to encrypt messages along the
>lines of "the attack will take place at dawn on Thursday" was easy with WWII
>technology and is even easier now. However, the sheer volume of data
>transmitted between even small nodes today requires vastly larger OTP's than
>was required for military or diplomatic communications in the past.
>
>I am not aware of any RNG design in the open literature that would even come
>close to generating the sheer volume of random numbers required by current
>civilian communication patterns. I trust that I don't need to elucidate on
>this list as to why a "solution" that would require the sender to limit the
>use of OTPs to sending critical data while other data would be encrypted
>using a different system will invariably lead to COMSEC failures.
>

I don't think that's quite fair. Pretty much any organization that 
wishes to protect sensitive information needs to be able to segregate 
it from other data that is not protected or enjoys a lower level of 
protection. Most PGP users only encrypt critical data.  And given the 
best security system imaginable, there will be COMSEC failures due to 
human error (q.v. the John Deutch case).

Generating enough random information to fill a CD should take a few 
hours using a sound card and a hardware noise generator, running 
FIPS-140 tests along the way and whitening so as to assume only 3 or 
4 bits of entropy per digitization. That CD would be enough to 
protect all the text e-mail I'lI ever want to exchange with another 
person.  An unconditionally secure text link between two people could 
be considered useful.

I suspect a video input device connected to a TV set tuned to an 
empty channel would be copious enough for most uses, but some real 
world testing should be done. Unconditional security is sounding a 
lot better in the post-Bernstein era.


Arnold Reinhold





---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From Eugene.Leitl at lrz.uni-muenchen.de  Thu Feb 28 02:54:18 2002
From: Eugene.Leitl at lrz.uni-muenchen.de (Eugene Leitl)
Date: Thu, 28 Feb 2002 08:54:18 +0100 (MET)
Subject: Interesting new cipher patent
In-Reply-To: <3C7D8CD0.16A579C2@al-qaeda.com>
Message-ID: <Pine.SOL.4.44.0202280831460.23878-100000@sun4.lrz-muenchen.de>


A question: assuming, you have a class of random number generators with
lots of internal state. (Lots: like >>10^6 bits). Let's say the evolution
through state space of that generator is provably reversible (or nearly
reversible), and that the Hamiltonian of the system is stochastic (system
evolution is a randomwalk in state space). The result is a pseudorandom
number generator with a ridiculously long periode, and good randomness of
output, obviously. A simple cypher based on it would exchange the
pseudorandom generator state (the key) through a secure channel,
similiarly to a one time pad.

Can someone point me towards papers describing construction of above
generators? I'm thinking about reversible cellular automata (is Gutowitz
the only guy who did CA crypto?) or automata networks with changing
connection geometry (i.e. the connection is also encoded in the state and
changes with each iteration) with the number of total iterations estimated
from lightcone considerations.

Point of this:

* algorithmic construction of PRNGs with provable properties
* lots of internal state, hence bit leakage even for a lot of messages
  buys attacker little
* scalable (add more state as hardware improves)
* directly mappable to hardware, very good parallelism

Any pointers?


On Wed, 27 Feb 2002, Khoder bin Hakkin wrote:

> Cipher mixer with random number generator
>
>                                                        Abstract
>
> An encryption device has a random number generator whose output is
> combined by exclusive-or with plaintext input which has been encrypted
> by a first block cipher. The combined exclusive-or output is encrypted
> with a second block cipher mechanism which produces a second enciphered
> output. The output of the random number generator is also encrypted by a
> third block cipher mechanism which produces a third enciphered output.
> The first and second block cipher mechanisms differ from each other.
>
> United States Patent
> 6,351,539
> February 26, 2002
>

-- Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBMTO: N48 04'14.8'' E11 36'41.2'' http://www.leitl.org
57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Thu Feb 28 07:50:24 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 28 Feb 2002 07:50:24 -0500
Subject: NAI puts PGP into Maintenance
Message-ID: <p05100309b8a3d7ebdbd3@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Wed, 27 Feb 2002 15:28:17 -0800
From: "PGP" <nai at nai.rsc01.com>
Reply-To: "PGP" <pgp at nai.com>
Subject: Important Information regarding PGP Desktop/Wireless Encryption
Products
To: rah at ibuc.com

****************************************************************
[This message is brought to you as a subscriber to the Network
Associates or PGP websites. To unsubscribe, please follow
the instructions at the bottom of the page.]
****************************************************************


February 26, 2002

Dear Valued Customer,

Since October 11th of last year, we have been diligently searching to find
a suitable
buyer for the PGP Desktop/Wireless encryption products in order to provide
a strong
partner for our customers. This search has not resulted in an appropriate
buyer who will
continue to develop and support the products while providing value to existing
customers. Therefore, the decision has been made to place our PGP
Desktop/Wireless
encryption products in maintenance mode.

The support team at Network Associates will continue to honor all support
agreements
for existing PGP Desktop/Wireless customers until their date of
termination. However,
effective immediately Network Associates will cease new development on these
products, and not sell additional licenses, services and support
agreements. Once
again, we reiterate that we will continue to honor all technical support
agreements for
the entire duration of the contract.

The PGP technology and source code will remain under the control and
ownership of
Network Associates. Other products that utilize this encryption technology
will remain
a part of Network Associates? current product portfolio and they will
continue to be
developed in order to meet the security needs of both new and existing Network
Associates customers. These products currently include McAfee E-Business
Server,
McAfee Desktop Firewall and McAfee VPN Client.

We pledge to you our complete efforts to assist you through this
transition, and to
ensure that your experience as a customer remains positive. We continue to
focus on
delivering to you superior technology and product solutions to help you
meet your
business needs. Our customers are our most valuable asset, and we look
forward to
continuing to work in partnership with you in the future.



Best Regards,


Sandra England
Executive Vice President of
Strategic Business Development and Research




****************************************************************

This information update is available at no charge to all
registered users of Network Associates website.

 * To cancel this update, send us a reply with the words
unsubscribe yourname at yourdomain.com in the subject line with the
original message attached.

 * To change your email address, send us a reply with the words,
"change-address" in the subject line. In the body of the message
include your old and new email addresses with the original
message.

  Use the following format for email changes:

  OLD: enduser at olddomain.com
  NEW: Joseph_User at newdomain.com

****************************************************************

______________________________________________________________________
This message was sent by Network Associates, Inc. using Responsys Interact
(TM).

If you prefer not to receive future e-mail from Network Associates, Inc.:
    http://nai.rsc01.net/servlet/optout?gHpgJDVZBEkHoFpINJDJhtE0

To view our permission marketing policy:
    http://www.rsvp0.net

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From rah at shipwright.com  Thu Feb 28 09:48:24 2002
From: rah at shipwright.com (R. A. Hettinga)
Date: Thu, 28 Feb 2002 09:48:24 -0500
Subject: Recruiting Agents
Message-ID: <p0510032fb8a3f3925b19@[10.0.1.2]>


--- begin forwarded text


Status:  U
Date: Thu, 28 Feb 2002 08:43:36 -0800
To: cypherpunks at lne.com
From: John Young <jya at pipeline.com>
Subject: Recruiting Agents
Sender: owner-cypherpunks at lne.com

Dell's admission of vetting customer use of its
products on behalf of domestic and national security,
raises the issue of who else is doing that.

About ten days ago I got a telephone message from
a person who claims to work for a major ISP as a sysadmin.
This person had previously disclosed the ISP's cooperation
with federal authorities to run a nationwide surveillance
system from a central hub of the ISP, claiming that the
system was set up under a memorandum of understanding
when the ISP was bought by a foreign corporation. We've
published this allegation on Cryptome.

We returned the call and talked about twenty minutes with
the person, who said that surveillance of the Net is
increasing rapidly over what he had said earlier. Then
came a pitch that I get on board by vetting information
sent to Cryptome with federal authorities if I thought
there might be a threat to national security.

The pitch got intense.The person asked if I had criminal
background. I said no. Did I believe the US had enemies.
I said yes. Did I believe it was my responsibility to protect
the nation. I said maybe. Was it not wise to report threats
to the nation to authorities? I said no, it was wise to report
them to the public so it could protect itself.

But, he said, don't you think the threats should be checked
with the authorities first? No, I said, it is not for me to
decide what is a threat and what is not, that my task is to
make information available and let readers decide.

Wouldn't you like to boost your authority, he said, by having
it supported by official authority? I said no, that I did not
want authority, that such authority is widely available for
those who want it from responsible sources. Instead, I
said, what is needed is more information not filtered by
authorities or responsible sources.

Don't get me wrong, he said, I admire what you're doing
on Cryptome, and I wish I had your courage. Thanks, I
said.

Still, he said, I think it would be a good idea for you to
establish an ongoing relationship with the authorities
so you don't get in trouble. No, I said, that is definitely
not something I want to do, for if I did that it would
be a betrayal of Cryptome readers.

You know, he said, I'm very troubled by what my company
is doing, but I think in times of danger we all have to do
what we can to protect the nation, and I think you should
get in touch with the authorities to be sure information
you get is okay to publish. No, I said, that's not for me,
what is needed in times of danger is more information
about how to protect yourself, and in times of danger
authorities are often a threat as great as what they
warn about.

How can you be sure of that, he said, I think you need
to talk to the authorities to be sure you know what the
threats are and what you are doing is okay. No, thanks,
I said.

Someday, he said, I hope I have your courage, but now
I have to think about my job. Agreed, I said, you should
do nothing that will put you in danger, don't jeopardize
you job and your family.

However, he said, I want you to think very carefully about
arranging to check with the authorities about information
to be published on Cryptome. Look, I said, the authorities
have more than adequate means to keep track of information
going on Crypotme and they don't need my help.

But you need to protect yourself, don't you see, to be sure
that you are not entrapped by information sent to you
for that purpose. Agreed, I said, but we were told soon after
setting up Cryptome to expect entrapment efforts, so we
do, and the reason we don't claim authority is to be sure
readers know they have to protect themselves in the
same way we do.

But wouldn't you like to be protected by the authorities,
to advocate to your readers that they do the same? No,
I said, that is the role of authorities and responsible
publishers, not Cryptome.

-----

I think this conversation is like many going on around
the country, and shows how recruitment of agents is
being done. We'd like to publish such accounts, anonymized
or not.

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From weidai at eskimo.com  Thu Feb 28 19:01:21 2002
From: weidai at eskimo.com (Wei Dai)
Date: Thu, 28 Feb 2002 16:01:21 -0800
Subject: Bernstein's NFS machine
In-Reply-To: <ML6F6WUJ37313.127962963@frog.gilgamesh.org>; from FrogRemailer@bigfoot.com on Tue, Feb 26, 2002 at 02:04:16AM -0000
References: <ML6F6WUJ37313.127962963@frog.gilgamesh.org>
Message-ID: <20020228160120.C4245@eskimo.com>

I haven't checked all of the numbers, but I think Frog3's analysis is
largely correct. However, the two O(1)'s below should be replaced with
o(1)'s.

Very informally, think of O(1) as some constant, and o(1) as converging to
0. One possibly confusing thing about Berstein's paper is that in the
sentence "for a given cost, the number of digits of n has grown by a
factor of 3.0090581972... + o(1)", the o(1) is most likely negative for
practical key lengths.

On Tue, Feb 26, 2002 at 02:04:16AM -0000, Frog3 wrote:
> Analysis of Bernstein's NFS machine when applied to a 1024 bit RSA key
> See http://cr.yp.to/papers.html#nfscircuit.
> 
> We will ignore O(1) terms to get some ballpark concrete results.
> 
> The main parameter for a 1024 bit modulus size:
> L = 2^45.  (All powers of 2 are rounded to integers.)
> 
> The normal NFS would take time 2^86 and space 2^43 for this size.
> 
> Bernstein's NFS takes time 2^53 and space 2^36.
> 
> The speedup is (in part) by using ECM in parallel to find smooth numbers.
> Also the matrix reduction is done in parallel as well.
> 
> For the optimal design balancing these two parts, the numbers we are
> checking are of size 2^46.  We are checking for smoothness against a
> bound of 2^36.  We need to do two smoothness checks per element.
> 
> The parallel ECM machine has 2^36 simultaneous units each checking
> smoothness against a bound of 2^36.  Each will do 2^36 tests in time 2^36,
> for a total throughput of 2^71 in time 2^36.  Actually this is wrong;
> each test will take 2^18, which is counted as negligible, but in fact
> it makes the time be 2^54.  This part is hidden in an O(1) but it is a
> significant slowdown.
> 
> We need to do 2^89 tests at an estimated rate of 2^72 tests per 2^36
> time for an estimate of 2^53 time.  Applying the correction that ECM
> test time is not negligible gives us an estimate of 2^71 time.
> 
> The cost is the need to build a machine that can do 53 billion
> simultaneous, independent ECM factorizations for smoothness testing.
> It's not clear how amenable this would be to hardware implementation.
> 
> A time of 2^71 is considerably less threatening than 2^53.
> 
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com


From geer at world.std.com  Thu Feb 28 22:59:13 2002
From: geer at world.std.com (Dan Geer)
Date: Thu, 28 Feb 2002 22:59:13 -0500
Subject: KYC: new FinCEN rule on information sharing 
In-Reply-To: Your message of "Thu, 28 Feb 2002 09:15:06 EST."
             <p05100323b8a3ebde8bb6@[10.0.1.2]> 
Message-ID: <200203010359.WAA00605@world.std.com>


    
>   http://www.treas.gov/fincen/po1044.htm

For what it is worth, the apparent consensus view amongst U.S.
financial institutions is that if "T+1" clearence and "straight
through processing" (STP) are to become operational realities,
then authentication and authorization credentials must be ones
that cross corporate boundaries.  In other words, the know your
customer (KYC) regime will include federated electronic identity
management at the personal level.  The Bank for International
Settlements (BIS) has already weighed in on the concept of 
extending KYC from money-laundering protection alone to a broader
and more critical role in general banking industry risk management.
See, for an example, 

http://www.bis.org/publ/bcbs85.htm#pgtop = summary

http://www.bis.org/publ/bcbs85.pdf = full publication

--dan


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com