Cryptography-Digest Digest #824, Volume #8 Sat, 2 Jan 99 09:13:05 EST
Contents:
Re: Encryption Basics (Tim Redburn)
Re: Strange Code Floating About
Re: PGP Keys on Smartcard (or ring) ("William R. Bishop")
Re: PGP Keys on Smartcard (David A Molnar)
Re: Secure Credit Card Transactions (Ben Dehner)
TEA Algorithm (Ladislav Sedivy)
Re: Open source Crypto algorithms in Java (G. Rease Ball)
Re: PGP Keys on Smartcard (Peter Gutmann)
Re: How to deduce EXE header contents and other questions. (Nathan Kennedy)
ICSA Guide to Cryptography (CryptoBook)
Re: Session key establishment protocol with symmetric ciphers ("Lyal Collins")
Re: Make Fast Random Number Generator? (Robert Davies)
Re: Open source Crypto algorithms in Java (KloroX)
Re: OTP/FTP/MTP Question
Re: PGP Keys on Smartcard (Ian Goldberg)
Re: Encryption Basics ([EMAIL PROTECTED])
Re: Opinions on S/MIME (Arnoud "Galactus" Engelfriet)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Subject: Re: Encryption Basics
Date: Fri, 01 Jan 1999 23:15:30 GMT
On Sun, 20 Dec 1998 13:48:45 GMT, [EMAIL PROTECTED] wrote:
<snip>
> One such person
>helped set up a web page for me. So at least read a little bit
>before you shoot your mouth off and spread more lies. Or are you
>incapable of telling the truth.
>
<snip>
You said yourself that you would not agree with the contents
of the page that was created for you, and in fact it's contents are
still at best misleading .... well at least it's claims as to the
entropy of the S-Boxes (this is the only bit I have looked at in
detail).
To quote you from an earlier post (1998/12/02) .......
>> The main thing I looked at in that page is the graphs
>> I changed them to gifs for speed. I have not read all he
>> wrote since I knew I would disagree. I would remember the
>> word entropy. I never use words like that except when talking
>> about thermodynamcis. If I read that part I would have changed
>> it and I plan to leave the page mostly alone since the guy
>> was nice enough to talk me in to getting a web page.
Why do you still refer people to the page if you don't beleive it to
be correct ? If you can't correct it, then you should at least
remove the reference from your signature, to stop people wasting
their time reading and analysing it.
<snip>
>http://members.xoom.com/ecil/index.htm
<snip>
- Tim.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Strange Code Floating About
Date: 2 Jan 99 00:20:36 GMT
Mark Terka ([EMAIL PROTECTED]) wrote:
: I'm enclosing another poster's message. Anybody know what this might
: be, or is it just gibberish?
It's one of the "Hipcrime" messages, part of an attack on USENET that's
been going on for some time, but which has been shifting between different
newsgroups. Shades of the "poetry festival" that I encountered on Deja
News and mentioned a while back...
It is, apparently, just gibberish.
John Savard
------------------------------
From: "William R. Bishop" <[EMAIL PROTECTED]>
Subject: Re: PGP Keys on Smartcard (or ring)
Date: Fri, 01 Jan 1999 17:29:45 -0700
fred wrote:
>
> Hi there.
>
> I'm a PGP User on Windows NT and would prefer to
> keep my secret keys on a smartcard which would always
> physically reside with me.
>
> Does such a product exist? I would ideally like to think that
> my secret keys always remained on the card and that signing
> and digest creationn occured on the card. That way my keys
> couldn't be snaffled away by a miscreant program on my NT
> workstation.
>
> Has anyone done this or am I about to make my fortune?
>
> Thanks in advance,
> Gavin
Hi Gavin,
Absolutely! I might suggest that in place of the smart card
you try a Java Ring (Knuckletop Computing):
<http://www.java.sun.com/features/1998/03/rings.html>
<http://www.javaworld.com/javaworld/jw-04-1998/jw-04-javadev.html>
Smart card technology + Java:
<http://www.java.sun.com/javaone/javaone98/sessions/T800/>
<http://www.java.sun.com/features/1998/04/javacard.html>
You're less likely to lose the ring :-)
Best Regards,
Bill Bishop
--
Academy Award winning Digital Imaging Product Development consultant
William R. Bishop - [EMAIL PROTECTED] - http://pcisys.net/~wrb/
Anti-SPAM measure - remove NOSPAM from reply address
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: PGP Keys on Smartcard
Date: 2 Jan 1999 00:35:43 GMT
fred <[EMAIL PROTECTED]> wrote:
> Does such a product exist? I would ideally like to think that
> my secret keys always remained on the card and that signing
> and digest creationn occured on the card. That way my keys
> couldn't be snaffled away by a miscreant program on my NT
> workstation.
> Has anyone done this or am I about to make my fortune?
_Applied Cryptography_ contains a table showing the speed of various
algorithms in smart-card implementations. RSA is among those, so
apparently the chip exists.
I know that MIT's Media Lab has some kind of cryptographically aware
token, but I'm not sure if it performs encryption or simply contains
a copy of one's public key.
------------------------------
Date: Fri, 01 Jan 1999 19:23:49 -0600
From: Ben Dehner <[EMAIL PROTECTED]>
Subject: Re: Secure Credit Card Transactions
Steve Sampson wrote:
> How much money do you want to spend?
>
> Go to CCNow http://www.ccnow.com/
>
> People can order products from you, and not pay sales tax
> (CCNow is a Delaware company). No startup or monthly fees.
>
> @ 8% of each sale.
The bypasses the issue, since it lets the CCNow company handle all of the
transactions for you. You have to ask yourself, do you trust their security,
and
as Mr. Samspon asks, "how much do you want to spend?".
>
> Go to the Netscape Website
> http://merchant.netscape.com/netstore/servers/suitespot.html
>
> 1) Purchase the Suitespot Server (includes LDAP, etc).
> 2) Order an annual Server Certificate from Verisign.
>
> @ $4000 or so.
Been a while since I mucked with the Netscape stuff, but I don't think its this
much. Directory server (their LDAP server) is about $1000, the web server
is the same, and the Verisign key is about $500. I don't think that the
Directory
server is strictly necessary for this though. Just need the Enterprise server
and
the Verisign key. For a small site I think that their Fastrack server can
handle SSL.
However, this is only part of the picture. The SSL web server encrypts the
transfer
of credit card info from the user to the server; the next part of the picture is
processing the transaction. This is done using something like Cybercash (see
http://www.cybercash.com) or SecureBuy by AT&T (don't have a URL for that
one.) You'll have to look at their products if you want to know about security.
The
software these companies provide gives an interface with a bank somewhere to
handle transaction. (Cybercrash in particular is a pain to set up and
configure.)
Finally, there is the question of overall security -- even though the
information
may be passed via SSL, are the credit card numbers stored on a flat file or
in a database on the system, so how secure is the system.
Ben
>
> Benzbrood wrote in message <[EMAIL PROTECTED]>...
> >
> >I need the info, progs, urls, or whatever I need to make a web site with
> secure
> >transactions for an online store, subscriptions, etc. Please reply.
------------------------------
From: Ladislav Sedivy <[EMAIL PROTECTED]>
Subject: TEA Algorithm
Date: Fri, 01 Jan 1999 22:00:27 -0500
Anyone has done any tests or analysis on TEA (Tiny Encryption Agorithm)?
The docs. are at
http://www.cl.cam.ac.uk/ftp/papers/djw-rmn/djw-rmn-tea.html
--
Lac
------------------------------
From: [EMAIL PROTECTED] (G. Rease Ball)
Subject: Re: Open source Crypto algorithms in Java
Date: Sat, 02 Jan 1999 02:29:27 GMT
On Fri, 01 Jan 1999 11:21:43 GMT, [EMAIL PROTECTED] (KloroX)
wrote:
snip!
>>http://www.windsong.demon.co.uk/crypt.zip
>
>The link does not work...
Works now. Thanks
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: PGP Keys on Smartcard
Date: 2 Jan 1999 04:05:15 GMT
David A Molnar <[EMAIL PROTECTED]> writes:
>fred <[EMAIL PROTECTED]> wrote:
>> Does such a product exist? I would ideally like to think that
>> my secret keys always remained on the card and that signing
>> and digest creationn occured on the card. That way my keys
>> couldn't be snaffled away by a miscreant program on my NT
>> workstation.
>_Applied Cryptography_ contains a table showing the speed of various
>algorithms in smart-card implementations. RSA is among those, so
>apparently the chip exists.
>I know that MIT's Media Lab has some kind of cryptographically aware
>token, but I'm not sure if it performs encryption or simply contains
>a copy of one's public key.
There are many, many smart cards which do RSA. Most are quite expensive,
almost all are a royal pain to work with, and none of them handle
reasonable-size keys (typically they only do 512-1024 bits). You can find
links to smart card info and vendors on my crypto link farm,
http://www.cs.auckland.ac.nz/~pgut001/links.html, under "Smart cards".
Peter.
------------------------------
From: Nathan Kennedy <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.asm.x86
Subject: Re: How to deduce EXE header contents and other questions.
Date: 2 Jan 1999 04:27:10 GMT
[EMAIL PROTECTED] wrote:
> I am in need of a way to deduce at least 13 consecutive bytes (better if
> more) of a DOS EXE file, knowing only its exact size (in bytes). This is
> required for decrypting a ZIP file to which I had lost a password. Brute
> force and dictionary-based approaches are of no help (I use long, unguessable
> alphanumeric sequences) and I am using the "known-text" algorithm,
> implemented in a program found at:
>
> http://www.unix-ag.uni-kl.de/~conrad/krypto/pkcrack.html
>
> The author of the program and 2 other sources suggest that DOS EXE file
> headers can be used a a source of known plaintext to feed the algorithm. From
> the descriptions I have seen of these headers, some of the information is
> common to all such files. However, the rest of the header is not.
>
> Could I use another string of plaintext for the "attack", one that is not
> derived from the header of the EXE file (if it cannot be computed using only
> the size of the file)? Are there VERY COMMON sequences of at least 13 bytes
> that occur frequently in DOS executables?
>
> A sequence of 13 NULL bytes has been tried and returned no results.
Dear me, that's probably your best bet. Try 13 (decimal) $90 (hex)
characters. This corresponds to NOP, but still isn't likely. I actually
find it somewhat surprising... Most EXE's are bloated with LOTS of null
scratch space. If you know that this EXE was produced by a certain
compiler, they will almost always tag on an error handling routine with all
the standard error messages (yet another example of DOS binary bloat...
there's no perror function in the kernel). If you have any other
executable from the same source, try to find standard messages or a common
string in it. I can think of lots of code strings but none that would
necessarily occur in all executables that are 13 bytes. But if you can get
another executable from the same source, look for error messages and you'll
almost certainly be successful.
If it's C, try portions of the string "Null pointer assignment." I think
most DOS compilers put this in. I know that Borland by default does, but
the check can be turned off.
Nate
------------------------------
From: [EMAIL PROTECTED] (CryptoBook)
Subject: ICSA Guide to Cryptography
Date: 02 Jan 1999 06:32:34 GMT
Classical Crypto Books is pleased to announce that the following major new book
is in stock and ready for immediate shipment.
ICSA Guide to Cryptography
by Randall K. Nichols (Ed)
For a comprehensive single volume library on a wide range of topics in
cryptology, you need look no further than the International Computer Security
Association (ICSA) Guide to Cryptography. Lead author Randy Nichols has
skillfully merged contributions from 22 subject matter experts to produce a
highly readable text. A unique feature is the treatment of both modern and
classical cryptology. Included are 22 chapters in five parts: 1 - The
Development Of Cryptography [Introduction; First Principles and Overview;
Historical Systems I; Historical Systems II; Codes and Machines; Data
Encryption Standard (DES) and Information Theory], 2 - Commercial Cryptographic
Systems [Public Key (Asymmetric) Cryptography; Algorithms; Identification,
Authentication, and Authorization on the World Wide Web; Digital Signatures;
Hardware Implementations; Certificate Authorities], 3 - Implementation and
Product Certification [Implementation Mistakes; ICSA Product Certification], 4
- Practical Cryptography [Internet Cryptography; Security: Policy, Privacy, and
Protocols; Smartcards; IP Security and Secure Virtual Private Networks;
Cryptography in Electronic Commerce Systems; Role-Based Cryptography], and 5 -
New Dimensions [Cryptanalysis and System Identification; Biometric Encryption].
Complementing the text are a glossary, an annotated bibliography, an index, and
eight appendices [Standards, Xenocryptic Data, A Short Tutorial in Complexity
Theory, A Short Tutorial on Number Theory, ICSA List of Adopted Algorithms,
Elliptic Curves and Cryptography (ECC), Progression of Cryptographic Machines,
and U. S. Legal and Government Policy Controlling Cryptography]. The included
CD-ROM contains supplementary technical papers as well as product information
and demonstrations. McGraw-Hill, 1999, xlii + 838 pp, CD-ROM.
Softbound: Pub. $70.00, Member $56.95, Non-Member $59.95
BINDING NOTE: McGraw-Hill originally planned to produce this book in a
hardbound format, but switched to a softbound format at the last minute. Their
advance information, which was provided to on-line booksellers such as
amazon.com, barnesandnoble.com, and borders.com showed a hardbound format. That
advance information is wrong -- the hardbound edition was never produced. This
softbound edition is the only one available.
PRICE NOTE: Order from CCB and you will save at least $10 over prices offered
by the online booksellers mentioned above (as of 1/1/99 -- all prices subject
to change without notice). Member prices are available to members of the
American Cryptogram Association, the US Naval Cryptologic Veterans Association,
and full time students.
A shipping and handling charge applies to each order. Visa and MasterCard are
accepted. For complete ordering information, a free catalog of crypto books
stocked, or for information about membership in the American Cryptogram
Association, please send email to [EMAIL PROTECTED]
Best Wishes for 1999!
Gary Rasmussen
Classical Crypto Books
E-Mail: [EMAIL PROTECTED]
Fax: (603) 432-4898
------------------------------
From: "Lyal Collins" <[EMAIL PROTECTED]>
Subject: Re: Session key establishment protocol with symmetric ciphers
Date: Sat, 2 Jan 1999 19:08:35 +1100
A denial of serice is possible if either R_A or R_B are altered due to any
cause.
The described protocol also requires multi-part message flows.
Why not simply create K_S = E( (R_A ), K), and send the message M plus R_A
to Bob, reducing network overheads etc. Bob recreated K_S from R_A, the
decrypts message M
Be careful how you do this, as a number of patents cover this general idea
in various ways.
Lyal
Shawn Willden wrote in message <[EMAIL PROTECTED]>...
>"Michael A. Greenly" wrote:
>
>> This protocol is vulnerable to a man in the middle attack.
>
>I think you're wrong. Although the MITM can always compute
>F(R_A, R_B), he cannot compute K_S directly, because he doesn't
>know K, even if he chose R_A or R_B. It seems to me that the
>best he can hope for is to choose an R_B' to send to Alice or an
>R_A' to send to Bob (or both) such that a previously used session
>key is reused, though he can't know what that session key is.
>However, assuming Alice and Bob are careful to avoid reusing
>values (or simply choose them at random from a sufficiently large
>space) then the properties I described in my first post should
>close out this opportunity as well.
>
>Have I missed something? If so, what?
>
>> >Suppose Alice and Bob share a secret key K and wish to
>> >establish a session key to be used for encrypting
>> >messages.. Alice generates a random R_A and Bob generates a
>> >random R_B. Alice sends R_A to Bob and Bob sends R_B to
>> >Alice, then both compute:
>> >
>> > K_S = E( F(R_A, R_B), K)
>> >
>> >to get the session key K_S.
>
>Shawn.
>
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Robert Davies)
Subject: Re: Make Fast Random Number Generator?
Date: Sat, 02 Jan 1999 09:43:33 GMT
Reply-To: [EMAIL PROTECTED]
Paul Crowley <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Robert Davies) writes:
>
>> The Tundra generator goes at 20,000 bytes per second, but it
>> plugs into an ISA slot. You could put 4 of them in a single
>> PC and run them at double speed to get 1,280,000 slightly biased
>> slightly correlated bits per second. Quite expensive.
>
>Eek. For what application is a fast CPRNG fed by a slower random
>number generator unsuitable?
The two applications I can think of requiring the fast generation
of random numbers are
(1) for someone generating the numbers for a one-time-pad to be
stored on a CD-ROM and
(2) for statistical simulations where a PRNG was considered
unsuitable
I suspect a CPRNG fed by a slower real random number generator
would be unsuitable for both of these.
Robert
------------------------------
From: [EMAIL PROTECTED] (KloroX)
Crossposted-To: comp.lang.java.programmer,comp.lang.java.security
Subject: Re: Open source Crypto algorithms in Java
Date: Sat, 02 Jan 1999 11:41:24 GMT
Reply-To: [EMAIL PROTECTED] (this is spam bait)
On 01 Jan 1999 17:08 +0000, Mr. Tines <[EMAIL PROTECTED]>
wrote:
>> >http://www.windsong.demon.co.uk/crypt.zip
>>
>> The link does not work...
>
>Does it work now??
Yes, thank you.
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Re: OTP/FTP/MTP Question
Date: Sat, 2 Jan 1999 10:44:11 +0100
On 1 Jan 1999, Earl Pottinger wrote:
> Hello,
> I don't know what the proper terms to use to do a DejaNews search,
> so if this has been discussed before please could you supply a few search
> terms for me.
>
> If a OTP is many times larger than the total messages sent, then as long
> as the communicating parties stay in sync then the messages should be
> unbreakable, I think.
It has to be at least as long as the sum of all messages to be provably
secure.
>
> Where is the source of such a large OTP to come from.
To get a OTP you'll need a true random number generator - for example an
electronic noise generator. It is possible to buy very good ones as well
as to use simple noise sources like the output of a microphone to get
generators that will do the job.
They can as well be implemented in software (keywords: 'yarrow',
'/dev/rand')
The problem is: It is neccessary to transmit the whole noise using a
secure channel (in most cases one is using floppies, tapes or CDs - I'd
prefer tapes, because it is possible to store lots of data, to erase the
tape after usage of parts of the data and it doesn't hurt to torch the
tape after having used all the noise stored on it).
> It seems that a
> random number generator based of shifting a seed number with EOR feedbacks
> should do this fine.
No - these ones are not provably secure (keyword would be 'stream cipher')
Actually such a generator (called 'linear feedback shift register',
keyword 'LFSR') is not secure at all.
> However, I was think of a hardware/software design
> where the starting seed would be very large IE 20^20 to 2^28, a lagre seed
> could be used but this is small enought to fit on a floppy for
> transportation.
>
> If sync is lost because of some one trying hack the system then it can be
> restore by sending a clear text message to restart a X cycles from the
> first seed configuration.
>
> Questions;
> Multiple restarts are a weak point, can the first restart be
> used to transmit a new seed safely?
No. A better way would be to use one very strong but maybe slow generator
to encrypt the messagekeys. It would be helpful to use a generator that
allows to get any random number within the stream without generating all
earlier ones. You could use random number (time * length of seed) so the
random sequence wouldn't be repeated. 'time' has to be transmitted to
prevent problems with non-synchronous clocks.
BBS (Blum, Blum and Shub developed this generator) would
be a good choice, but it is not simple to implement this one in hardware.
Another way would be to store the last state of your generator.
Or you could transmit one tape or floppy with noise and use it to encrypt
the seeds of single messages. This way the encryption of the seed is
provably secure and you don't have to use lots of floppies to ancrypt huge
datasets.
>
> Testing for small arrays (4-8 bits) I found if I knew the clear
> text I could figure out the seed and feedback using long messages.
LFSRs aren't secure but can be used to develope stronger generators - have
a look at A5 as example for such a construction (the registers in A5 are
too short to be secure, but this could be changed simply).
> However I could not do that if the message shorter than the repeat pattern
> of the RNG. It was however still hard to break by hand.
> Must the lenght of the seed always be longer than any message
> sent?
For OTPs (provably secure): Yes.
For stream ciphers: No.
> Or will a 2^20 seed hard to break even if used to send a 2^28
> lenght message?
No - not if you are using a single LFSR.
>
> Are there simpler ways to break the RNG seed that I don't know
> about? I expect a yes to that question.
Yes, but it is hard to get more information about these ways.
>
> Earl Colby Pottinger
> ---------------------------------------------------------------------
> : Internet Direct. Have you heard about our :
> : (416)233-2999, 1000 lines Do-It-Yourself Webserver? :
> : T3 bandwidth, 9600-33,600bps+ISDN http://web.idirect.com :
> ---------------------------------------------------------------------
>
>
Andreas Enterrottacher
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: Re: PGP Keys on Smartcard
Date: 2 Jan 1999 12:47:53 GMT
In article <01be35d5$51109520$337be8c3@infinity>,
fred <[EMAIL PROTECTED]> wrote:
>Hi there.
>
>I'm a PGP User on Windows NT and would prefer to
>keep my secret keys on a smartcard which would always
>physically reside with me.
>
>Does such a product exist? I would ideally like to think that
>my secret keys always remained on the card and that signing
>and digest creationn occured on the card. That way my keys
>couldn't be snaffled away by a miscreant program on my NT
>workstation.
>
>Has anyone done this or am I about to make my fortune?
See for example http://www.cs.berkeley.edu/~nikitab/projects/auth-agent/
and http://www.cs.berkeley.edu/~nikitab/projects/auth-agent/paper.ps
(a project done by one of the studentsin the Computer Security class I
co-taught this past Fall: http://www.cs.berkeley.edu/~daw/cs261/),
as well as the talk I'll be giving at RSA '99, "The Palm III as an
Authentication Token".
The latter also discusses why you _can't_ use a smartcard to get what you
want; briefly, if your NT box has a miscreant program, it can just wait
for you to insert the smartcard and unlock it, and then it can obtain
a signature on whatever it likes.
- Ian
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encryption Basics
Date: Sat, 02 Jan 1999 13:00:55 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Tim Redburn) wrote:
> On Sun, 20 Dec 1998 13:48:45 GMT, [EMAIL PROTECTED] wrote:
>
> <snip>
> > One such person
> >helped set up a web page for me. So at least read a little bit
> >before you shoot your mouth off and spread more lies. Or are you
> >incapable of telling the truth.
> >
> <snip>
>
> You said yourself that you would not agree with the contents
> of the page that was created for you, and in fact it's contents are
> still at best misleading .... well at least it's claims as to the
> entropy of the S-Boxes (this is the only bit I have looked at in
> detail).
Well at least it still is over a million bytes no matter how you
slice it. Like I said I didn't change his wording since at least
his style caused you to some what look at it. However I have been
thinking of writting a parallel analysis so you could contrast the
2 methods. But still the C source code is the best palce to look
at.
>
> To quote you from an earlier post (1998/12/02) .......
> >> The main thing I looked at in that page is the graphs
> >> I changed them to gifs for speed. I have not read all he
> >> wrote since I knew I would disagree. I would remember the
> >> word entropy. I never use words like that except when talking
> >> about thermodynamcis. If I read that part I would have changed
> >> it and I plan to leave the page mostly alone since the guy
> >> was nice enough to talk me in to getting a web page.
>
> Why do you still refer people to the page if you don't beleive it to
> be correct ? If you can't correct it, then you should at least
> remove the reference from your signature, to stop people wasting
> their time reading and analysing it.
If you can think of a nice internal footnote that is clear I could
add that to it. But I don't want to change his comments as yet but
willing to add clarifaction if you can do that. That is if you
have an understanding of it yet.
>
> <snip>
> >http://members.xoom.com/ecil/index.htm
> <snip>
>
> - Tim.
>
Dave
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Arnoud "Galactus" Engelfriet)
Subject: Re: Opinions on S/MIME
Date: Sat, 02 Jan 1999 13:13:28 +0100
In article <[EMAIL PROTECTED]>,
"Sam Simpson" <[EMAIL PROTECTED]> wrote:
> Thanks for the additional information. I appreciate the need for the
> individual to prove to the CA that they are in possession of the private key
> in order to stop some attacks, but having an "archive private key field"
> seems like mandatory escrow waiting to happen.
For authentication-only systems, that's not likely. All European
proposals I've read state quite explicitly that "private keys for
authentication shall not be archived." Perhaps the Americans think
differently about this.
The big problem with archiving secret keys for authentication is
that it is no longer possible to guarantee that only the real owner
of the secret key could have created the signature. This makes it
impossible to provide non-repudiation services, since the owner can
now always claim that the CA must have compromised its copy of the
secret key. In a normal setup, only the owner has the secret key, so
any compromise is the fault of the owner, so it is only his
responsibility to handle this.
Greetings,
Arnoud
--
\/ Arnoud "Galactus" Engelfriet - [EMAIL PROTECTED] This space
5th year Business & Computing Science student left blank
URL: http://www.stack.nl/~galactus/ PGP: 0x416A1A35 intentionally.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
