Cryptography-Digest Digest #225, Volume #10 Sun, 12 Sep 99 19:13:03 EDT
Contents:
Re: GnuPG 1.0 released (Pawe� Krawczyk)
CS Student Support Site (William Stallings)
Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out (Tom Knight)
Re: Deniability (Mok-Kong Shen)
Re: some information theory (SCOTT19U.ZIP_GUY)
13 reasons to say 'no' to public key cryptography (Thierry Moreau)
Re: patented algorithms ("Roger Schlafly")
Ritter's paper (Mok-Kong Shen)
Re: Mystery inc. (Beale cyphers) ("Douglas A. Gwyn")
Re: Sources of randomness ("Douglas A. Gwyn")
Re: Random and pseudo-random numbers
Re: Double encryption is patented (mabey)
Re: Random and pseudo-random numbers
Re: Random and pseudo-random numbers ("Douglas A. Gwyn")
Re: Mystery inc. (Beale cyphers) (Curt Welch)
----------------------------------------------------------------------------
From: Pawe� Krawczyk <[EMAIL PROTECTED]>
Subject: Re: GnuPG 1.0 released
Date: 12 Sep 1999 17:42:14 GMT
Charles Blair <[EMAIL PROTECTED]> wrote:
> Sorry for asking what I'm sure is an FAQ, but didn't one of the
> claims for the public key partners patent extend to ANY public key
> system?
> Also, does GnuPG claim to be able to process messages sent by
> users of regular PGP? If so, I would assume it has to have some
> RSA capability.
GnuPG distribution doesn't have IDEA and RSA implementations, but it
contains hooks to load external cryptographic modules. Actually, this
is as easy as adding "loadmodule rsa" and "loadmodule idea" to GnuPG
options file, and it becomes fully compatible with PGP 5+. There are
some problems with PGP 2 compatibility caused by different packets
ordering, but I don't know exactly if they are fixed now or not...
--
Pawel Krawczyk, CETI internet, Krakow. http://ceti.pl/~kravietz/
------------------------------
From: [EMAIL PROTECTED] (William Stallings)
Subject: CS Student Support Site
Date: Sun, 12 Sep 1999 14:43:58 -0400
I maintain the Computer Science Student Support Site, at
http://www.shore.net/~ws/StudentSupport.html. The purpose of this site is
to provide information and links for computer science students. I would
appreciate any comments on how to improve the site.
Bill
------------------------------
From: Tom Knight <[EMAIL PROTECTED]>
Crossposted-To: rec.arts.sf.written,alt.cyberpunk
Subject: Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out
Date: Sun, 12 Sep 1999 19:49:09 +0100
Brad Johnson wrote:
> I'd be surprised if most of the attitudes expressed in Cryptonomicon
> aren't Stephenson. Check out this earlier bit of fiction by Neal, from
> Time in 1995:
>
I'd still say that there's nothing in Cryptonomicon that seems to favor the pro
encryption attitude. I wouldn't be too surprised if Stephenson himself was pro
encryption, but the book definitely never reads like it's trying to put a point
across. As I said, he's far too clever for that.
>
> The Great Simoleon Caper
> http://kuoi.asui.uidaho.edu/~kamikaze/documents/simoleon.html
> It's the crypto cash scenario of Cryptonomicon, effectively.
>
> It's interesting how Stephenson used essays and short fiction
> to write Cryptonomicon; his Wired pieces and the "In the beginning"
> essay were both incorporated into Cryptonomicon as well.
>
> -- bradj.
> ------------------------Nullus Oppidenda Est--------------------------
> brad johnson ([EMAIL PROTECTED]) 'Disc, God, Country, Pork'
> http://www.amherst.edu/~bgjohnso/ 'Chickens! No Cynics!'
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Deniability
Date: Sun, 12 Sep 1999 21:04:55 +0200
Mok-Kong Shen wrote:
>
> Anonymous wrote:
> >
> > When you're not sending sensitive material, you encrypt the message with
> > the cover-traffic key and pad it with an equal sized block of random data.
> > This is your normal mode of operation. When you need deniability, you
> > lie and claim that this was what you used, that only half the message
> > can be decrypted and the other half is noise. You then decrypt the
> > cover half and your real message is kept safe.
>
> Maybe I misunderstood. But I am not sure that this is acceptable
> to the person demanding decryption from you. For you could otherwise
> just as well always pair a plaintext message with an enciphered
> message and claim that it is your practice to pad your messages
> with random stuffs that way.
I believe that the following scheme from discussions quite a time
ago could work:
Let R be a random string known to both partners, D a dummy message
and P the plaintext. One sends 2 ciphertexts as follows, where E1
and E2 are encryption functions and + denotes XOR:
C1 = E1( R + P )
C2 = E2( R + D + P)
When demanded to decrypt, one does an XOR of R+P and R+D+P to
present D. (R+P is pretended to be sort of OTP.)
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: some information theory
Date: Sun, 12 Sep 1999 20:27:45 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>
>> I think you have lost it again. At one time I thougth you have an idea
>> of how the ending was handled in "one to one" huffman type of methods.
>> The ending is always such that a unque sybmol would come out.
>> If you at the end of buffer depending on waht occured and you in the
>> middel of a token you either add ones the compress was able to chop
>> off. Or your in the unique token that tells you the last token was for last
>> character of the file. THere is no ERRORS. Even if you picked the
>> static tree of your choice with 256 leaves and the binary file of your
> choice.
>> There is no ERRORS. IT will decompress to a unique file that will compress
>> back. I thought at one time you inderstood this. Know you seem to be
>> lost again.
>
>I said 'the original Huffman scheme', i.e. without the type of
>modifications you employ. In that case, if a wrong Huffman table
Then the static huffman table would not be part of the file. IT
would have to be excahanged in secrect. There for one could consider
a secret huffman table as part of the encryption.
>is used, then the chance is high that on reaching the last bit
>of the file one has an incomplete code which one can't deal with.
>So my arguments as given in the previous post seem to hold.
>For the adaptive Huffman (I consider again the original unmodified
>one), the same phenonemon can occur. Since now the algorithm can be
>started with an arbitrary table which the analyst don't know,
Then if the table is secret it is part of the encryption. Some
how you have to get it to the users.
>he has apparently a problem to decide whether he guess the wrong
>table or the wrong key.
Your right if the starting table used was secret and if using the
"origianal method" He could have the wrong huffman table if he
was guessing and or the wrong encryption key.
But I would consider a secret huffman table a part of encryption.
and not compression. But lets say you use a secret table like
you suggest and the enemy picks ( though this is a slow way to do
it) a encryption key and a huffman table. If the combination leads to
a file which can't be properly decompressed. The enemy knows that
even if the encrypted key is correct that he has the wrong huffman
table. He then may search ( some how ) to find the valid huffman tables
if any that lead to the string being compressed. IF the encrypted key was
wrong he still can find if any the possible starting tables that lead to a
file. IF any he then most check those few files. But the amount of files
one needs to check is very small compared to what would have had to been
checked if the guy used a proper "one to one' modifaction to write the
compressed text in the first place.
>
>M. K. Shen
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Thierry Moreau <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: 13 reasons to say 'no' to public key cryptography
Date: Sun, 12 Sep 1999 14:31:08 -0400
I once wrote this opinion statement
(http://www.connotech.com/13reas.htm) entitled "Thirteen Reasons to Say
'No' to Public Key Cryptography." It might be a starting point for some
interesting discussions in sci.crypt.
A more business-oriented perspective on the long-term market potential
for public key cryptography is in another document
(http://www.connotech.com/alttopki.htm) entitled "Why Should We Look for
Alternatives to the Public Key Infrastructure (PKI) Model?"
Have a pleasant reading everyone (please be tolerant for typos and
spelling errors)!
- Thierry Moreau
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: patented algorithms
Date: Sun, 12 Sep 1999 11:40:29 -0700
Richard Parker wrote in message ...
>> RC4?
>
>The RC4 encryption algorithm was not patented, but it was a trade
>secret. Now that the algorithm has been leaked, RC4 is no longer a
>trade secret. However, the name "RC4" is a trademark in the US and
>can not be used without RSA's permission.
To be more precise, the trademark limits the marketing of products
in a confusing manner. You can say that you use of RC4 is compatible
with RSADSI's RC4, or put in a disclaimer.
>> RDA?
>
>Did you mean RSA? The RSA public-key algorithm is claimed under US
>patent 4,405,829. This patent expires on September 20, 2000.
The patent doesn't actually cover the algorithm. But it will expire
soon anyway.
>> DSA
>
>The NIST Digital Signature Algorithm is patented under US patent
>5,231,668. NIST permits the free use of DSA. It is my understanding
>that several other patent holders have claimed that their patents must
>be licensed in order to use DSA. I do not know the current status of
>DSA. However, GNU Privacy Guard <http://www.gnupg.org/> supports DSA,
>so presumably the GnuPG team believes DSA to be unencumbered.
No, I don't think so. At one time the US patent 4,995,082 (Schnorr) made
such a claim, but the patentholder no longer makes any claim that it
covers DSA.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Ritter's paper
Date: Sun, 12 Sep 1999 22:11:42 +0200
I just read Terry Ritter's Article
Cryptography: Is Staying with the Herd Really Best?
in Computer (August issue). While the content has been subjects
of a number of previous discussion threads in this group, the
presentation of the article is extremely lucid and renders it not
only a valuable paper for the general readers of that journal but
also worthy, in my humble opinion, the time of those who have
participated in the said discussions to glance over it to refresh
in memory what has been argued in the past. I enjoyed very much
reading the paper.
M. K. Shen
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Mystery inc. (Beale cyphers)
Date: Sun, 12 Sep 1999 20:31:16 GMT
Curt Welch wrote:
> > ABFDEFGHIIJKLMMNOHPP. He considers that evidence of a hoax, but
> The odds of it happening by ramdom chance are so small that to ignore
> the string would be foolish.
Jim estimated the odds in his article.
However, it is important to understand that the probability
of even *a completely random* specific character string that
long is exceedingly low. It is not the raw probability that
should be considered, but rather the total weight of *all*
available evidence for or against a specific hypothesis.
I've actually seen apparent "clues" nearly that striking
that turned out to be false leads.
However, in further posts Jim noted stronger evidence of
that sort, which bolsters his conclusion of it being a hoax.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Sources of randomness
Date: Sun, 12 Sep 1999 20:20:30 GMT
Mok-Kong Shen wrote:
> Question: How about utilizing sources in the opposite direction,
> i.e. obtaining random bits from apparently periodic phenomena?
Sounds like you want to make the implementation as hard as possible!
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Random and pseudo-random numbers
Date: 12 Sep 99 20:07:14 GMT
Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
: Eric Lee Green wrote:
: > None of these are working for me if I'm wanting my code to run on
: > HPUX, Solaris, or SCO Unix in unattended mode.
: There is (so far as I know) no POSIX-standard true-random generator.
: You can attach a hardware RNG to a serial port, for example, and fetch
: however many random bits you need when you need them; or, if all your
: systems are attached to a net, they could fetch random bits from some
: random bit server that has the appropriate hardware. I think there's
: even a publicly-accessible Internet site serving random bits, if you
: want to trust it.
Since I've claimed in some previous posts that if one wishes to generate
N-bit keys, one *must* have N bits of true randomness prior to generating
the first one, but one _could_, if one has to, use a good pseudorandom
generator of cryptosecure quality thereafter,
I'm going to make a further suggestion, that, instead of making finding a
way to get random bits slowly out of the computer hardware a priority, the
simplest way of meeting this requirement doesn't involve anything that is
not transportable.
Simply require the user to type several lines of random characters at the
keyboard, and use that input as the starting point.
If there are ways to get even 16 true random bits invisibly each time the
program runs, that is well and good, but to get a large quantity of random
bits all at once, I'm afraid looking for timing, disk block number, inode
number, system status and similar information to derive randomness from is
just not going to meet the requirement.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Double encryption is patented (mabey)
Date: 12 Sep 99 20:18:16 GMT
Mok-Kong Shen ([EMAIL PROTECTED]) wrote:
: What does the patent do to get rid of the problem of difficulty of
: having GOOD source of randomness on PC? I don't yet see that the
: patent has contributed anything to the problem of obtaining good
: random bits at all. If anything, isn't an XOR of the blocks and an
: encryption (the Y in my post) serve the same purpose just as well?
: (Please explain with a bit detail. Thanks.)
You're right that the patent doesn't lead to a method for producing
genuinely random bits.
However, the purpose of encryption is to conceal a plaintext unknown to an
adversary. While known-plaintext attacks are considered in evaluating the
strength of cipher systems, this is only because one might know some
messages, but not others, sent with the same key, and thus a
known-plaintext attack can lead to being able to read unknown plaintexts.
So, for any key unique to a single message, we can safely assume that
particular message is unknown to the attacker.
Thus, a key generated from a hash of the message being sent is as useful
as a key that is a true random number.
And if we hash the rest of the message, and XOR the hash with the first
block of the message, then the reciever must perform the hash again to get
the first block of the message. So, not only are we saving on bandwidth,
we are eliminating a possible _subliminal channel_ (if the recipient
doesn't do the hash, but the session key is a block additional to the
message, then the recipient might not confirm the session key is what it
should be, for compatibility with changes in the hash, or its replacement
by real ransom numbers: so, a program that has been tampered with could
leak permanent key information through its choice of "random" IVs or even
session keys).
That's why I explain the scheme in the section of my web site entitled
"Red Thread Resistance" instead of elsewhere.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Random and pseudo-random numbers
Date: 12 Sep 99 20:09:59 GMT
Richard Parker ([EMAIL PROTECTED]) wrote:
: "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
: > There is (so far as I know) no POSIX-standard true-random generator.
: > You can attach a hardware RNG to a serial port, for example, and fetch
: > however many random bits you need when you need them; or, if all your
: > systems are attached to a net, they could fetch random bits from some
: > random bit server that has the appropriate hardware. I think there's
: > even a publicly-accessible Internet site serving random bits, if you
: > want to trust it.
: I am familiar with an internet site called "HotBits" that may be the
: site that you remember. It provides random numbers generated by the
: detection of the beta decay of Krypton-85 by a Geiger-M�ller tube
: detector. Here is the URL:
: HotBits: Genuine random numbers, generated by radioactive decay
: <http://www.fourmilab.ch/hotbits/>
I've had people denounce, in no uncertain terms, the use of FM noise from
a radio reciever as a source of random bits, because the random hiss you
recieve could be intercepted or controlled by an adversary.
So, while this site is useful for many purposes, I think that for
generating keys, it wouldn't be acceptable. (Although I'm not in agreement
that FM noise is unsafe for most purposes.)
John Savard
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Random and pseudo-random numbers
Date: Sun, 12 Sep 1999 20:34:22 GMT
[EMAIL PROTECTED] wrote:
> Simply require the user to type several lines of random characters
Sure, you can obscure the inevitable non-randomness by hashing,
but it is important to realize that humans typing "at random"
really don't do a very good job of randomizing. It is fun to
fit a HMM to the result..
------------------------------
Subject: Re: Mystery inc. (Beale cyphers)
From: [EMAIL PROTECTED] (Curt Welch)
Date: 12 Sep 1999 18:50:53 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> sha99y00000 wrote:
> > I can see your point here, but discussions on the feasibility of it
> > (Beale's] genuineness. How people have attack the problem. What
> > resources have they used etc. etc.
>
> Rowlett, Sinkov, Kullback, and Hurt worked on Beale during their
> training, and Rowlett at least believed it was a hoax.
There's two levels of "hoax" to think about. The first is whether
the story (about the gold etc.) is a hoax, and the second is whether
the cyphers are real, or just ramdom numbers.
It's very possible that the story about the gold is a hoax, but that
the cyphers are real -- i.e., they do contain a message that can
be decoded. So you don't need to believe in the story in order to justify
spending time trying to decode the cyphers. Decoding the Beal
cyphers when no one else over the years have been able to do it would
be a very worthy achievement.
We know that the beal story was published back whenever (17??). There
are still original copies of that published document in existance. We
also know that some of the facts from the story are valid (like the
existance of the town and the tavern). But I don't think much else
is known. So one possible answer is that this entire story was made
up has a hoax just so someone could make money selling copies of the
pamphlet.
Another posibility is that they guy who published the pamphlet didn't
create the cyphers, but did create most of the story. His motive could
have just been to make money selling the pamphlet, or maybe something
more complex. Maybe there was some type of treasure connected to the
cyphers and he made up the story as told in the pamphlet and published
it to try and get others to help him decode the cyphers. The thoeory
being that since only he knew the "real" story behind the cyphers,
only he would be able to correctly interpret the decoded cyphers.
This of course is all very far fetched, but it just points out that
there are various options of how the cyphers could be real even if
the story isn't.
> > 2 Reasons for fake: someone found lines like ABCDEFGHIJKLMN
> > when deciphering #1 with DOI.
> > Why would someone code ABCDEFGHIJKLMN than randomly
> > writing any code numbers to create garbage?
> > Would finding ABCDEFGH, etc. show that some sort of
> > transposition has been used within the code?
>
> Jim Gillogly wrote an article about this in Cryptologia, V4N2.
> Decrypting Beale-1 with the Declaration of Independence produced
> ABFDEFGHIIJKLMMNOHPP. He considers that evidence of a hoax, but
> I don't think it's conclusive.
The odds of it happening by ramdom chance are so small that to ignore
the string would be foolish. But what caused the string and what
it "means" is very much a point of debate.
> If it had been precisely
> ABCDEFGHIJKLMNOP then I would agree it must be a hoax, but an
> "approximately alphabetic" stretch could be found by accident.
Of that length. No way.
> (Gillogly pointed out that the first F and last H could have
> been off-by-one encipherments of C and O, respectively, which
> makes it somewhat more suspicious.)
Yes, it's very easy to justify both errors as off-by-one mistakes. Not
only that, but I believe some of the encoding errors in #2 match
these errors. i.e., a correctly numbered DOI does not decode #2
correctly. You have to make a few adjustments (numbering errors?)
to make it decode correctly. And I belive it is possible to create a
numbering of the DOI which fixes both the decoding of #2 and
the F and H in the string.
BTW, I think there are two alphabetic runs in #1, not just one. The
other one as I recall is much shorter (5 letters?).
This is a very strong indication that the DOI encoding used to decode
#2 was somehow envolved with the numbers in #1.
> I think that anyone who was
> laboriously encrypting garbage for a hoax, once he "got bored"
> and decided to encrypt a stretch of the alphabet, would very
> likely proceed to encrypt various words such as "FOOLED YOU".
Ed Rupp came up with one theory about what could have created the
Gillogly strings. It goes something like this...
Imagine the person encoding #2. He could have created a table of
numbers from the DOI something like this (I don't have the DOI
numbers at hand so I'm making these up):
A 6 12 26 75 102
B 3 16 35
C 13 17 22 24 37 46 49
D ...
etc.
i.e., the numbers used to encode an A are listed on the first line, and
the numbers for B on the second, etc. These all just come from the word
numbers of the DOI.
You could then write the alphabet across the top of this table. Then use
the rows instead of the columns to encode the #1 document. To encode an A,
you would pick 6, 3, 13, etc. So, by doing this, you have created a new
encoding, but you have used the DOI numbers in the processes.
As you encode the #1 document, for each letter, you pick a random number
from the appropriate column. But what if at one point part way though
the encoding, you decide to take the number from the first line. Then
on the next letter, you take the number from the second line, and you
continue working down a line for each consecutive letter.
Doing that would cause the alphabetic strings to appear when the document
was decoded with the DOI! It also nicely explains the duplicate letters.
The encoder either goofed and didn't skip down a line, or he just decided
to use the same line twice.
There are various problems with trying to make this 2-D table theory
actually work. But I think it's an excellent example that shows how the
#1 document could be both a valid cyhper and contain the alphebetic
strings.
But of course it's also a good example of how the #1 document could
have been created as nothing but random numbers. I.e. the person who
created the #1 encoded document just picked random numbers from
the table, and at one point just happened to scan down the table line
by line as he picked random numbers.
In any regard, these Gillogly strings prove to me that the key to
decoding the #1 document is the DOI. Looking for other publications
to use with the same algorithm is not the way to go. Looking for
other ways to use the same DOI numbers is the likely solution to the #1
document.
Personally, I like to think the cyphers are real, even if the story
isn't.
--
Curt Welch http://CurtWelch.Com/
[EMAIL PROTECTED] Webmaster for http://NewsReader.Com/
------------------------------
** 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
******************************
