Cryptography-Digest Digest #939, Volume #9 Mon, 26 Jul 99 16:13:04 EDT
Contents:
Re: RSA public key (DJohn37050)
Re: hush mail (Anton Stiglic)
Re: The Gnu Privacy Guard ? (SCOTT19U.ZIP_GUY)
Re: RSA public key (DJohn37050)
Re: I wonder why he wrote it that way. (Jacques Guy)
Re: RSA public key (Patrick Juola)
Re: Advances in Cryptology 1981--1997 (Francois Grieu)
XOR now explained on web site! (John Savard)
Re: RSA public key (DJohn37050)
Re: OTP export controlled? (Jim Gillogly)
Re: another news article on Kryptos (Jim Gillogly)
sorry :) ([EMAIL PROTECTED])
Re: What I think is B.S. about the X.509 . Please encrypt the certificate!
(Matthias Bruestle)
Re: What I think is B.S. about the X.509 . Please encrypt the certificate!
([EMAIL PROTECTED])
Re: message digest problem? (John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: RSA public key
Date: 26 Jul 1999 14:16:03 GMT
This is the "chilling" flaw in a random number generator. With RSA, there is a
grey area where it is hard to detect such an error. For example, FIPS 140-1
specifies some RNG tests. It is possible to pass those tests, but generate RSA
keys that are insecure as they share a prime.
Don Johnson
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,alt.privacy,alt.security.keydist
Subject: Re: hush mail
Date: Mon, 26 Jul 1999 10:59:53 -0400
fungus wrote:
> Anton Stiglic wrote:
> > 128 bit is equivalent to 16 ASCII caracters, it's a bit better then an
> > 8 ASCII caracter password on UNIX, but still....
>
> In what way a "bit better"???
>
> I'd say that squaring the attack time is more than "a bit better".
Yes, you are correct, brute force attack on the passwords would be most
likely impossible for
the time beeing (sorry for any confusion, always happy to see how posters jump
on someone if
say something wrong ;). But brute force attack on the passwords is not the
solution here,
the initial secret is a passphrase, wich is transformed into a password, wich
is hashed
to something we will call h. Finaly, a _part_ of h is taken for
validation. The hash
function used is SHA, wich produces a 160 bit message digest. I don't know
how
big a part of that they take, depending on the size they take, brute force on
that could
(or could not) be directly applied.
There may also exist other loop holes, using this technic, wich can be broken
with something
more intelligent than brute force.
Anton
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: The Gnu Privacy Guard ?
Date: Mon, 26 Jul 1999 16:07:19 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
>--------------9736BD3942835C87E94A0987
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>
>Hey all...
>
>What do you all think of the Gnu Privacy Guard, also known as GPG ? It
>is intended to be a freeware version of pgp sponsored by the Free
>Software Foundation as part of the GNU system. You can check out this
>web page for more information. Any input regarding the quality of this
>would be very appreciative.
>
>
>http://www.gnupg.org
>
Well Spike I took a very quick look at it. I like the concept of a
GNU group working on a public key encryption. But if I am not
mistaken it still uses CFB mode encryption and still in the first
few blocks incorparates a method so users can tell imediately
that they have the wrong session key. Those features seem to
be fixed as they where in the early PGP. I can't say about later
PGP since it is no longer DOS. But I feel these two features
may make the task of the NSA types several orders of magnitude
easier. Again I am talking about the actual encryption that gets
used on the data. There really are not many options for the public
key part. I guess we just have to hope there is no easy break in
them.
However I for one would like to see more chaining modes. I would
even like to see the possiblity of a wrapped PCBC type of chaining
and would like to see an option to drop the quick session key
check which can only weaken the over all system.
Thanks for sharing the news about GPG.
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: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: RSA public key
Date: 26 Jul 1999 16:07:23 GMT
The point is that an RNG can pass FIPS 140-1 tests and generate RSA keys that
can be broken. Testing RNG is hard. With crypto, one wants assurance that
things are going right, not just that one cannot see anything wrong. An RNG
might be "chilled" due to a spec of dirt on a mask, for example, in
manufacturing. If it outright fails, I can detect it, it if is chilled maybe
not.
Don Johnson
------------------------------
Date: Mon, 26 Jul 1999 09:30:06 -0700
From: Jacques Guy <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: I wonder why he wrote it that way.
JOE wrote:
>
> Rongorongo has been deciphered by S. R. Fischer
No. Fischer *claims* to have deciphered them. He has not.
If anyone is entitled to make such a claim it is Yuri
Knorozov, who, in 1956, identified a series of glyphs
on the Small Santiago Tablet clearly compatible with
a genealogy. In fact, it is difficult to imagine how
they could be anything but a genealogy. See:
http://www.geocities.com/Athens/Delphi/8389/geneal.htm
Those signs, interpreted using Fischer's method of decipherment,
yield utterly absurd readings: [A] copulating with [200] produced
[A], [B] copulating with [200] produced [B], etc...
For a dissection of Fischer's decipherment see my article
in Anthropos vol.93:552-555 "Does the Santiago Staff Bear
a Cosmogonic Text?" (September 1998). And for an alternative
interpretation of the Santiago Staff, based on Knorozov's
finding, see "Probable Nature and Contents of the Santiago
Staff", Rapa Nui Journal, vol.12(4):109 (December 1998)
> the very same fellow who
> did the Phaistos disk.
Another vacuous claim. The text turns out to be archaic
Greek (surprise! surprise!), a very strange archaic
Greek, where declension and conjugation
endings are haphazard, and the diachronic phonology
of which is even stranger (read: "impossible").
> >[EMAIL PROTECTED] (wtshaw) wrote, in part:
> >
> >>The strangest statement in the book, which really leaves me grinning and
> >>crying with laughter occurs on page 553, "Rongorongo consists of tiny,
> >>amazingly regularly formed glyphs about 1 centimeter high and 10
> >>millimeters wide."
> >
> >Since Rongorongo isn't a cipher, but a language - specifically, the
> >lost script of Easter Island - extant examples indeed could have a
> >specific size. However, I will have to agree that it's odd to change
> >units of measurement to describe something square...(and it isn't even
> >right, the glyphs are taller than wide)
It's just poor proof-reading. I had lengthy exchanges with Wrixon, about
the rongorongo, the Phaistos disk, and the Voynich manuscript. There
is another, annoying, mistake: he describes the Easter Island statues as
"wooden", when, in fact, they are made of stone (volcanic tuf) as
everybody knows. An unfortunate slip of the pen, that's all.
Mind you, Paul Bahn, Fischer's PR agent, goes two better in his
14 Feb 1998 tout in New Scientist ("Who's a clever boy, then?").
There, he writes of "Crete's Phaistos Disc of 1600 BC, a large, carved
stone disc". Well, this "large" disc is 15cm across (6 in.), the "stone"
is very fine baked clay, and the "carvings" are *stamped*. The only
thing
he got right is that the disk is not pyramidal! In comparison, Wrixon's
mistakes are insignificant.
> >Of course, the main claim to fame of Rongorongo is its uncanny
> >similarity to the Indus Valley script.
Hevesy's claim, circa 1930. But half of the rongorongo glyphs
he claims simply DO NOT EXIST. They are his fabrications. Grab his
original article and go there, where the whole corpus and list of
rongorongo glyphs are, and see for yourselves:
http://www.rongorongo.org
As for the size of the rongorongo glyphs, their height is usually
constant, but their widths vary. Some are narrow, some square, some
wide.
Jacques Guy, better known as Frogguy in Voynich circles.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: RSA public key
Date: 26 Jul 1999 12:18:42 -0400
In article <[EMAIL PROTECTED]>,
DJohn37050 <[EMAIL PROTECTED]> wrote:
>The point is that an RNG can pass FIPS 140-1 tests and generate RSA keys that
>can be broken. Testing RNG is hard. With crypto, one wants assurance that
>things are going right, not just that one cannot see anything wrong. An RNG
>might be "chilled" due to a spec of dirt on a mask, for example, in
>manufacturing. If it outright fails, I can detect it, it if is chilled maybe
>not.
And again I ask : is this a realistic threat? Why is this more
worrisome than the possibility that the RNG might be generating bad
session keys or that a radium source might suddenly emit a stream of
all zeros for your OTP?
Talking about "might be" situations is meaningless unless you've got
a scenario in mind that's more likely than all the molecules in my
underwear suddenly leaping a meter to the left.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: Advances in Cryptology 1981--1997
Date: Mon, 26 Jul 1999 19:15:45 +0200
[EMAIL PROTECTED] (CryptoBook) wrote :
> ADVANCES IN CRYPTOLOGY 1981-- 1997: Electronic Proceedings and Index
> of the CRYPTO and EUROCRYPT Conferences 1981 -- 1987
Is it 1981 -- 1997 or 1981 -- 1987 ?
Sounds like a must, anyway.
Francois Grieu
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: XOR now explained on web site!
Date: Mon, 26 Jul 1999 16:22:00 GMT
Yes, at
http://www.freenet.edmonton.ab.ca/~jsavard/tele03.htm
I have added, for the sake of completeness, inspired by a recent
posting, a description of what an XOR operation is.
Also, on that page, I've added a chart showing the reasoning behind
the allocation of the 5-level codes to reduce wear and tear, based on
a common 5-level test tape.
And elsewhere, at
http://www.freenet.edmonton.ab.ca/~jsavard/pp010103.htm
I've added the full Vigenere chart, in an effort to explain other
simple concepts analogous to XOR, as well as a modulo-10 addition
chart, a Porta chart, and a table for my "Better Gronsfeld" of a
recent post.
At
http://www.freenet.edmonton.ab.ca/~jsavard/intro.htm
I've made the repeater pennants longer, but I'll be changing them
back, as that change was an error. While there is a web site giving a
number of old signal flag arrangements, it doesn't include one of the
more famous ones, the flags used by Nelson at Trafalgar; I'm getting
ready to add them to the chart soon. However, I'll have to try to find
a reference again, as I don't know what the 2nd repeater looks like in
those old flags.
I've taken the page at crypto.htm and put it back to entry.htm; now,
crypto.htm is simply a "splash page" that points only to index.html,
thus taking new visitors through the counter. The look of the home
page, index.html, has been considerably changed in an effort to look
more visually appealing...further changes, such as splitting the page
up into smaller pages, and showing some of the diagrams from the pages
inside, are likely in the near future.
Also, you may have noticed that a while back, I've changed the colors
of the backgrounds to minimize any problems with text readability.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: RSA public key
Date: 26 Jul 1999 17:29:28 GMT
I do not know what is so hard to understand. An RNG can be flawed thru a
manufacturing defect or a deliberate act. An RNG is difficult to test, due to
the nature of the output.
How does one know if one is using a flawed RNG?
One answer is: I do not know, but it seems rare, so I will ignore the
possibility. This seems risky to me, maybe not to you. You are free to use
it, I may want more assurance, perhaps my application is more critical or I
care about my money more than you. Another answer is to try to provide
assurance that this flaw did not occur. It is a cost/benefit decision.
Some types of flaws can be detected by doing FIPS 140-1 tests. Some cannot be.
It turns out the chilling flaw in an RNG is very difficult to detect when using
RSA but is not that difficult to detect when using DL/ECC systems (check for
dup. public key).
So I ask you, a bad guy in a manufacturing plant chills an RNG. How do you
know this did or did not happen? Your life, your choices.
Don Johnson
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OTP export controlled?
Date: Mon, 26 Jul 1999 09:50:22 -0700
David C. Oshel wrote:
> Somewhere on the net is Che Guevara's pencil-and-paper version of the one
> time pad. Close observation between how that system actually worked (it
> was responsible for hours of fun SWL from Radio Havana Cuba back in the
> '70s), and how XOR-ing random bytes against 7-bit ASCII text is nothing
> like that, is pretty interesting.
Thanks for the pointer. I was able to AltaVista the page from your
description. It turns out to be:
http://icewall.vianet.on.ca/pages/dwyerj/che.html
He used a monome-dinome system (aka "straddling checkerboard") to reduce
the text to digits, then a shared OTP of digits to encrypt it. I haven't
tried analyzing the string of digits given in the JPEG to see whether it
has an "obvious" generator, but that would be an interesting exercise.
The monome-dinome block is based on a keyword, but if the OTP is random
this doesn't compromise the operation: just a convenience to get to digits.
Monome-dinome is particularly nice since it doesn't expand the plaintext
very much as it goes from letters to digits.
--
Jim Gillogly
Mersday, 3 Wedmath S.R. 1999, 16:43
12.19.6.7.1, 6 Imix 9 Xul, Sixth Lord of Night
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: another news article on Kryptos
Date: Mon, 26 Jul 1999 09:59:44 -0700
Mok-Kong Shen wrote:
> Jim Gillogly wrote:
> > Yes. One of my three leading candidates is polyalphabetic substitution
> > (like Kryptos-I and Kryptos-II) followed by transposition (like K-III).
> > This would be an interesting "closure" of the methods used previously.
> > I don't know whether this would qualify under Scheidt's appellation of
> > "a whole different ball game", but it would certainly be much more
> > challenging than either taken separately.
> Just a question (independent of Kryptos): Is is better to have
> polyalphabetic substitution followed by transposition or the
> other way round? Or is it indifferent? Why?
I'd say it's better to substitute first and transpose second, because
it's easier to diagnose a transposition cipher than a polyalphabetic.
If it's transposition first, then polyalphabetic, you can try solving
the polyalphabetic for something that gives not only a good index of
coincidence for English, but also that has the right individual letter
frequencies for English. If you're going the other way, when the
transposition is unwound correctly, you then need to nearly solve the
polyalphabetic to see whether it's the right one. If it's a long
text with a shortish key it will be obvious (though still more
expensive than recognizing a transposition), but if it's a short text
and a longish key, even incorrect transpositions will result in ICs
that give false positives that need to be checked before moving on
to the next transposition candidate.
> If the unsolved part is really 'a whole different ball game', then
> I suppose that there is practically nothing left (after excluding
> substitution and transposition) in the realm of classical methods
> excepting perhaps code book, which seems to be quite unlikely, I guess.
You can have substitutions and transpositions that are a whole
different ballgame from what's gone before in Kryptos. I've seen
no reason to change my top three candidates from the first time I
posted them here. In no particular order, they're some form of
autokey, some form of running key, and some form of combined
polyalphabetic with transposition.
Sure wish we had more ciphertext!
--
Jim Gillogly
Mersday, 3 Wedmath S.R. 1999, 16:51
12.19.6.7.1, 6 Imix 9 Xul, Sixth Lord of Night
------------------------------
From: [EMAIL PROTECTED]
Subject: sorry :)
Date: Mon, 26 Jul 1999 18:18:31 GMT
thanks, jorge
------------------------------
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: What I think is B.S. about the X.509 . Please encrypt the certificate!
Date: Mon, 26 Jul 1999 16:14:30 GMT
Mahlzeit
Dirk Mittler ([EMAIL PROTECTED]) wrote:
> Surely there must be better protection. I know that without a certificate
> authority, or a ?recipient? authority, the reader or sender doesn't know if
> he or she has a valid public key.
There is also the Web-Of-Trust-Model of PGP where youself decide
whom you trust and whom not. If you handle it very stringent the only
"certificate authority" are youself.
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
Schnittchen-Schneider mit den elastischen Beilen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: What I think is B.S. about the X.509 . Please encrypt the certificate!
Date: Mon, 26 Jul 1999 18:25:56 GMT
"Dirk Mittler" <[EMAIL PROTECTED]> wrote:
> The certificate is basically a data structure that can be read (wow!).
It
> includes a certificate authority, serial number, RSA decryption key,
and a
> type of data signature of the whole document. I'm realising as I try
to read
> this that given some mathematical, cryptologic knowledge, someone can
> encrypt a document and provide their own public (in this case
decryption)
> key, as well as a whole forged certificate.
Nope. Find out about that "type of data signature
on the whole document".
[...]
> But what I would at least expect is that the certificate itself would
again
> be encrypted.
Encryption prevents disclosure. Signature prevents
forgery or modification. Certs are signed, not
encrypted, just as they should be.
If you want to know what's really B.S. about X509,
see Peter Gutmann's "X.509 Style Guide" at
http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: message digest problem?
Date: Mon, 26 Jul 1999 19:53:49 GMT
Bill Lynch <[EMAIL PROTECTED]> wrote, in part:
>so he suggests adding 'session-specific' data and incorporating it into
>digest. So now, we send the username, a random number and a timestamp
>(all plaintext) to the server.
>So my question is -- isn't this second method still vulnerable to
>attack? Since the name, random number and timestamp are all sent
>plaintext to the server,
Well, the server *could* check the timestamp, to see if it's the
correct time. That would be sufficient to thwart most replay attacks.
However, the correct way to do this is to have the *server* think of
the random number and send it to the terminal where the password is to
be entered.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
