Cryptography-Digest Digest #420, Volume #9 Mon, 19 Apr 99 03:13:05 EDT
Contents:
How Many Sniffers? ("Charles Booher")
Re: Question on confidence derived from cryptanalysis. ("Douglas A. Gwyn")
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(wtshaw)
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(wtshaw)
Re: Adequacy of FIPS-140 (wtshaw)
Re: Extreme lossy text compression (D. J. Bernstein)
What is E0~E3 Algorithm.? ("Kim. Jae-Yong")
Re: AES Competition (wtshaw)
Re: FSE-6 Report: Slide Attack (wtshaw)
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(wtshaw)
Re: Question on confidence derived from cryptanalysis. (Terry Ritter)
Re: SNAKE#13 (Thomas Wu)
----------------------------------------------------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: How Many Sniffers?
Date: Sun, 18 Apr 1999 21:30:20 -0700
How Many Sniffers does NAI sell to the NSA and the FBI?
How Many Sniffers does IBM own?
How Many Sniffers does HP own?
How Many Sniffers does Cisco own?
How Many Sniffers does 3Com own?
How does NAI keep paying the rent on the red granite building and the
salaries of all the idiot VP's who are mostly a bunch of semi-retired FBI,
NSA, and Military hacks?
If only we could get a good look at the books at NAI.
I wonder what kind of interesting things we could discover.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Question on confidence derived from cryptanalysis.
Date: Mon, 19 Apr 1999 05:16:48 GMT
Geoff Thorpe wrote:
> perhaps this is because you're a little disgruntled with what you
> clearly see as ivory tower academics who don't measure up to the
> military resources or the hard-working "non-academics" of the world?
> Who knows. I certainly have no time for such cold-war style
> conspiracy theories - that somehow the knowledge present in
> military/intelligence agencies or foreign unstable countries (do the
> US still call them "commies"??) is probably so far distanced and
> disimilar to what is available in the open as to make work,
> developments, and failures (to break ciphers) in the open completely
> irrelevant when considering "the enemy"'s corresponding work.
It depends on who you conceive the potential "enemy" to be.
For many perfectly decent people, their own governments can
become their enemies; history gives us many instances of this.
While the cryptanalytic bureaus of most third-world countries
might not be very advanced, the one in the US certainly is.
Therefore, it is quite appropriate to be concerned with
*provable* security instead of "nobody in academia has a
clue" security. The former should, if properly applied,
stand up against *any* enemy, while the latter stands up
only against, shall we say, amateurs.
(I'm not suggesting that academics haven't made useful
contributions to the state of the art, just that their
work does not define the total state of the art.)
> Mathematical problems - that is what I was referring to ...
Yes, cryptology is largely applied mathematics, but
practical cryptanalysis has evolved in the context of
operational experience that is largely unavailable to
outsiders, and that has caused a substantial difference
between insiders and outsiders in their aims and methods.
Some problems, like efficient factoring, are obviously
relevant, and unlikely to be achieved in secret without
happening in the outside around the same time. Other
breakthroughs have been kept secret for decades, in some
cases. So there really is reason to fear that the most
advanced "enemies" might know how to easily crack some
system you use that appears uncrackable to all outsiders.
> But I will highly ticked off if someone discovers that despite
> years of cryptanalysis, it's actually easy to break [3DES] using
> well established techniques and we should have spotted it before
> (and the military already had).
There is a significant difference between what is "well
established" in long-existing, well-funded cryptologic
organizations and what is "well established" in the
dispersed, high-turnover-rate academic community.
There is a big problem in working in *applied* fields
academically, since it is harder to get academic
respect from publication of application or tutorial
papers instead of research papers. There are many
technologies that are well-known *in general* in the
research community, but their specific application to
cryptology is *not* well known.
> We all know that risk - it's the probabilities that are open to
> debate. ...
More precisely, the likelihoods.
The nice thing is that *relative* likelihoods can be estimated
and used to make decisions; e.g. "I need a cipher that <meets
certain requirements> -- pick one."
If the consequences of not making a decision are sufficiently
severe, then even an uncertain decision can be better than
letting the uncertainty stop you from making a decision.
> Me, I'm going to stick with RSA and triple-DES for a while.
In a well-designed cryptosystem, these do seem sufficiently
secure against realistic threats for the near future. Any
vulnerabilities would most likely occur elsewhere in the
system/protocols, not in these encryption algorithms as such
(assuming of course a long RSA key, and 168-bit 3DES key).
> Exactly why do you, or many other designers, put multiple
> stages in a cipher design. I'm guessing it's so that the
> cipher is at least as strong as the strongest element in
> the chain ...
That seems to be part of Ritter's aim, but others seem to
think that during cryptanalysis the stages have to be peeled
like an onion, and they assume that there is not enough
pattern available at the next-to-outermost layer for there
to be any chance of peeling the outer layer off.
> And this can't be achieved within ONE cipher? When you start talking
> multiple algorithms, you instantly start talking interoperability
> and standardisation headaches.
That's a significant concern, because breakdowns in operational
procedure often provide the enemy analyst the entering wedge he
needs to crack a system.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Sun, 18 Apr 1999 23:36:51 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> > Ah, elections do come up at some point. As I remember, the final
> > pick is to be submitted to higher, political, authority for
> > *approval*, which is apt not to be a technical decision ...
>
> The technical decision would already have been made, and any
> further process would be simply an approve/disapprove decision.
That is an easy prediction for a technical person. In politics, the rule
is there are no rules, except that rules of more equal for those who
contribute to the right people.
>
> I don't know what "elections" have to do with it. You can't
> think that the electorate in general cares one whit about AES.
End decisions are to be made by political cronies. My reference to
elections suggests that we should all get involved in the political level
as well if we want the best AES, such that it is, to come forward.
Getting involved means getting closer to actual candidates and
spotlighting the various crypto related issues to them. You can't be just
a technician any more and be responsible.
--
A new random permutation generator: You put X windoze
machines in a room, merely start them up, and record the
order in which they eventually crash on their own.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Sun, 18 Apr 1999 23:50:41 -0600
In article <7fcn7v$3nv$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> Since when has the "All-or-nothing logic" been considered as a fallacy
> or what have you been smoking.
It's bigger than mere crypto, it applies to all logic. Formally, the
concept was presented to me eons ago in Freshman English, but I was
already familiar with the concept, with the others that go along with it.
It's also put in the wisdom of not putting all your eggs in one basket,
which is rather a historically known truth.
> I am sure that would be news to Mr R. of RSA fame.
He surely is a nice fellow, but I am also pretty sure he is liberally
educated in basic logic as well.
> All or nothing encryption has not been around very long and is not
> something groups like NSA are very ready to deal with.
I doubt that the methods used by many are that much of a problem. I will
grant that you do something better there.
I consider the technology just a patch that can be used on any of several
weaker-than- they-should-be algorithms, not to consider yours in that
lower class at all. However, the practice limits the use of your
algorithms. There may be a fix to what you have done, making your
encryption more acceptable to me, but you may not like the idea at first.
--
A new random permutation generator: You put X windoze
machines in a room, merely start them up, and record the
order in which they eventually crash on their own.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Adequacy of FIPS-140
Date: Sun, 18 Apr 1999 23:28:49 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> On Sat, 17 Apr 1999 23:23:39 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
>
> >If you can make the attacker consider you are using a OTP when you are
> >not, he might quit earlier, or not even try, consider the following as a
> >header for any message:
>
> >----BEGIN OTP MESSAGE HERE----
>
> >If the algorithm you choice is sufficiently good, it probably should mean
> >about the same thing.
>
> Of course a competent cryptanalyst is not going to believe that
> attempt at deception, and will try to find regularities in your
> ciphers.
>
> The sneakiest trick would be to use a system which gave him the
> regularities he seeks, but not the message. IOW, exploit his naive
> belief in Occam's Razor.
>
There are good methods to do this, to make something look like a familiar
cipher. A masquerade with wrong name more convincing details is an easily
pulled off trick. You can even reference some key hoarding structure,
wrong of course.
--
A new random permutation generator: You put X windoze
machines in a room, merely start them up, and record the
order in which they eventually crash on their own.
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: Extreme lossy text compression
Date: 19 Apr 1999 04:45:47 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
> I'm confused. Isn't it true that CRC(x) = CRC(0||x), for
> any polynomial?
Not if you initialize the CRC correctly. Given input bits m[1], m[2],
..., m[n-128], compute the polynomial
x^n + m[1] x^(n-1) + m[2] x^(n-2) + ... + m[n-128] x^128
and divide by a secret irreducible degree-128 polynomial p. Then add 128
secret bits to the remainder.
The result is is what people call ``almost strongly universal,'' i.e.,
almost uniformly distributed on any pair of distinct inputs. It's a
secure single-message authenticator.
Common modifications:
* Use a public value for the 128 bits added at the end: typically 0
or all-1s. The result is ``almost xor universal,'' i.e., has an
almost uniform output difference for any two distinct inputs.
* Omit the factor x^128 from the polynomial. The result is ``almost
universal,'' i.e., almost never collides on any two distinct
inputs. This is good enough for many applications.
* Omit the leading x^n term from the polynomial. This only works for
fixed-length inputs. (It's a common mistake in the literature.)
* Use a public value for p. This doesn't pose any risk if the input
is chosen independently of p.
All of these variants, and many more, are called CRCs in practice.
---Dan
------------------------------
From: "Kim. Jae-Yong" <[EMAIL PROTECTED]>
Crossposted-To: alt.security,comp.networks,comp.security,comp.security.misc
Subject: What is E0~E3 Algorithm.?
Date: Mon, 19 Apr 1999 14:56:29 +0900
I saw that RF Network called 'Bluetooth' uses E0,E1,E2,E3 algorithm as a
security algorithm..
I wanna know about these algorithm and surveyed a book Applied Cryptography
by Schneier. but I can't find that.
I wanna know about those algorithms. in fact I must..
Please let me know about those algorithm
Your typing for a minute can help me much.
Thanks in advance.
Kim. Jae-Yong
--
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES Competition
Date: Mon, 19 Apr 1999 00:16:08 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Jerry Coffin) wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> [ ... ]
>
> > What would you call AES when it is renamed?
>
> I think the convention usually used with programming languages is
> probably perfectly reasonable -- DES-2000 (or perhaps DES-00).
DES2K would work well if E2 makes it. Figure that the name might have
some play on what it comes from.
--
A new random permutation generator: You put X windoze
machines in a room, merely start them up, and record the
order in which they eventually crash on their own.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: FSE-6 Report: Slide Attack
Date: Mon, 19 Apr 1999 00:18:45 -0600
In article <[EMAIL PROTECTED]>, James Frey
<[EMAIL PROTECTED]> wrote:
> The Slide Attack
>
.....
> This attack can be prevented by using non-iterated rounds. Make
> each round different, especially early rounds and last rounds.
Insanity is doing the same thing over and over again and expecting
different results.
--
A new random permutation generator: You put X windoze
machines in a room, merely start them up, and record the
order in which they eventually crash on their own.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Sun, 18 Apr 1999 23:55:28 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> "Steven Alexander" <[EMAIL PROTECTED]> wrote, in part:
>
> >If I try to build a cipher and do
> >not understand cryptanalysis I will not ahve any idea how to protect my
> >cipher. If you have a better way to design ciphers, please share.
>
> You are right that avoiding known weaknesses is important, and
> understanding cryptanalysis is important.
>
> However, I think that there is a "better way to design ciphers" than to
> place too much faith in the _present_ knowledge of cryptanalysis. A cipher
> should be designed conservatively: not just in the sense of having a few
> extra rounds, but in the sense of having extra complexities in its design
> _far beyond_ those needed (nonlinear S-boxes, irregularities in the key
> schedule) to frustrate _known_ methods of attack.
>
A good trick is to telescope complexities into new primatives if you can.
Multiple layers of appropriate complexity do work, but the cost is
diversified in several directions.
--
A new random permutation generator: You put X windoze
machines in a room, merely start them up, and record the
order in which they eventually crash on their own.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Question on confidence derived from cryptanalysis.
Date: Mon, 19 Apr 1999 06:10:27 GMT
On Sun, 18 Apr 1999 18:48:37 -0400, in <[EMAIL PROTECTED]>,
in sci.crypt Geoff Thorpe <[EMAIL PROTECTED]> wrote:
I spent some hours responding to this huge article, and only at the
end realized (I assume correctly) that most of the controversy was
about something which I consider peripheral to the main issue. So I
am going to separate that other stuff off and ignore it so we don't
loose sight of the forest. This is not intended to disrespect the
effort in the original posting -- as I said, I have already made
comparable effort in the response you do not see. But nobody wants to
read huge postings, and all the points get lost anyway.
>Hello,
>
>Terry Ritter wrote:
>> >You want to sound a cautionary note that we all risk being naive and
>> >over-confident in our "cryptanalytic testing" of ciphers - excellent
>> >point and it is well taken.
>>
>> No, the point is NOT well-taken. It is ignored and brushed off as
>> trivial and known. Then everyone sticks their head in the sand again
>> until I bring it up again. This has happened for years.
>
>Once again, we are in disagreement - philosophically and factually it
>would appear. From your postings, I can understand why you think this,
>but it is based on a premise I simply do not accept and will not no
>matter how many times you repeat it. Namely, that repeated cryptanalytic
>testing does not provide a measure of the tested strength of a cipher.
OK, that is the peripheral cul-de-sac. I believe it, and believe it
can be successfully argued, but it is a side-issue nevertheless.
My main argument starts out that no matter how much analysis is done,
there is always the *possibility* that a cipher may fail anyway. I
doubt anyone disagrees with this.
Since cipher failure is *possible*, we need to look at the
consequences of failure: If this is to be the one standard cipher for
society, the results of such failure would be *catastrophic*. Again,
hardly controversial stuff.
We can do something about this: We can innovate various procedures
and protocols to avoid single-cipher failure. As a general concept,
it is hard to imagine that even *this* is controversial. The actual
technical details, of course, are arguable and changeable.
The package I have proposed includes compartmentalizing our data under
different ciphers, thus reducing the amount of data at risk of any
single cipher failure. (This virtually requires us to change ciphers
frequently.) I also proposed multi-ciphering as a matter of course
(reducing the likelihood of failure), and having a growing body of
ciphers from which to choose. Other proposals can of course be made.
At this point, I see arguments for doing nothing (if the fix is too
costly compared to the value at risk) and that the fix is worse than
the original problem. The first depends upon the extent of the value
at risk, which of course will include financial data, so the risk will
be very, very high, without much argument. The probability of failure
is the cul-de-sac argument itself, and may be hard to resolve. But
even a very low probability may not be acceptable; it would not be
acceptable to me.
The second part arguments are technical, but we can include the
best-tested cipher in the multi-cipher stack. In this case, I think
most would agree that -- properly done -- the overall strength could
not be weaker than the tested cipher. And I think most would agree
that this would indeed help prevent the single-point cipher failure
which (almost) everyone will admit is at least *possible*.
Really, after going though this stuff at great length, I don't see
much controversy here. No fireworks tonight: Sorry.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: SNAKE#13
Date: 18 Apr 1999 18:57:01 -0700
Peter Gunn <[EMAIL PROTECTED]> writes:
> Here is my latest and greatest idea for a "probabalistic"
> SNAKE version... SNAKE#13-1...
>
> A,B are random numbers
> R,T are s bit random numbers with n bits set to 1
> p is a large safe prime
> H() is a one way hash (SHA or similar)
> P=H(password)
> h(x,y) is a function which creates a s bit value
> by XORing H(x,y) split into s bit quantities
> U is the user identifier
>
> 1) A->B: (g^A)%p, U, T
> 2) B->A: (g^B)%p, R
> 3) A->B: E[H(g^AB)](h(g^AB,P,R) xor V)
>
> if B is MITM he cant solve 'h(g^AB,P,R) xor V' for P
> by brute force since he doesnt know V.
What is V?
> The real B accepts client if h(g^AB,P,R) XORed with
> the value from the client results in a number with n
> bits set to 1. Otherwise it disconnects.
>
> 4) B->A: E[H(g^AB)](h(g^AB,P,T) xor S)
>
> similarly the client accepts the server if
> h(g^AB,P,R) XORed with the value from the
> server results in a number with n bits set to 1.
> Otherwise it disconnects.
>
> Problem is I dont know how to work out how much
> information is being leaked and therefore how
> long the lifespan of a password would be for different
> values of s and n.
I'm not sure it matters. One one hand, you want your
preliminary "pre-authentication" to be strong enough so
that a MITM can't convince both sides through sheer chance
to go to the next stage, and spill out enough information for
a full-blown brute-force attack. On the other hand, if you
make it that strong, then that stage itself starts to leak out
enough information about the password so that after only a
handful of sessions, the MITM has the password anyway. This
is not a good set of constraints to have, since I believe they
are mutually exclusive with a good degree of overlap. I'd want
at least 16 bits of strength versus on-line attempts in the first
round, but 8 bits of leakage per round would be, IMHO, enough to
mount a practical partition attack.
As much as I hate to say it, why not just use one of the existing
strong password methods for your application? They're simple,
they're fast, papers have been written about them, there are plenty
of live code implementations out there - they're well known and
established. You don't have to invent the protocol yourself to
be able to use it in your application.
> How can I work out how many s bit numbers contain
> n bits set to 1??
That's just (s choose n) or
s!
========
n!(s-n)!
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
** 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
******************************
