Cryptography-Digest Digest #20, Volume #11 Sun, 30 Jan 00 23:13:00 EST
Contents:
Re: NIST, AES at RSA conference (Terry Ritter)
Re: KEA gains something with RSA instead of D-H ("Rich Ankney")
Re: NEC claims New Strongest Crypto Algor (Hideo Shimizu)
Re: Strip Security ("Scott Fluhrer")
Re: KEA gains something with RSA instead of D-H ("Scott Fluhrer")
General Groves' 10x10 (Rebus777)
Re: Intel 810 chipset Random Number Generator (Jerry Coffin)
Re: NIST, AES at RSA conference (David Wagner)
Output openssl results to memory buffer (Angus Lee)
Re: Security of Kremlin (PC software): Insecure implementation? (JPeschel)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Mon, 31 Jan 2000 02:01:42 GMT
I really would prefer to avoid this discussion, but since the previous
author makes false claims about my position, I will try to correct the
errors.
On Sun, 30 Jan 2000 23:03:57 GMT, in <872g0r$e2j$[EMAIL PROTECTED]>, in
sci.crypt Bryan Olson <[EMAIL PROTECTED]> wrote:
>[...]
>I'll explain my point in terms of the two responses you
>present. I see Ritter's argument as insisting that "we lack
>proof" is fatal to any cipher that an effort such as AES
>might produce, regardless of how the designer of that cipher
>may have applied the "do everything we can" principle in
>your second paragraph.
That statement depends upon how the previous author defines "fatal."
It is clear that to claim AES is secure without proof would be
incorrect and false and wrong. And cryptanalysis can offer no such
proof.
On the other hand, I accept that we have no choice *but* to use
ciphers we cannot trust.
>He rejects such ciphers
>categorically, saying we have no results about them.
That statement is false and misleading.
We have to use ciphers. Unfortunately, we necessarily use ciphers
which have no proof of strength, and, therefore, may be weak. I claim
that it is appropriate for us to innovate and use other measures which
will maintain security even when our most trusted cipher is in fact
weak.
>He does
>not consider any analysis of their properties or any
>internal structure they may have; they are simply rejected
>because we cannot disprove that an adversary may break them.
That statement is also false and misleading.
I do reject the common wisdom that cryptanalysis tells us anything
about the strength of ciphers which have not been broken.
Cryptanalysis testifies only to weakness, and only when a particular
weakness has been found. But since we only use ciphers which have not
been broken, cryptanalysis does not help us trust the ciphers we use.
The fact that a cipher has survived cryptanalysis does not mean that
it cannot be broken at will by our opponents.
>Then for the systems Ritter advocates, I do not see the same
>criteria applied. If we do apply it, then these
>multi-ciphers fail just as surely as single ciphers.
That statement seems deliberately slanted.
It is certainly true that using multiple ciphers in sequence might
also be weak -- provided we really do have a "cryptographer's stone"
which can break any cipher. But in that case, cryptography is dead
anyway.
It is also true that we cannot express a strength for the use of
multiple ciphers in sequence. But we can convince ourselves of
several things, including: a) since we can use any cipher we want in
the sequence, we can use the one we think is strongest, and the result
will be at least that strong; b) if we use three "thought strong"
ciphers, each of the individual ciphers will be protected from
known-plaintext and defined-plaintext attacks, which does make the
ciphers more resistant in the sense that it limits what the opponents
can possibly do.
Now, we can either choose to use a single cipher for which we have no
factual or logical basis for trust, or, say, three such ciphers. Then
we have some consequences: 1) The single cipher is of course not
protected from known-plaintext or defined-plaintext attacks; the
sequence of three ciphers is protected. 2) If we send all our data
under one cipher, and that cipher falls, all of our data are exposed;
but if we use multiple ciphers and only some fall, then only some of
our data are exposed.
>Do we accept a cipher with unproven and unquantifiable
>security? If the answer is "yes with great caution" then
>the idea that we cannot categorically reject single ciphers;
>we have to carefully apply that great caution in the design
>and analysis of that cipher. That is the process the AES
>effort is pursuing.
There is no cookbook for secure design, no mathematical system which
produces guaranteed secure ciphers. Putting great effort into the
design is fine, as is the same for analysis. But analysis can only
tell us about weakness, not strength, and we don't use the ones which
are found weak. No matter how much analysis there may be, the fact
that a cipher passed through all that work makes no statement about
the true strength of the cipher.
Most people do see AES as a "certification" process, in which the
strength of the competing ciphers is assured, at least to some high
probability. That vision is simply false. One or more of those
ciphers may be broken now, and if we use such a cipher our data may be
exposed, no matter how many tests that cipher passed.
The above is not a mythical fear, it is a real possibility. We do not
know our opponents, so we do not know their capabilities, and we
cannot extrapolate from strength with respect to academics to strength
with respect to opponents we do not know.
>If the answer is that we cannot accept a system with
>unquantifiable security, and I see the position as
>reasonable though it is not my own, then no system based on
>computational security can pass, no matter how layered or
>dynamic. If all unprovable ciphers must be tripled, then we
>must triple our triples of triples with no end.
That statement gives a position which certainly is not mine; it is in
fact opposite to mine: I claim that we have *no* *choice* but to
accept a system with unquantifiable security. We have *no* *choice*
but to use systems which we cannot trust, and upon which we cannot
rely.
We are in an unsavory position, and the only thing we *can* do is to
try to improve our odds:
We can try to improve our odds by requiring opponents to do more than
one thing. Breaking a cipher is one thing. Breaking three ciphers is
most likely three things -- unless of course we return to the
"cryptographer's stone" myth again, in which case all of this is
pointless.
We can reduce the consequences of single-point failure by sending part
of our data under one cipher, part under another, and so on, and
especially not allowing most of society to use the same cipher.
We can improve our response to the unexpected by building systems
which allow ciphers to be replaced at will. Then, if a cipher is
found weak, we can just replace it, without a massive re-engineering
of the entire society.
We can improve our investment in security, versus the cryptanalytic
investments of our opponents, by having and using many fundamentally
different ciphers. Having many ciphers requires each opponent to
identify, acquire, analyze and break (when possible) each different
cipher. It is far cheaper to produce new ciphers and distribute their
costs (if any) over each unit than it is to cryptanalyze and break
each new cipher.
My position is substantially different from what the previous author
would have you believe. Given the volume of material I have written
to explain this -- including a printed article -- and that my position
is available on my pages, I believe such mischaracterization can only
be seen as deliberate propaganda.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Rich Ankney" <[EMAIL PROTECTED]>
Subject: Re: KEA gains something with RSA instead of D-H
Date: Sun, 30 Jan 2000 21:42:42 -0500
Good point. A similar argument came up last week at an ANSI
X9F1 meeting (discussing using RSA for key agreement). Using
XOR might (depending on the protocol) allow one party to influence
the derived (XORed) key. (This is true of any protocol where Alice
sends a component to Bob and Bob can then decrypt and determine
his response.) We (i.e. Don Johnson, Bob Silverman, and others)
figured hashing the key components seems better. (Leading to the
problem, in an asynchronous comm environment, of determining what
order to hash the components:-)
Regards,
Rich
David Wagner wrote in message
<872l3i$lfo$[EMAIL PROTECTED]>...
>In article <[EMAIL PROTECTED]>,
>John Savard <[EMAIL PROTECTED]> wrote:
>> Hence, if a protocol like KEA were used, sending two session keys in
>> opposite directions simultaneously, but with RSA instead of
>> Diffie-Hellman, with the XOR of the two session keys being used as the
>> actual session key, communications would remain secure *even if the
>> private key of one party had been compromised*.
>
>Good point! I haven't seen this observation before.
>
>Does anyone have any clue why KEA uses XOR to combine the two session
>keys, instead of simply hashing them with (say) SHA-1?
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: NEC claims New Strongest Crypto Algor
Date: Mon, 31 Jan 2000 11:46:37 +0900
Last week, Japanese cryptographic conference 'SCIS2000' was held in Okinawa.
SCIS is the largest security conference in Japan, and about 250 papers
are presented there.
In SCIS2000, NEC announce the Cipher Unicorn-A is the world strongest cipher.
As my understanding, their strongest major is correlation about F function.
Y. Tsunoo, et.al, '128-bit block cipher CIPHER UNICORN-A'
There are many interesting papers, but unfortunately almost of papers are
written in Japanese.
AES related papers are listed below.
- S. Moriai, 'Cryptanalysis of Twofish (1)'
She develop fast evaluation method for truncated differential attack.
- K. Takeuchi, et.al., 'Correlation attack against RC5 and RC6'
Improvement of Knudsen's paper
- M. Kiyama, et.al., 'Higher order differential attack against CRYPTON'.
- T. Sorimachi, et.al., 'On the differential/linear path for SERPENT'
- H. Yokoyama, et.al., 'On the higher order differential characteristics
of Serpent'
- D. Suzuki, et.al., 'On the higher order differential characteristics
of round function of DFC
- J. Yajima, et.al., 'On the efficient boolean expression of s-box of
Serpent'
In 5 s-boxes, they found smaller boolean expression than Gladman's one.
Totally, they reduce 66 clock on Pentium III.
(Only Japanese titles are given, so this is translated one.)
Hideo Shimizu
TAO, Japan
Arthur Dardia wrote:
>
> Apparently NEC thinks they've developed the strongest crypto in the
> world. In addition, they claimed that they've met and surpassed the AES
> standards. The algorithm is backwards compatible with DES and AES as
> well. It's a rather interesting read, but I'd like to see some source.
> I highly suggest you check it out.
>
> http://www.currents.net/newstoday/00/01/25/news4.html
>
> --
> Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
> PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.palmtops.pilot,alt.comp.sys.palmtops.pilot,comp.sys.handhelds
Subject: Re: Strip Security
Date: Sun, 30 Jan 2000 19:23:29 -0800
Highdesertman <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi Gordon, nice to see you again
>
> IDEA is a block cypher. My understanding of block cyphers is that by
> their nature, the password is removed from the actual encrypting key,
> the key being generated by the algorythm itself.
>
> >The other issue is the password. From memory I think IDEA uses a
> >128-bit key. That means there are on the order of 10^38 possible keys.
> >However the key used for your database is presumably just a hash of
> >the entered word or phrase. If you picked a five character password
> >with no numbers there you have restricted yourself to about 10^7
> >possible keys. In other words a brute force solution has just become
> >about a billion billion billion times easier and could probably be
> >done in a matter of seconds on a PC.
>
> I usually find myself in agreement with your posts, but in this case,
> I must disagree.
>
> I don't believe your estimate of the resources required to crack IDEA
> is accurate. You are correct in pointing out that the security of the
> application is dependent on the proper implementation of the algorythm
> and the design of the program. But assuming the above has been done
> properly, I don't believe that cracking IDEA is quite so easily done.
If you read his post, he's not talking about cracking IDEA -- he's talking
about cracking a crypto *system* that has a poorly chosen user password
as the weak point. The particular weakness he is exploiting has nothing
to do with IDEA, it has to do with how the IDEA is used. In addition,
that is the real reason why:
> This is why it is so important to use a security program
> that implemets an algorythm with published code. publishing the code
> allows for analysis of weaknesses.
Actually, if all we were interested in is whether they have implemented
the algorithm correctly, doing interoperability tests, or running test
vectors
will tell us that. Instead, the real reason publishing the code is
considered
important is that it allows the public to find weaknesses in the overall
system, such as low-entropy keys. That the individual algorithms are
strong is a necessary condition, but not sufficient.
--
poncho
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: KEA gains something with RSA instead of D-H
Date: Sun, 30 Jan 2000 19:26:19 -0800
Rich Ankney <[EMAIL PROTECTED]> wrote in message
news:872scb$6k7$[EMAIL PROTECTED]...
> Good point. A similar argument came up last week at an ANSI
> X9F1 meeting (discussing using RSA for key agreement). Using
> XOR might (depending on the protocol) allow one party to influence
> the derived (XORed) key. (This is true of any protocol where Alice
> sends a component to Bob and Bob can then decrypt and determine
> his response.) We (i.e. Don Johnson, Bob Silverman, and others)
> figured hashing the key components seems better. (Leading to the
> problem, in an asynchronous comm environment, of determining what
> order to hash the components:-)
Mind if I make a simple-minded suggestion: compare the two
components, and put the smaller one first :-)
--
poncho
------------------------------
From: [EMAIL PROTECTED] (Rebus777)
Subject: General Groves' 10x10
Date: 31 Jan 2000 03:37:48 GMT
In David Kahn's (The Code-Breakers) the paper & pencil cipher used by General
Groves during the Manhattan Project, seems to be very easily set up and fairly
secure for limited communications. The fact that you can assign many
plaintext positions to the most common letters and you can easily change the
numbering of the horizontal and vertical cipher numbers makes it very
versitile even if you only have one 10x10 matrix defined. The same message
can be encipher many ways.
The horizontal and vertical could be numbered:
1234567890 or 0123456789
Thus 4 diff keys: 11, 10, 01 or 00 (1st number of horizontal &
vertical)
This seems to be a clever system and I was wondering what some of
you paper and pencil people thought of it?
-RSC
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: Sun, 30 Jan 2000 20:38:26 -0700
In article <872l01$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> I think you got his claim backwards (not suprising given that he
> really doesn't make any sense at all 99% of the time!) He is saying
> that the "thermal drift" (which he says happens when the temperature
> of the crystal is kept constant, so it's not what you are thinking
> it is) of (frequency?) diverges from the starting point in the same
> manner that a particle does under brownian motion AND THAT THIS
> DIVERGENCE STAYS THE SAME EVEN WHEN YOU TURN OFF THE POWER
> OVERNIGHT!!!
Well, I guess I'll admit I'm not sure what he's saying -- it appears
to me that he frequently makes a claim in one direction about the
theory, but then turns around and specifically disclaims having said
anything about what would result from that theory.
> Have you ever seen the output of a player behave like that?
I've never seen the output from much of any oscillator act that way.
I can't imagine how you'd put such an oscillator to use in any design
I've ever seen.
> Neither have I. Only aging of the quartz acts
> like that, and he specifically excluded that as a possibility.
>
> He is right about one thing, though. Nobody understands his theory.
...including him, I'm reasonably certain.
In any case, it seems to me that we're kicking a dead horse. It all
comes down to one simple fact: a crystal oscillator is a lousy source
of entropy. I'm reasonably certain that if you try to use crystal
oscillators in something similar to the way he envisions, nearly all
the entropy you get will be from other sources. Just for example, you
could take two oscillators, run them at what was supposed to be 180
degrees out of phase, mix the results (which should obviously cancel),
and amplify the difference.
This _would_ have the jitter mixed into the output signal, but the
majority of the output would be due to noise and distortion in your
oscillators, mixer, amplifier, etc.
It's a bit like the situation with using a TV as a cosmic ray
detector. If you tune to a channel with no signal, some of the "snow"
comes from cosmic rays. Unfortuntely, other sources account for the
vast majority of what you see, and there's no real way to tell what
parts came from where...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST, AES at RSA conference
Date: 30 Jan 2000 19:49:05 -0800
Your post still doesn't address Brian Olson's elegant one-line refutation:
``If all unprovable ciphers must be tripled, then we
must triple our triples of triples with no end.''
The only way out of this conundrum (as far as I can tell) is to admit
that not all unprovable ciphers must be tripled -- and thus to admit
that we have some other implicit figure of merit in mind.
IMHO, this makes it abundantly clear that provable security cannot
serve as sole justification for multiple ciphering. It seems that
the lack of provable security is a red herring that really says nothing
about whether multiple ciphering is preferred over single ciphering.
A more moderate stance would be to argue that `diversity increases the
odds of security, but is no guarantee' -- but that doesn't seem to be
the argument you are making. Anyway, one would still need to support
this position with evidence that diversity is more cost-effective than
other means at our disposal.
------------------------------
From: Angus Lee <[EMAIL PROTECTED]>
Subject: Output openssl results to memory buffer
Date: Mon, 31 Jan 2000 11:42:36 +0800
Hi,
I tried to use openssl in my final year project to create certificate.
The openssl package does not provide enough documentation, however. I
tried to digged into the source code of the openssl applications. But
they usually output the results to files. I want the results output to
the memory buffer. Does anyone know how this can be done?
Thanks.
Angus Lee
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Security of Kremlin (PC software): Insecure implementation?
Date: 31 Jan 2000 04:04:00 GMT
"cedric frost" [EMAIL PROTECTED] writes, in part:
>I'm currently using a program called Kremlin (Mach5 software,
>http://www.mach5.com/) to encrypt local files. It has a nice variety of
>algorithms and an unobtrusive context-based interface.
>
>But there is something about it that concerns me. When I double-click an
>encrypted file (encrypted files are overwritten as *.kgb), I am prompted for
>a passphrase (key). If I enter an incorrect key, instead of decrypting the
>file to gibberish, it pops up a dialog that says "Incorrect Passphrase." I
>am no security expert, but it seems to me that in order for this software to
>know that my key is incorrect, it must be storing some information about my
>key in this .kgb file. Anyone have any thoughts on this?
One prominent cracker, Casimir, has tried cracking Kremlin without
success. I'd use it.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.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
******************************
