Cryptography-Digest Digest #416, Volume #9 Sun, 18 Apr 99 16:13:02 EDT
Contents:
Re: Adequacy of FIPS-140 (R. Knauer)
Re: Radiation/Random Number question (Fredrik Olofsson)
Re: AES Competition (Thomas Pornin)
Re: AES Competition (James Frey)
Re: AES Competition (Kent Briggs)
FSE-6 Report: Slide Attack (James Frey)
Re: Adequacy of FIPS-140 (R. Knauer)
Re: FSE-6 Report: Slide Attack ([EMAIL PROTECTED])
SNAKE#13 (Peter Gunn)
Re: Wanted: free small DOS Encryption program (fmd)
Re: Thought question: why do public ciphers use only simple ops like shift and
XOR? (Terry Ritter)
Re: AES Competition ([EMAIL PROTECTED])
Re: Extreme lossy text compression (Geoff Thorpe)
Re: which programs ... which algorithms (Phil Howard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Adequacy of FIPS-140
Date: Sun, 18 Apr 1999 14:11:44 GMT
Reply-To: [EMAIL PROTECTED]
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.
As a simplistic example consider this OTP ciphertext:
ATTACK AT DAWN
The real message is
ATTACK AT DUSK
where the key is the XOR of those two texts.
A smug cryptanalyst would conclude that the key is all zeros, and go
home for the day confident that he had decrypted the message.
Bob Knauer
"I am a great mayor; I am an upstanding Christian man; I am an intelligent
man; I am a deeply educated man; and I am a very humble man."
- Marion Barry, Mayor of Washington DC
------------------------------
From: [EMAIL PROTECTED] (Fredrik Olofsson)
Subject: Re: Radiation/Random Number question
Date: 18 Apr 1999 14:10:16 GMT
Dave Knapp ([EMAIL PROTECTED]) wrote:
: They tend not to be chips; rather, they are very pure single crystals.
: But the purity is required mainly for energy resolution; if you were
: using something for a RNG, a garden-variety silicon crystal would do.
Silicon dioxide? Quartz?
How should one do the coupling to the stone then? Drilling two holes,
making them irregular in structure and solder in electrodes?
: The main problem with using wafer-type chips for such radiation
: detection is the poor efficiency. You want the detector to have an
: appreciable thickness.
If it is quartz I'm sure I can spend a day in the nature to find a
really large one :)
- f0n
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: AES Competition
Date: 18 Apr 1999 14:45:32 GMT
According to Michael Scott <[EMAIL PROTECTED]>:
> it's completely patent free
It is explicitly stated by NIST that the winner of the AES contest will
be patent-free anyway. The 14 losers will keep whatever copyright policy
they wish.
If you want to make patent-freedom a selection criterion, then you must
NOT chose a patent-free candidate, since you will be able to use it even
if it does not win the contest. Better chose a completely proprietary
algorithm, this will make it free.
Anyway...
--Thomas Pornin
------------------------------
From: James Frey <[EMAIL PROTECTED]>
Subject: Re: AES Competition
Date: Sun, 18 Apr 1999 09:30:43 -1000
Kent Briggs wrote:
>
> Michael Scott wrote:
>
> > I must say Rijndael is looking good, given that its completely patent free,
> > scales nicely to various architectures, and can also be used as a one-way
> > hash. Its only problem seems to be its awful name.
>
> I guess that problem will take care of itself if it wins. It will simply be
> known as AES, wouldn't it?
>
> --
> Kent Briggs, [EMAIL PROTECTED]
> Briggs Softworks, http://www.briggsoft.com
No. After an algorithm is chosen it will be given a new acronym.
The "Advanced" Encryption Standard will not seem advanced after
12 years, it will seem ordinary, at best. I recommend the winner
be called the Millenial Encryption Standard Algorithm: MESA. This
will be a descriptive name that dates it so that in 2035, when
something advanced is needed, they call call for AES candidates again
without resorting to superlatives, live UES Ultra-Advanced
Encryption Standard.
What would you call AES when it is renamed?
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: AES Competition
Date: Sun, 18 Apr 1999 16:00:41 GMT
Michael Scott wrote:
> I must say Rijndael is looking good, given that its completely patent free,
> scales nicely to various architectures, and can also be used as a one-way
> hash. Its only problem seems to be its awful name.
I guess that problem will take care of itself if it wins. It will simply be
known as AES, wouldn't it?
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: James Frey <[EMAIL PROTECTED]>
Subject: FSE-6 Report: Slide Attack
Date: Sun, 18 Apr 1999 10:28:47 -1000
The Slide Attack
Summarized from the FSE-6 Conference in March, 1999, Rome
The authors were Alex Biryukov and David Wagner at the
Fast Software Encryption Workshop #6. The Slide Attack
is done using known plaintexts and known
ciphertexts. Two encryptions are put side by side,
with a one round offset. F is the round function:
P0
F
P1 P0'
F F
P2 P1'
F F
P3 P2'
F F
P4 P3'
F F
C P4'
F
C'
Pn is a plaintext in round n, C is a ciphertext.
In each round, a guessed subkey is used. Non-Feistel ciphers require
about O(2^(n/2)) work using known plaintexts with known
ciphertexts. For Feistel ciphers which split blocks in half,
the work and number of Chosen plaintexts and ciphertexts
needed are about O(2^(n/4)). Ciphers that do not split the block
in half are more secure against this attack.
Collect a large number of plaintexts and ciphertexts that used
an unknown key.
By the birthday paradox, one can expect to find a matched pair
P1=P0' more often than an exhaustive search would require. If the
key is right, then C=P4' also. Apparently, one guesses subkeys
and tries to find matched pairs. When the pairs are matched,
the subkey is probably correct. It can be verified using other
known P,C. The remaining key bits can be guessed or found by
repeating the test on other rounds than the rounds in which the
matched pair was found.
This attack is independent of the number of rounds. This is
important for designers to know, since it is often stated that
many attacks are prevented by specifying more rounds.
This attack can be prevented by using non-iterated rounds. Make
each round different, especially early rounds and last rounds.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Adequacy of FIPS-140
Date: Sun, 18 Apr 1999 14:18:11 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 17 Apr 1999 17:57:39 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
>>Gee, I was hoping you'd go off and develop such a method.
>>We certainly need something better than "I tried random
>>attacks and didn't find one that succeeded."
>Gee, I thought you were serious.
I sure hope that you know better now.
>Since we do not have a complete theory of cryptanalysis, all
>the work spent on cryptanalysis can never produce the true strength
>value we seek.
That statement is true for classical crypto, but it is not true for
quantum computation of true random numbers. There is no cryptanalytic
attack possible for keys generated in that manner.
>And while it would be nice to have such a theory, we
>have 50 years of mathematical cryptography which argues that there is
>no such thing.
That statement is true for classical crypto, but not for quantum
crypto.
Bob Knauer
"I am a great mayor; I am an upstanding Christian man; I am an intelligent
man; I am a deeply educated man; and I am a very humble man."
- Marion Barry, Mayor of Washington DC
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: FSE-6 Report: Slide Attack
Date: Sun, 18 Apr 1999 18:29:37 GMT
<snip>
This is a chosen plaintext attack? Or what? I mean if I give you C = E(P)
and C' = E(P') then you don't know the values inside the rounds.
How does it work then? Is there a paper available or even just text?
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Peter Gunn <[EMAIL PROTECTED]>
Subject: SNAKE#13
Date: Sun, 18 Apr 1999 17:59:49 +0100
13, Unlucky for some, and I've now resigned myself
to the fact that I cant really come up with
anything which is immune to offline password attack.
So, my new plan is to simply make the man-in-the-middle's
life as difficult as possible, and maybe even find a way
to leak information in a controlled fashion so that its not
probably that the MITM has enough of the password to
launch an effective attack.
SNAKE#12 was probably the most computationally
expensive SNAKE to crack offline since every
guess required a modexp()...
1) A->B: g^A, U
2) B->A: g^B
3) A->B: E[H(g^AB)](E[P](A))
4) B->A: E[H(g^AB)](E[P](B))
...but this still inst enough :-(
The hash of the username U is being given away for
free, and it would be good if we could hide this
from a MITM, but anything he cant see, cant be seen
by the server either, but for small systems of a
few hundred users or less this might not be a
problem as the server could do an exhaustive search
of its user list...
So, here is my first idea for SNAKE#13...
1) A->B: g^A
2) B->A: g^B
3) A->B: E[U](E[H(g^AB)](P)) & n
4) B->A: E[P](E[H(g^AB)](B)) & n
5) A->B: E[U](E[H(g^AB)](P))
6) B->A: E[P](E[H(g^AB)](B))
What happens is both client and server swap DH
public values (g^A and g^B) and work out a strong
shared secret (g^AB).
Then the client encrypts the user's password
with the session key and then with the username,
and sends the lower n bits to the server. The
server then does a linear search on its list of
users to find if it matches one or more entries.
If it does the server returns its the lower n bits of
its DH private value encrypted with the session key
and the username.
Then all going well, they swap the full blown
values.
The problems I can see with this approach is that
the value supplied to the server in step 3) might
match multiple users, and might be guessable if n
is small. What would a be a sensible value for n??
Any comments on this type of approach? Are there
well known mechanisms for doing this sort of thing
which I can read about??
ttfn
PG.
------------------------------
From: [EMAIL PROTECTED] (fmd)
Crossposted-To: comp.security.misc
Subject: Re: Wanted: free small DOS Encryption program
Date: Sun, 18 Apr 99 16:03:48 GMT
In article <[EMAIL PROTECTED]>,
Grinch <Use-Author-Address-Header@[127.1]> wrote:
>Milton Pomeroy <[EMAIL PROTECTED]> made the request:
>
>>Wanted - a free DOS-based encryption program which is small, fast,
>> strong and friendly
>
><snip of 12 requirements>
==========
I have a list of several sources at
http://www.ultranet.com/~fmd/pcsec.htm
>
>As several other people have done, I'll start by trying to dissuade
>you from one of your requirements:
>
>> (6) EXE or COM file must be small - less than say 80kbytes
>> (if it's large, like PGP for DOS at around 400kbytes, it takes
>> over 10sec to load from floppy-drive)
>
>My copy of PGP 2.6.2 is 243,097 bytes. It fits easily on a floppy. I
>use it from a floppy on occasion. This is my top recommendation. Use
>the conventional encryption:
>
> pgp -c "filename"
>
>if you are intimidated by the public key capabilities.
>
>Dissuading aside, the best solution that I know of that strictly meets
>all 12 of your requirements is SAFER. You can download it from:
>
> ftp://ftp.isi.ee.ethz.ch/pub/simpl/safer.V1.2.tar.Z
>
>using ftp, lynx, netscape, ...
>After downloading you will need to unpack with uncompress and tar,
>which you will find on your convenient unix system:
>
> uncompress safer.V1.1.tar.Z
> tar -xf safer.V1.1.tar
>
>You didn't list in your 12 requirements what compressing and archiving
>utilities you had access to.
>
>Be careful, however, with regard to:
>
>> (9) strong (at least 80-bit-key strength)
>
>This particular implementation has the unpleasant feature that if you
>link with getpass() to allow input of password without echoing, then
>safer will truncate the output to 8 characters, even if getpass()
>returns more. Most implementations of getpass() already truncate to 8
>characters, but that is another problem, and not safer's. Since you
>don't want to compile, much less change the source and compile, you
>will need to enter your pass phrase on the command line. Enclose it
>in " " marks. Using pgp, by the way, will solve this problem.
>
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Sun, 18 Apr 1999 19:27:29 GMT
On Sun, 18 Apr 1999 15:37:54 +0200, in <[EMAIL PROTECTED]>,
in sci.crypt "H. Ellenberger" <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>
>> >[...]
>>
>> The truth is that we *never* know the "real" strength of a cipher. No
>> matter how much review or cryptanalysis a cipher gets, we only have
>> the latest "upper bound" for strength. The lower bound is zero: Any
>> cipher can fail at any time.
>
>Correct, however you only describe the bewildering lack of a sound
>theoretical foundation of the subject matter.
Incorrect. The problem is both theoretical and practical; there is
ample reason to make serious changes. And, I do not *only* describe
the problem, but have also given prescriptions for increasing system
strength even when every cipher is suspect.
>> Since we have only an upper bound for the strength of any cipher, any
>> confidence we may have is no more than our own delusion. We wish and
>> hope for cipher strength, and -- absent a specific proof otherwise --
>> we gradually come to believe in it. But that does not make it true.
>
>Correct. Should we therfore stop analyzing existing ciphers?
No. We should stop depending on any small set of ciphers, no matter
how well analyzed.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AES Competition
Date: Sun, 18 Apr 1999 18:38:40 GMT
In article <ctXR2.15401$[EMAIL PROTECTED]>,
"Richard Parker" <[EMAIL PROTECTED]> wrote:
> >Which are the favourites?
>
> My favorites for AES candidate selection, in alphabetical
> order, are:
>
> DFC, E2, Mars, RC6, Rijndael, Serpent, and Twofish.
Hmm, well my favs are: DFC, RC6 and Twofish.
I have read them all. I haven't implemeneted any of them (other then RC6).
I think some of them are too over complicated, and that's why people 'think'
they are secure.
I really hope (no offense) that Loki97 doesn't make it. I have heard a lot of
bad stuff about it, and unless they have changed their ways, I wouldn't think
so.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Geoff Thorpe <[EMAIL PROTECTED]>
Subject: Re: Extreme lossy text compression
Date: Sun, 18 Apr 1999 14:26:23 -0400
Hi there,
> Thank you for your TIME to write such a lengthy and VERY CLEAR post.
My pleasure - I've had to play with essentially the same issues you have
a few times so if I can save you a little time as a result, great.
> If SHA1 and MD5 are well known secure hashes, what's a well known standard
> hash?
Well here you've got me a little - I'm a mathematician interested in
crypto who happens to make his $$ undercover as a programmer, not a
computer scientist well versed in all Knuth's volumes of essential
reading [;-) However, some others have mentioned a couple in these
threads - the Universal Hash Function, and somebody also mentioned a
simple (& fast) cute example involving XOR-ing in the blocks of the
message one at a time (after seeding it with some constant key-value and
padding incomplete blocks with zeroes I think?). This could suffice,
although if you expect a LOT of your texts to be very similar but not
quite the same this method would probably have a statistically better
chance of collisions - just a hunch though, I'm not going to even try to
justify that feeling though.
> By "additional steps" you mean the pre-hash "munge" you suggested for a
> standard hash, right? Maybe a secure hash is better for me just for its
> "munge"-free quality!
The munge would just be an idea to avoid what I was mentioning just
before about my "suspected" weakness of the XOR-based hasher ... if the
differences in many texts are isloted, possibly positioned on
unfortunate block boundaries or some such thing, then maybe some of the
hash values will come out similar - and worse, the same. A munge step
would just be an attempt to make sure that any differences are given
their best chance of influencing the hash value (or more precisely,
influencing all of the hash value). A paranoid consideration, that's
all.
> FINALLY: I just want to re-ask one other question, which no one responded
> to... Do hash developers run any statistical TESTS to back up their theory of
> random output, particularly for secure hashes?
Absolutely ... and even if they don't, there's a veritable army of
cryptanalysts out there just waiting to puncture even the smallest hole
in a "secure" hash algorithm (or any other class of crypto algorithm for
that matter). If someone even found a highly contrived way to choose
desirable texts that would cause the output hash values to exhibit ANY
kind of pattern, other than random noise, then that hash algorithm would
be discarded as a "cryptographic hash algorithm" and would turn
overnight into a "standard hash" (and a slow one moreover).
Many PRNG (psuedo-random number generators) take "random-info" from
hardware, eg. hard-drive timings, kernel stats, mouse activity, blah
blah - but although that info may be random, it may also be predictable
structured meaning that if you just stick the numbers end on end, and
XOR-hash the result you would have a VERY weak PRNG by cryptographic
standards. What the PRNG's usually (or should) do is just keep throwing
such "random-info" into a secure hash function - so as you can see, by
design these hashes need to have the property that subtle changes in
data, or data that is structurally similar every time, needs to still
generate seemingly unpredictable output unless the data matches exactly.
SHA1 and MD5 are dedicated secure hash algorithms, but there are others
that are derived from symmetric ciphers - that gives you an indication
of how seriously these algorithms are taken. They not only want a good
statistical "spread" for input values - they want it to stay
statistically uniform in the face of a determined attack to bias the
outputs. In short, the answer to your question (for secure hashes) is
yes.
For standard hashes, I believe there is some basic theoretical results
to the effect that given random (unknown) data A, the output value has
equal probability of landing on all possible hash values etc, and
similar probabilistic results about changes in input causing (in all
probability) changes in output. I find that it's all very easy if you're
prepared to accept hand-waving arguments without any mathematical
details [;-)
Well, best of luck,
Geoff
------------------------------
From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: which programs ... which algorithms
Date: Sun, 18 Apr 1999 20:02:19 GMT
On Sun, 18 Apr 1999 13:38:24 GMT Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
| Phil Howard wrote:
| > | 1.1 What is Kerberos?
| > | ...
| > Why is it so difficult for people to simply say which algorithm(s)
| > something actually uses? Is there some need to keep that secret
| > until someone peeks into the source code?
|
| You're overreacting. The very first question in the FAQ, "What is
| Kerberos", is almost certainly not the place for details. I don't
| have a copy of the Kerberos FAQ at hand, but I wouldn't be
| surprised if later on it does explain more about the protocols.
| Anyway, the exact crypto algorithms are relatively unimportant
| so long as they are sufficiently secure; Kerberos isn't primarily
| an encryption/decryption service as it is an authentication
| service.
I read the description of Kerberos. It involves a trusted third
party (the "AS"). But in the setup I want to do, there won't be
any place for a third party. What I want is something that is
pure end to end using some sort of public key to authenticate
(the key exchange will be done when the remote is installed)
as well as encryption.
DSA will be fine for authentication, and I believe El Gamal will
be as well. For the encryption, it can either exchange session
keys with the authentication keys, or use D-H to come up with a
set of random ones. The session algorithm can then be one of a
number of shared (since it hasn't been shared with outsiders) key
algorithms that are unencumbered, DES, 3-DES, Blowfish, AES[1-15],
etc., but not others like IDEA, RC-5, etc.
Actually, the one package I have found that looks like it could
fit my needs is LSH. But it isn't done, yet. FreeSwan might,
as well (I'm trying to figure out a way to make the tunnels under
the addressing conditions I have). I'd use SSH if it didn't have
gouging pricing for commercial use (any package that charges one
big price regardless of machine size is gouging for the small
machines I'll be working with).
I can pick what to do based on algorithm. There are lots of different
software out there (commercial payware and free for commercial use)
to choose from. The fundamental problem is that listings of the
packages don't explain algorithms. You have to d/l and investigate
(for freeware anyway ... payware is often secret and proprietary,
which I would double stay away from anyway). I have downloaded
some software that said it was freeware. What I keep finding is
that even though the software itself has free copyright licensing
under acceptable terms like GPL or Artistic, that the underlying
algorthms they chose have patent encumbrance in the US. Since the
good software comes from outside the US (due to you know what) the
problem seems to be that the authors are not aware of, or are just
not concerned with US patents (either because they are academic
and it might not affect them or their target audience at all or
because they just don't care about usability in a country with
export restrictions like the US has).
Do I need to volunteer to create an index/compilation of security
freeware out there, detailing its encumbrances based not just on
copyright, but on patent, and probably other laws? No such list
now exists?
--
Phil Howard KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
** 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
******************************
