Cryptography-Digest Digest #399, Volume #9 Thu, 15 Apr 99 23:13:04 EDT
Contents:
Re: PGP, The Big Lie (Theorem with Incomplete Proof) (Edward A. Falk)
Re: Comments to DOJ re NICS (Eric Williams)
Re: Comments to DOJ re NICS (Eric Williams)
Re: Comments to DOJ re NICS (Paul Rubin)
Re: Blowfish Source Code? (John Dafoe)
Re: Twofish among the top 5 ?! (DJohn37050)
Extreme lossy text compression ([EMAIL PROTECTED])
Re: Extreme lossy text compression (John Myre)
SCRAMDISK question ("N")
Re: Simple additive problem ([EMAIL PROTECTED])
Re: Adequacy of FIPS-140 ([EMAIL PROTECTED])
Re: Comments on Boomerang Attack Sought (David Wagner)
Re: Adequacy of FIPS-140 ([EMAIL PROTECTED])
The Cryptogram by Jules Verne (CryptoBook)
I don't care! ("Charles Booher")
HEY STUPID!!! ("Charles Booher")
Re: PGP 6 is JUNK ("Charles Booher")
PGP=NSA (PGP 6 totally cracked by NSA!!) ("Charles Booher")
John Savard is REALLY REALLY STUPID!! ("Charles Booher")
Cryptography Short Course (Christof Paar)
Re: Is public key crypto just Snake Oil?? (Kenneth Almquist)
PGP=NSA (More Evidence) ("Charles Booher")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Edward A. Falk)
Subject: Re: PGP, The Big Lie (Theorem with Incomplete Proof)
Date: 15 Apr 1999 15:49:11 -0700
In article <7f0sh5$[EMAIL PROTECTED]>,
Charles Booher <[EMAIL PROTECTED]> wrote:
>Theorem: There is no PGP Book.
>
>...
Dearie, dearie me.
I give up. Troll, or just someone who needs their medication adjusted?
FWIW, I've seen the pgp5 book with mine own eyes. Can't vouch for
the pgp6 book, but I'd say the odds of it's being genuine are
pretty good.
--
-ed falk, [EMAIL PROTECTED] *********************#*************#
See http://www.rahul.net/falk/whatToDo.html *#**************F******!******!*!!**
and read 12 Simple Things You Can Do ********!***************************
to Save the Internet #****#******#*********!**WW*W
------------------------------
From: Eric Williams <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.guns
Subject: Re: Comments to DOJ re NICS
Date: Thu, 15 Apr 1999 15:52:27 -0700
ELVA wrote:
>
> Hello,
>
> Reading the ideas exchanged about NICS signature we might have a
> solution to answer the problem.
>
> Our company named ELVA Inc, an holding based in Florida, which has its
> headquarter based in France in
> Paris, has created a new identification smart card, called VocaliD,
> which allows On Line identification.
Sounds similar to our (Secure Computing's) synchronous authentication
tokens, but I'm not sure how it would be useful in this application?
We're trying to provide verification of a document and it's associated
approval, not someone's identity.
------------------------------
From: Eric Williams <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.guns
Subject: Re: Comments to DOJ re NICS
Date: Thu, 15 Apr 1999 15:47:27 -0700
Paul Rubin wrote:
>
> In article <[EMAIL PROTECTED]>,
> Eric Williams <[EMAIL PROTECTED]> wrote:
> >> Depending on having a phone available doesn't sound so wise in this
> >> situation.
> >
> >I think I've heard of a recent invention called a "cellular phone". It
> >might have applications in this situation.
>
> See above. Cellular phones work in most urban areas. Gun dealers
> are not necessarily in urban areas. The cell phone systems with
> the most coverage are analog and are terrible for sending data.
> I guess a satellite phone might work better but it starts getting
> ridiculous.
>
> >> Of course it would. You just backdate the transfer to the day the key
> >> was good.
> >
> >But if DOJ kept records of what signatures were issued to what FLL and
> >when (as my proposal included), that scan wouldn't work.
>
> In that case there is no need for a secret key. Just remember the
> hash of the whole application. You're no longer verifying anything,
> but just looking it up.
I think you need to study the current NICS system and my proposal, you
keep re-introducing problems that have already been solved and throwing
away solutions for those that haven't.
------------------------------
Crossposted-To: talk.politics.guns
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Comments to DOJ re NICS
Date: Thu, 15 Apr 1999 23:22:33 GMT
In article <[EMAIL PROTECTED]>,
Eric Williams <[EMAIL PROTECTED]> wrote:
>> In that case there is no need for a secret key. Just remember the
>> hash of the whole application. You're no longer verifying anything,
>> but just looking it up.
>
>I think you need to study the current NICS system and my proposal, you
>keep re-introducing problems that have already been solved and throwing
>away solutions for those that haven't.
I'm a cryptography guy (sci.crypt) and don't have much knowledge of,
or interest in, the finer details of current gun registration policy,
which I presume is what NICS is. I tried to answer your questions
from a cryptography implementer's point of view. I did look at your
proposal and described its problems compared with current security
practices in other areas. It may be much better than NICS
regardless--I don't know. I like the idea of being visited by federal
agents if one of them is Agent Scully. I doubt if NICS provides
for that though. If your system can do that, sign me up. ;-)
------------------------------
Date: Thu, 15 Apr 1999 16:29:36 -0700
From: John Dafoe <[EMAIL PROTECTED]>
Subject: Re: Blowfish Source Code?
Jon Kadilak wrote:
> I'm not sure if this is the right group to post to, apologies if it is
> not. Can someone point me in the direction of some Blowfish encryption
> algorithm source code? Or some source code that will encode files with
> the Blowfish encryption method.
>
> --
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Jon Kadilak The Internet Access Company
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The author of Blowfish, Bruce Schneier's home page is www.counterpane.com and
he has info on the algorithm in question.
--
John Dafoe
Director of Internet Communications
CyPost Corporation - http://www.cypost.com
Strong Encryption Products
Suite 101, 260 West Esplanade,
North Vancouver, B.C. Canada. V7M 3G7
Phone: (604) 904-4422 Ext. 228
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Twofish among the top 5 ?!
Date: 16 Apr 1999 00:03:14 GMT
I do think Twofish should be a finalist.
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Extreme lossy text compression
Date: Fri, 16 Apr 1999 00:20:22 GMT
I have an idea to reduce redundancy in a large data store. When a plaintext
is submitted to storage, I want to be able to easily determine whether that
exact plaintext already exists in my storage.
Briefly, my idea is to process some plaintext (which might be from 1KB to 10KB
in length), and create, say, a 256 byte "key" that is derived from that
plaintext that will be unique with a high degree of certainty.
It would be kind of like an extreme "lossy" compression scheme. We'd be
taking up to 10000 bytes of plaintext and creating a 256 byte "key" useful for
matching identical plain texts.
Then when a new plaintext is submitted, I can generate my 256 byte "key" and
quickly search my database to determine if that 256 byte "key" already exists.
Unlike most things discussed in sci.crypt:
1. I don't need to be able to recreate the plaintext from the key.
2. I don't care about security, so headers and things are perfectly fine.
Let's assume that I won't be able to compare the original plaintexts to verify
that they are actually identical. I need a high degree of confidence based
upon the keys alone.
Has anyone ever heard or seen anything like this before?
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Extreme lossy text compression
Date: Thu, 15 Apr 1999 19:11:05 -0600
(see original question below)
Any good hash (e.g. SHA-1) ought to work. The output is even
shorter (20 bytes in the case of SHA-1) than requested, and so
more efficient. The theory is that a good hash seems like a
"random function" of the input and so the likelyhood of a false
match (a "collision") is the same as two random values of the
hash length being the same. For SHA-1 this means a 1 in 2^160
chance of error (*really* small).
Intuitively, I think of it this way: we say a hash function is
cryptographically secure when we don't think an adversary could
generate a false match on purpose even with extraordinary amounts
of compute power. If that is so, then an accidental false match
must also be extremely unlikely, or else the adversary could
generate a false match merely by trying random inputs.
The way this is different from more ordinary check value functions
(CRC's and the like) is that we (essentially) remove the chance
that a few simple changes to a document would result in the
same check value. An ordinary check value function has some
structure which an adversary could use to figure out how to
get a false match; given such a structure a "few" changes might
work, and a "few" changes can happen by accident.
If a 20 byte hash doesn't seem long enough, you could concatenate
two or more different hashes (e.g., SHA-1 plus MD5, or a hash of
the document plus a hash of the document modified in some simple
way, like adding a blank at the end).
(Of course, I am taking for granted that in fact you want even a
tiny (e.g., 1 byte) change to show up as a difference; that you
don't care if you store umpty-ump versions of the same document.)
[EMAIL PROTECTED] wrote:
>
> I have an idea to reduce redundancy in a large data store. When a plaintext
> is submitted to storage, I want to be able to easily determine whether that
> exact plaintext already exists in my storage.
>
> Briefly, my idea is to process some plaintext (which might be from 1KB to 10KB
> in length), and create, say, a 256 byte "key" that is derived from that
> plaintext that will be unique with a high degree of certainty.
>
> It would be kind of like an extreme "lossy" compression scheme. We'd be
> taking up to 10000 bytes of plaintext and creating a 256 byte "key" useful for
> matching identical plain texts.
>
> Then when a new plaintext is submitted, I can generate my 256 byte "key" and
> quickly search my database to determine if that 256 byte "key" already exists.
>
> Unlike most things discussed in sci.crypt:
> 1. I don't need to be able to recreate the plaintext from the key.
> 2. I don't care about security, so headers and things are perfectly fine.
>
> Let's assume that I won't be able to compare the original plaintexts to verify
> that they are actually identical. I need a high degree of confidence based
> upon the keys alone.
>
> Has anyone ever heard or seen anything like this before?
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "N" <[EMAIL PROTECTED]>
Subject: SCRAMDISK question
Date: Fri, 16 Apr 1999 00:56:03 GMT
I have Scramdisk installed and think it's a great piece of software.
Some of the files stored on it are encrypted again (yes, okay - forgive my
overkill!) using a mixture of PGP and Cryptext.
I have noticed that, sometimes when I try to decrypt some of these files on
the mounted volume, I get an error and the decryption will not proceed. The
only way to access my files is by copying them back to my C: drive and
decrypting them from there.
Does anyone know why this might be happening? It only occurs with certain
specific encrypted files, but happens consistently with the ones in
question.
In the case of PGP, the error reported is:
"PGP warning - an error has occurred: bad packet".
In the case of Cryptext, you just get the usual error that is reported when
the password has been mistyped.
=============================
As an aside, does anyone have any opinions as to the security afforded by
Cryptext? I use it in conjunction with other encryption (like PGP), but
haven't
stumbled across many comments on it.
Many thanks
N
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Simple additive problem
Date: Fri, 16 Apr 1999 01:43:02 GMT
Here is a clarification (I made some mistakes)..
Both Bob and Alice have a random number seed (LFSR state or what have not).
The protocol works like this...
1. Using the shared LFSR state, they make two large (?) numbers A and B.
2. Only one user sends the value (A+B mod 2^n).
3. The other user verifies
4. Loop to step 2 (if passed).
Assuming each a and b are n bit words, there are 2^n combinations of A and B
which will produce the output. The problem is the first bit is partialy
revealed. Thusly you could return the middle w bits (if n = 512, then w could
equal the middle 128 bits or 256 bits...)
The attacker would have a 1 in 2^n (or 1 in 2^w if you use a window) chance of
faking the identity.
The same result has a 1 in 2^n (or 2^n) chance of occuring in the protocol.
So even if you know one result, you can't use it to fake the identity.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Adequacy of FIPS-140
Date: Fri, 16 Apr 1999 01:10:20 GMT
[EMAIL PROTECTED] wrote:
> I will do as I chose.
Indeed you will, sir. And so far, you have chosen to be an intellectually
dishonest idiot. Good show, man! Encore!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Comments on Boomerang Attack Sought
Date: 15 Apr 1999 19:24:44 -0700
Your assessment seems about right to me.
In honesty, it seems there are really only about two cases where the
boomerang attack has any chance of being very useful in practice:
1. When the round function is asymmetric, where e.g. diffusion is worse
in one direction than in another, or
2. When the cipher has a non-homogenous structure, so the round function
is not the same in all rounds (i.e. it is not a pure iterated cipher).
DES has a homogenous structure with symmetric round function
=> safe from boomerang attack ?
COCONUT98 is non-homogenous, symmetric
=> apply boomerang + conventional differentials.
Khufu is homogenous, asymmetric
=> apply boomerang + truncated differentials.
QUADIBLOC is non-homogenous; QUADIBLOC 99 is homogenous.
Skipjack has non-homogenous structure and asymmetric round function .....
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Adequacy of FIPS-140
Date: Fri, 16 Apr 1999 01:28:52 GMT
[EMAIL PROTECTED] wrote:
> Assume, as Patrick Juola did, that there are 10^12 documents on the
> Web. If I select any 3 of them to mix strongly for my keystream after
> hashing), then there are approximately (2^40)^3 combinations
A black-bag job on your home is conducted. A copy of the program which
generates the 3 document references is located. It is reverse engineered,
and all possible sets of documents it generates for some span of time is
computed. This set is going to be much smaller than 2^120.
Game over for you.
A TEMPEST van captures the program as you develop it. It may also capture
the 3 URL's.
Game over for you.
A tap on your phone line captures the documents as you download them.
Game over for you.
Your efforts to produce even a passable *pseudo* random number are laughable,
Knauer. How on Earth can you even dare to speak of "true random numbers"
or "provable security"?
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (CryptoBook)
Subject: The Cryptogram by Jules Verne
Date: 16 Apr 1999 02:36:21 GMT
Classical Crypto Books is pleased to announce availability of the following
book:
The Cryptogram
by Jules Verne
Like Edgar Allan Poe, whom he admired greatly, Jules Verne was so fascinated by
cryptography that he made the solution to a Gronsfeld cipher the central theme
in this 1881 novel of Amazon adventure. Verne "points to Poe's 'Gold Bug' as
the source for his own tale.... The handling and appreciation of cipher
writings in 'The Cryptogram' are as different from the superficial explanation
of the cipher in Verne's earlier [Journey to the] 'Center of the Earth,' as is
the appreciation of a master from that of the most idle amateur." -- From the
Introduction. The publisher's note states that this difficult to find, and long
out of print volume is released "in an edition limited to 80 copies." Amereon
House, viii + 111 pp.
Hardbound: Pub. $18.95, Member $17.95
Member prices are available to members of the American Cryptogram Association,
the US Naval Cryptologic Veterans Association, and full time students. Shipping
and handling are extra. For complete ordering information, a free catalog of
crypto books, or for information about membership in the American Cryptogram
Association, please send email to [EMAIL PROTECTED]
Best Wishes,
Gary Rasmussen
Classical Crypto Books
E-Mail: [EMAIL PROTECTED]
Fax: (603) 432-4898
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: I don't care!
Date: Thu, 15 Apr 1999 19:54:57 -0700
> Also note that even if you are correct about PGP, no one is going to
> buy your product simply because we don't like your attitude or your
> posts. Learn to be a little nicer and you might actually sell something.
>
I don't care!
I am going to get the truth out about PGP.
It does not matter to me if you use my product or not.
PGP = NSA TRANSPARENCY
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: HEY STUPID!!!
Date: Thu, 15 Apr 1999 20:00:59 -0700
If you do not like my attitude it is probably because your work for the NSA.
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: Re: PGP 6 is JUNK
Date: Thu, 15 Apr 1999 19:59:58 -0700
> Come to think of it, PGP 6.0 uses Diffie-Hellman, not
> Rivest-Shamir-Adleman. So even if it did use only 10^9 different prime
> moduli ... or even just one ... for _that_ algorithm, it would still be
> secure.
SecureOffice uses
UNLIMITED KEY LENGTH RSA
and
UNLIMITED KEY LENGTH ELGAMAL
You get to pick the prime numbers.
You get to check the math.
You get to decide for yourself if I am telling the truth or not!
Yes, Math people can be rather odd.
I may be crazy, but I am not stupid.
PGP=NSA
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: PGP=NSA (PGP 6 totally cracked by NSA!!)
Date: Thu, 15 Apr 1999 20:04:38 -0700
Zimmerman can fill you in on the details.
PGP is now owned by Network Associates.
Network Associates does $$$$ buisness with the NSA.
Mostly they sell Sniffers to the NSA.
The NSA also buys Ultra SPARCS by the truck load.
THE NSA CAN READ MOST PGP MESSAGES!!
There are only 1,000,000,000 possible PGP key pairs with DF implemenation in
PGP 6.0
Every PGP key pair has been calculated, stored, and sorted.
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: John Savard is REALLY REALLY STUPID!!
Date: Thu, 15 Apr 1999 20:05:06 -0700
1449104978526962045944998855740936856568093587767296486248442594117477060009
6997455294355191321068642504870556150664426314137478852719891307141306383574
6783912763163712962433846438054519146426734032774330564678455517587171562820
03341822395966282473836094381032182030279009091296250408308536353450477
is prime.
Can you please give me the next prime number?
------------------------------
From: Christof Paar <[EMAIL PROTECTED]>
Subject: Cryptography Short Course
Date: Thu, 15 Apr 1999 22:49:12 -0400
Worcester Polytechnic Institute
4-Day Short Course
Waltham Campus
APPLIED CRYPTOGRAPHY AND DATA SECURITY
Seminar Leader: Dr. Christof Paar
This course will provide you with an in-depth understanding of
applied cryptography and information security. Most of today's
information technology applications require security as a central
system feature. Applications such as LAN computer networks,
intranets, E-commerce, database systems, and many www applications
rely heavily on a high degree of system security. This four-day
course will provide you with a solid foundation in state-of-the-art
cryptography and data security.
The course provides you with a balance of cryptographic algorithms,
protocols, standards, and many real-world examples. All cryptography
schemes will be introduced together with up-to-date security
assessments, information on their software and hardware performance,
and remarks on their implementation. At the end of the course you
will have the skills to design, assess, and implement data security
schemes for given applications.
Note: The Applied Cryptography course has been taught to more than
250 technical professionals and graduate students. On-site programs
were delivered at the NASA Lewis Research Center, OH, GTE Government
Systems, MA, and at Philips Research, NY.
COURSE OUTLINE
Introduction to Cryptography and Data Security
Overview. Private-Key Cryptosystems. Cryptanalysis.
Private-key Algorithms: Stream Ciphers
Random Number Generators. Synchronous Stream Ciphers and LFSRs.
Attacks. One Time Pad. Unconditional and Computational Security.
Private-key Algorithms: Block Ciphers
DES Functionality and History. DES Implementation: Hardware
and Software. Attacks and Security Estimations. AES and other block
ciphers.
Modes and Variants of Block Ciphers
Operation modes of block ciphers. Multiple encryption. Key whitening.
Introduction to Public-Key Cryptography
Principle. Some Number Theory. Overview of Practical Schemes: RSA,
Diffie-Hellman-type, Elliptic Curves. Public-Key standards (ANSI,
IEEE)
RSA
Cryptosystem. Implementational Aspects. Recent Attacks and Security
Estimations.
Diffie-Hellman-Type Cryptosystems
The generalized discrete logarithm problem. Diffie-Hellman key
exchange. ElGamal encryption. Elliptic curve cryptosystems.
Elliptic Curve Cryptosystems
Cryptosystems. Implementational Aspects. Attacks and Security
Estimations.
Digital Signatures and MACs
Principle. RSA, ElGamal, DSA Signature Scheme. Message Authentication
Codes (MACs).
Hash Functions
Introduction. Security Considerations. Practical Hash Algorithms.
Protocols
Attacks Against Protocols. Security Services. Privacy,
Authentication, Integrity, Non-Repudiation.
Key Distribution and Agreement
Private-Key Approaches. Public-Key Approaches. Certificates. Perfect
Forward Secrecy. Key Derivation.
Introduction to Identification Schemes.
Secret Key Approaches. Challenge-Response Protocols.
WHO SHOULD ATTEND
Engineers and other technical professionals who design, assess, or
implement information security applications in software or hardware;
system administrators who need to address security issues in computer
networks; software engineers involved in E-commerce projects;
technical managers who need a solid understanding of data security.
ABOUT THE INSTRUCTOR
Dr. Christof Paar leads the Cryptography and Information Security
Group at WPI's ECE Department. Christof's research interests include
efficient implementation of public-key and symmetric-key algorithms,
wireless and ATM security, and cryptographic algorithm agility. He is
the co-organizer of the Workshop on Cryptographic Hardware and
Embedded Systems (CHES), to be held at WPI in August 1999. For more
information on his research, visit http://ece.wpi.edu/Research/crypt
DATES AND LOCATIONS
May 6-7 & 13-14, '99 WPI Waltham Campus, Waltham, MA, USA
(10 miles from Boston)
FEE
$1795 for first registration
$1625 for subsequent registrations
===================== print and cut here =============================
WPI CONTINUING EDUCATION REGISTRATION FORM
Please print out, complete, and return this form to
Office of Continuing Education, WPI, Worcester, MA 01609-2280,
call (508) 831-5517 or FAX this form to (508) 831-5694.
For further information, send email: [EMAIL PROTECTED]
Make copies of this form for multiple registrations.
Title of Seminar: APPLIED CRYPTOGRAPHY AND DATA SECURITY
Date of Seminar: May 6-7 & 13-14, '99, WPI Waltham Campus, Waltham, MA
Name (Mr.)(Ms.) ___________________________________________________
Title _____________________________________________________________
Organization ______________________________________________________
Business Address __________________________________________________
City _______________________________________
State ________ Zip _________________________
Business Phone ____________________________
FAX _____________________
Home Phone ______________
Fee Enclosed (Make checks payable to WPI) ______
Bill my Company, P.O.# __________
Please charge my: VISA Mastercard Discover
Name on card ________________________________________________
Exp. date _____________________
Card # ______________________________________________________
Signature ___________________________________________________
------------------------------
From: [EMAIL PROTECTED] (Kenneth Almquist)
Subject: Re: Is public key crypto just Snake Oil??
Date: 16 Apr 1999 02:56:42 GMT
Peter Gunn <[EMAIL PROTECTED]> wrote:
> Anyways, the problem is simple... you can only verify a signature
> from someone who you're not familiar with by checking with some
> trusted authority to make sure the public key is owned by whoever
> claims to be the author, and not a person-in-the-middle.
>
> If this is the case, wouldnt it be simpler to have a traditional
> username/password account with the trusted authority, and
> send them the hash for a document you want to sign, and
> have them return a signature of the hash encrypted using
> some 'private key' unknown even to you. Similarly, people
> could verify the signatures by simply sending off the signature
> and your username, and receive the hash for the document
> which they could then check.
You want a private key which is shared with the trusted authority,
rather than a password, if you are concerned about eavesdropping
or man in the middle attacks on your communications with the
trusted authority. The trusted authority also needs to provide
some additional operation if you want the full functionality
provided by a public key system (such as the ability to produce
a message that can only be read by person X). These details
aside, you are correct about the following points:
1) Without a trusted authority, public key systems are of
limited use.
2) If you have a trusted authority, you can implement all
of the functions provided by a public key system using
only private key cryptography.
Why bother with public key cryptography, then? The answer is
that it places fewer demands on the trusted authority.
First, with private key cryptography, users normally have to
contact the central authority more frequently. With public
key cryptography, you can download another individual's public
key once, and use it as many times as required, whereas with
the private key scheme you describe, you have to contact the
trusted authority each time you want to verify the signature
on a document. This means that the trusted authority has to
be able to handle many more queries than it would if public
key cryptography were used. It also means that higher
reliability is required, since the impact of the trusted
authority becoming temporarily inaccessible is higher.
Second, and more important, private key cryptography places
stronger security requirements on the trusted authority. With
private key cryptography, if someone steals the list of private
keys held by the trusted authority, security is broken. With
public key cryptography, depending on the details of the key
management system, an attacker either has to change the keys
held by the trusted authority (replacing your public key with
a different one) or steal the trusted authority's private key.
One way to protect against compromises of the trusted authority
is to have several trusted authorities. This can be done with
private key cryptography, but the number of communications
required discourages it. For example, to extend your signature
scheme to use two trusted authorities, you would have contact
both authorities each time you signed, or verified the signature
of a document. (Well, the verifier could contact only one of
the authorities if s/he wanted to trade security for speed.)
With a public key system, the verifier can get the public key
from two authorities once, and verify that they are the same,
or can get the key from one authority, but verify that the key
has been signed by two trusted authorities.
For these reasons, it should be easier to achieve a given level
of security when using public key cryptography than when using
private key cryptography, thus making public key cryptography
the logical choice now that the patents are expiring.
Kenneth Almquist
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: PGP=NSA (More Evidence)
Date: Thu, 15 Apr 1999 20:21:33 -0700
There are only 1,000,000,000 possible PGP key pairs with PGP 6.0
One key pair per second on an Ultra Sparc
! year = 60*60*24*365.25 = 86765.25 Seconds in a year.
100 Ultra SPARC workstations will need around four months to compute the
entire set.
If PGP is not run by the NSA then the people who wrote PGP are idiots!
408-733-7215
510-624-6864
------------------------------
** 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
******************************
