Cryptography-Digest Digest #57, Volume #11 Sun, 6 Feb 00 03:13:01 EST
Contents:
Re: KEA gains something with RSA instead of D-H (David Wagner)
Re: KEA, and XDH (David Wagner)
Re: polyalphabetic substitution cipher ([EMAIL PROTECTED])
Re: Polyalphabetic en/de-cryption program ([EMAIL PROTECTED])
Re: NIST, AES at RSA conference (Terry Ritter)
Re: NIST, AES at RSA conference (wtshaw)
TLS: What is the purpose of the client certificate request? ([EMAIL PROTECTED])
Re: Key Generation program for Windows? (Steve K)
Re: TLS: What is the purpose of the client certificate request? (Paul Rubin)
Re: Does the NSA have ALL Possible PGP keys? (Dan Day)
text analysis ("G. R. Bricker")
Re: Does the NSA have ALL Possible PGP keys? (Dan Day)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: KEA gains something with RSA instead of D-H
Date: 5 Feb 2000 20:30:55 -0800
Thanks for the great concise description of KEA!
By the way, does anyone have any idea why the final key
g^{xB*rA} + g^{xA*rB} mod p is obtained using addition
rather than, say, hashing the two terms?
Anyway, to answer your question, if I understood correctly,
I think John Savard's idea goes something like this:
A->B: {NA}_PB
B->A: {NB}_PA
(SA,PA are Alice's secret and public keys; Bob's are SB,PB.)
(NA,NB are Alice's and Bob's secret random nonces.)
Now Alice and Bob calculate the session key as K = hash(NA,NB).
His observation is that this protocol also provides a forward
secrecy propery much like KEA does. (I hope John Savard will
correct me if I mischaracterized his idea.)
Presumably you'd want to add extra glue to the protocol to
bind the derived key to this session, e.g.,
1. A->B: {1,A,B,NA}_PB
2. B->A: {2,A,B,NA,NB}_PA
K := hash(A,B,NA,NB,PA,PB)
but the underlying idea should be clear.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: KEA, and XDH
Date: 5 Feb 2000 21:02:55 -0800
In article <[EMAIL PROTECTED]>,
David Hopwood <[EMAIL PROTECTED]> wrote:
> > > Alice: tAB = YB^rA mod p
> > > Bob: tBA = YA^rB mod p
> > > Alice: uAB = RB^xA mod p
> > > Bob: uBA = RA^xB mod p
> > > Alice: w = (tAB + uAB) mod p
> > > Bob: w = (tBA + uBA) mod p
> > > Alice & Bob check that w != 0, and derive a key from it
>
> Does anyone know the reason for the check that w != 0, BTW?
Hmm. Well, yes, maybe, I think I just may see a possible attack that
might justify such a check. Would you check my work?
I'm thinking there's a reflection attack. A misbehaving Bob might
behave like this:
Alice sends her certified public key, YA
Bob sends his purported public key YB, but choosing YB := YA
Alice sends her transient DH contribution RA
Bob sends his claimed transient DH contribution RB, choosing RB := RA
In other words, Bob just reflects Alice's own values back to her.
Note that Bob's public key YB will be correctly certified if Alice's is.
Now Alice will calculate her session key as
w = YB^rA + RB^xA = YA^rA + RA^xA = 2 * g^{xA*rA} mod p.
So far this doesn't look like a problem, but it is the beginnings of
an unpleasant property. Consider what happens if Bob modifies his
reflected answers ever so slightly, so that he chooses RB := -RA mod p
(everything else is unchanged). Then Alice will calculate
w = YB^rA + RB^xA = YA^rA + (-1)^xA * RA^xA = 0 mod p, if xA is odd
So with probability 1/2, Alice will be fooled into thinking that the
key exchange completed correctly with the result w = 0. If Alice now
sends anything confidential encrypted under that key, Bob can read that
traffic; and if Alice trusts data coming in encrypted under w as properly
authenticated, Bob can inject fake traffic.
This is still a reflection attack, so Alice could just as well check
to make sure that the public key she receives is different from her own,
but it still seems like a potentially undesirable property. Who knows,
perhaps there are other variations I overlooked that are far worse...
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: polyalphabetic substitution cipher
Date: Sun, 06 Feb 2000 05:18:20 GMT
In article <87hs1j$d31$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Does anyone know of any tools on the internet to
decipher
> polyalphabetic substitution ciphers -- something
that one:
> - figures out how many alphabets are being used
> - deciphers text accordingly.
> Your help is most appreciated
>
If you consider just one example, the Vigenere
cypher, the only tools you need are paper and
pencil. A computer program would be overkill, in
my view.
lobert@aol
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Polyalphabetic en/de-cryption program
Date: Sun, 06 Feb 2000 05:22:46 GMT
In article <eV0n4.1069$[EMAIL PROTECTED]>,
"Andersen" <[EMAIL PROTECTED]> wrote:
> Does anyone know a pc program which can encrypt and decrypt plain text
by
> the polyalphabetic method as I need to create some exaples using that
> method.
>
> /sa
Do a net search for CipherClerk. You can probably find a link for it at
the Crypto Drop Box. If not, Google it.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Sun, 06 Feb 2000 06:11:05 GMT
On Sat, 05 Feb 2000 05:48:25 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>On 4 Feb 2000 16:27:07 -0800, [EMAIL PROTECTED]
>(David Wagner) wrote, in part:
>
>>Yes, sure, but Terry Ritter claimed that multiple ciphering is
>>strictly *stronger* (i.e., >, not just >=). Such a claim is, as far
>>as I can see so far, unsupported.
>
>I don't think he meant to say that it was proven strictly stronger,
>but simply that from a practical point of view it is very likely to be
>so (particularly when one uses three layers, to take into account the
>meet-in-the-middle attack) with reasonable choices of ciphers.
I do mean that multiple ciphering is strictly stronger, although
debate seems a waste of time: The proven increase is an infinitesimal
delta, so we would inevitably end up talking about complete
irrelevancies.
In practice, I think we all know that a cipher which cannot be
attacked in the most favorable ways is in some sense "stronger" than
it would otherwise be. But talking about this requires some form of
*measure*; I think the obvious measure of strength is the time and
effort required to take ciphertext to plaintext.
Note: Any (non-null) cipher takes *some* time to take ciphertext to
plaintext. So ciphertext has *some* strength, even if the opponents
can break the cipher, and even when they know the key. And strength
is contextual, depending upon the opponents, what they know, and what
their resources may be. Not only do we not know what those strength
values are; we *can't* know what those strength values are. The same
cipher can and will have different strengths to different opponents.
(That cipher strength is contextual seems at the root of some of the
problems in these discussions. The strength of a cipher with respect
to academic cryptanalysts is not the same as its strength with respect
to a well-funded group of dedicated opponents.)
In practice, the major strength "increase" from multi-ciphering seems
to involve protecting individual ciphers from attacks: When the
opponents start out to break a 3-cipher stack, none of the ciphers are
broken. The opponents thus must attack one of those ciphers *without*
using known-plaintext, and that is a big limitation. This strength
increase is not a mathematical sum or product of the cipher strengths.
Three cipher layers seem to make sense in that the whole point of this
is to protect against cipher weakness. If we assume one of the
ciphers is broken, then we still have a 2-cipher pair remaining in
which each still protects the other.
>I know alternating between a practical viewpoint, and saying that
>AES-class ciphers are necessarily inadequate because they can't be
>_proven_ strong, is both kind of confusing and open to criticism...
Yeah, I suppose it would be "confusing and open to criticism," were I
doing that. But since I am not, it is irritating to find that I get
the criticism anyway.
I do not and never have claimed that ciphers were "necessarily
inadequate because they can't be *proven* strong." That is something
you guys came up with, not me. I suppose you define "adequate"
differently than I do. By your definition, there will never be an
adequate cipher or ciphering system. I suppose that means to you that
there is no point in trying for anything better, so we might as well
accept what we have, which frankly is not acceptable to me.
I guess I'll try a different way to explain this and maybe we'll move
on just a little bit: It is claimed that I think "AES-class" ciphers
are inadequate. I would instead say that all ciphers are risky and we
cannot trust any cipher. Because there is no trustable cipher, we
need to concern ourselves with possible cipher failure. We need to
think about the amount of plaintext subject to such failure, and what
we can do beyond the cipher itself to reduce the probability and
consequences of such failure. Since we will not know of cipher
failure, everyone might happily use a broken cipher for years on end.
But I have made these points many times, so now let's see what *you*
have:
On what basis do you assume that "AES-class" ciphers *are* adequate?
What is your reasoning?
My view is that such a claim cannot be supported by fact and reason.
And I claim that cryptography has a product dynamic which is distinct
from any other product; we cannot expect the experience we have using
and surmounting faulty software to work with ciphers.
I claim the AES process is not fundamentally different from any cipher
design process: We have smart people, but that hardly makes their
designs perfect. We have some volunteer testing going on, but even
the best possible testing may not unmask weakness. We have ciphers
which our academics cannot break, and -- somehow! -- the assumption is
made that the result will be good enough for society to use against
our unknown opponents with unknown capabilities. What facts and
reasoning warrant such an assumption?
"Everybody thinks so," is not reasoning.
"That's the way it was done before," is not reasoning.
"There is no other choice," is not reasoning.
>but there is really only one gap in Terry Ritter's argument. The only
>missing link is some grounds for considering the AES candidates as
>likely to be inadequate, or in need of additional reinforcement, from
>a _practical_ point of view as well. Everything _else_ falls into
>place neatly enough.
>From a practical point of view, it is easy to imagine that any
particular cipher may have a flaw in its design. A group of analysts
working in secret and concentrating on the problem might well find a
flaw where our academics found none. And if all of our data are
protected by that broken cipher, then none of our data will be
protected, and that could continue for years.
On a similar topic, there is a letter to the editor about my earlier
guest column in IEEE Computer magazine, plus my response, in the
current issue. But it probably contains little that has not been said
here many times.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: NIST, AES at RSA conference
Date: Sun, 06 Feb 2000 00:12:26 -0600
In article <uu1Al6Dc$GA.333@cpmsnbbsa03>, "Joseph Ashwood"
<[EMAIL PROTECTED]> wrote:
....
>
> > Evidently some of Ritter's comments are so valuable that
> he is censored
> > from plain distribution of his posts on these matters to
> all quadrants.
> > It is not cute to treat him this way; it is wrong to do
> so, to him or
> > anyone else.
>
> If I ever attempt to be "cute" I won't do it on this NG, my
> statements were specifically to establish a direct
> contradiction to a statement that may or may not have been a
> misinterpretation of Ritter's comments. In addition I see no
> reason to take any person's word as gospel, I insist on
> taking the time to consider if there are any simple
> contradictions, and often the time to see if there is a more
> complex contradiction. In this case the contradiction was
> easy and simple to understand. If you are going to take
> someone's word as gospel without giving consideration to the
> obvious and complete contradictions that are presented, I
> would appreciate it if you would take those comments to
> private e-mail, I will no longer respond to this thread on
> the newsgroup.
You take too much as personal when it isn't. You should note that some of
my comments were more for the consumption of others. I am thankful that
you want to discuss these issues, but it is a public conversation that
makes it rather more than two sided, and is not meant to inflame. Please
accept my apologies if I led you to think differently, not my intent.
Especially note that *cute* is especially directed to those referenced for
doing some cowardly things in the same paragaraph, surely not you, as far
as I know.
I respect Ritter, but we do have differences on some issues. I do give
him the benefit of the doubt much of the time because of his scholarship,
depth of thought, willingness to create, and integrity. But, he is not my
parrot, nor me his.
Where I aggree with him, I will gladly say so, and otherwise with candor.
Should we not expect that here?
--
A big-endian and a little-endian have been spotted sitting at a
campfire nibling on bytes and pointing at each other as they
argued about who got hit with the most errors.
------------------------------
From: [EMAIL PROTECTED]
Subject: TLS: What is the purpose of the client certificate request?
Date: Sun, 06 Feb 2000 07:02:46 GMT
Hi,
I've got some doubts regarding the TLS 1.0 client certificate request.
Basically, the server can *optionally* request a client certificate from
the client. What is the purpose of doing this? The pre-master secret is
encrypted using the public key of the server cerficate. Is the purpose
of the client certificate only to authenticate the client? If this is
the reason, how does one authenticate the user??
I'm really confused about the above. Could someone help me out...
Thanks a ton,
With Regards,
Anuj
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Key Generation program for Windows?
Date: Sun, 06 Feb 2000 07:23:57 GMT
On Sat, 05 Feb 2000 17:07:50 GMT, [EMAIL PROTECTED] (Steve K)
wrote:
>This is not exactly what you wanted, maybe, but I think it's a pretty
>OK work around: You can use any decent crypto program for text, as a
>strong pseudo-random number generator with (typically) 64 bits per charachter of
>entropy
WRONG! And might I add, "Oops."
That's 7 bits of entropy, not 64, because 2^7=64. So the numbers are
really:
7 x 8 = 56 bits per 8 bit password, which gives
2^57 minus one = 144,115,188,075,855,871
unique 8 charachter pass phrases.
Nowhere near as big a number as I dumbly dreamed up for the previous
post, but still totally adequate for what most 8-letter passwords are
used for-- user passwords on services whose admins would notice a
brute force attack in progress. Nowhere near good enough for things
like crypto keys, or their pass phrases.
It also occurs to me that you might want to play with polyhedral dice.
They are available from hobby shops or search the net for "Dungeons
and Dragons". A handful of these and some graph paper would make
generating near-random outputs for any chatachter set a snap.
For instance, with a single cube, you can roll twice and get lower
case alphabet plus digits 0 to 9, a little over 6 bits of entropy per
charachter:
1 2 3 4 5 6
____________________________________________
1 a b c d e f
____________________________________________
2 g h i j k l
____________________________________________
3 m n o p q r
____________________________________________
4 s t u v w x
____________________________________________
5 y z 1 2 3 4
____________________________________________
6 5 6 7 8 9 0
____________________________________________
:o)
Steve
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
PGP key 0x5D016218
All others have been revoked.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: TLS: What is the purpose of the client certificate request?
Date: 6 Feb 2000 07:24:31 GMT
In article <87j6am$97b$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Hi,
>
>I've got some doubts regarding the TLS 1.0 client certificate request.
>Basically, the server can *optionally* request a client certificate from
>the client. What is the purpose of doing this? The pre-master secret is
>encrypted using the public key of the server cerficate. Is the purpose
>of the client certificate only to authenticate the client? If this is
>the reason, how does one authenticate the user??
Yes, the server certificate authenticates the server and the client
certificate authenticates the client. I don't understand your final
question about authenticating the user.
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Sun, 06 Feb 2000 07:55:36 GMT
On 02 Feb 2000 09:19:28 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
>Clearly I can do the same with the number that I make
>out of the sum of all PGP keys. Let's call it "PBN"
>(Pretty Big Number). The universe is too small to
>write down PBN in binary, decimal, or hex, but you
>can write down PBN in base PBN with ease. it's "10".
And what do you do when someone comes along and
asks, "what number base was that, again?"
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: "G. R. Bricker" <[EMAIL PROTECTED]>
Subject: text analysis
Date: Sun, 06 Feb 2000 07:55:03 GMT
I posted a couple of weeks ago. I had asked if anyone knew of some good
text analysis software. Thanks for the replies. However, none of the
programs which various respondents mentioned were really up to the task.
Perhaps I need to dust off my programming skills. Or unearth them (it's
been a LONG time). What has whetted my appetite is the Code Book Challenge.
I progressed to stage 3 and thought, damn, I know I want to group these
symbols somehow. I want to identify whether Q represents a letter and P
represents a letter, or instead if QP is a letter. So I sat down with a
glass of wine and a pad of paper. I ran out of wine before I ran out of
paper. Pretty much shot that session. So, I peeked ahead to stage 4. Ahh, a
Vignere cipher. This time I managed to get the job done.
But then I peeked farther forward into the later stages and despaired.
Remembering Turing and the story of breaking the Enigma, I realised that I
needed a program (or series of programs) do perform the following analyses
:
1) total character count (easy) and frequency
2) word count (if there are separated words) and frequency
3) count and spacings of pairs and triplets of words (which would be
useful
for homophones, Vigneres, and other types of ciphers).
4) a program to build chains of relationships (q is always followed by u,
z is never preceded by k, etc.).
None of these programs would crack a code, per se, but they would lead you
in the correct direction. Particularly if you don't know what kind of code
you're up against.
Now I'm sure there are some decent programs out there which can perform 1,
2, and 3. But he ones I have tried are not particularly good (and only
perform 1 and 2 at best). It seems as if most of the text analysis programs
out on the web were designed for literary analysis (did Bacon write
Shakespeare's plays?), and not for amateur crypto buffs.
So my point is this. I'm begging once more for any knowledge of decent
programs. If none are out there, I'll write my own. If I'm forced to write
my own, are the any other basic features that I should include other than
1-4 above?
Sincerely praying I won't need to program again,
George
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Sun, 06 Feb 2000 08:05:25 GMT
On Tue, 01 Feb 2000 15:25:03 +0000, Johnny Bravo <[EMAIL PROTECTED]> wrote:
>>My suspicion (admittedly without solid basis) is that the government
>>probably has people working day and night on the problem, and undoubtedly
>>has algorithms that CAN break encoded messages in finite time, but that the
>>time involved is still sufficiently long so as to make the routine intrusion
>>into every pgp message prohibitively costly.
>
> Or more likely they can't, but they don't need to. Is your home TEMPEST
>shielded? I seriously doubt it. The government can park a van outside
>your building and read everything on your screen, every keystroke you
>make. If they thought you were worth the effort, they would do so.
>
> That is the bottom line, the vast majority of us aren't worth it. The
>government doesn't give a damn what is in my email, encrypted or
>otherwise.
But that's why the cracking of PGP would be so significant...
Yes, you're right in that the government is not going to bother sending
a truck full of electronics to your street, just so that they can eavesdrop
on your communications.
No, that doesn't mean that breaking PGP wouldn't be a disaster for
privacy.
Breaking PGP (or other popular personal encryption) suddenly means that
they don't *need* to expend a lot of manpower to snoop into your
privacy. They can just sit there with their existing eavesdropping
hardware on communication trunk lines, and read EVERYTHING with a
keyword-triggered computer. That's an entirely different level of
snooping, one that makes it so easy for them that the attitude is
bound to be, "why the hell not -- let's just scan it ALL". That would
*not* be the case if they had to resort to sending a truck out to
every address in the country...
Yes, if they're really after you in particular, they'll get you.
But the big question is, can they get you without even going after
you in particular in the first place? *That* is the situation if
PGP is broken (or whatever privacy method you currently use).
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
** 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
******************************
