Cryptography-Digest Digest #440, Volume #10 Sun, 24 Oct 99 07:13:03 EDT
Contents:
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Roger
Schlafly")
Re: OAP-L3: Where are the negative critiques from users? ("Belldandy")
Re: Weakness in the Rijndael key schedule? (SCOTT19U.ZIP_GUY)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Re: Note on Feistel Ciphers ([EMAIL PROTECTED])
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Mok-Kong
Shen)
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Roger
Schlafly")
Key size vs number of rounds (Mok-Kong Shen)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Terry
Ritter)
----------------------------------------------------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 23 Oct 1999 11:22:05 -0700
Trevor Jackson, III <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Why have any MUST implement ciphers at all. The AES contest is not
defined to
> be an interoperability issue. It is defined to be a threshold test for
USG
> acceptance of security products. Thus if NIST chooses a set of AES
algorithms
> any cipher from that set would satisfy the minimum security threshold and
thus
> be "AES compliant".
All other things being equal, interoperability is a good thing. That goes
without saying. But even if NIST's role is only one of acceptance testing,
its job is a lot easier with 1 cipher, than with 5 or 15.
------------------------------
From: "Belldandy" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Where are the negative critiques from users?
Date: Sat, 23 Oct 1999 17:53:34 -0500
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Taneli Huuskonen wrote:
> > Whoever is stupid and/or ignorant enough to believe your hype and buy
> > your programme is certainly not qualified to assess its cryptographic
> > strength. That simple fact suffices to explain the lack of negative
> > feedback, regardless of the merits of the product.
> >
> > Taneli Huuskonen
> OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E
>
> You don't have to buy the software. It is shareware.
>
> This means you can have the software delivered for free via email for
> evaluation purposes. (In the U.S. and Canada, only.)
>
> This is noted in very large FLASHING bold letters right at the top of
> the web page.
>
> Are you saying that none of you noticed this?
>
> Get the software.
>
> http://www.ciphile.com
hmmm is that mean that i don't have to buy the software even after 30
days?!?!?!?!?! :-) <--- just want to show your "mistake" in interpreting
what Huuskonen had said.
anyway, in your webpage you said
"OAP-L3T: ORIGINAL ABSOLUTE PRIVACY - LEVEL3 Version 4.1 © (patent pending)
may be the best encryption software available today. They said it couldn't
be done! Well, everyone knows that only messages encrypted using one-time
pads are unbreakable. At its heart, Original Absolute Privacy - Level3 is an
automated pseudo one-time pad generator."
Well, theoretically the one time pads are unbreakable. So I guess the
possible weakness in your encryption is in the pad generator. It is a bold
claim to say that your pad generator is totally "random" that makes
predicition impossible.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Weakness in the Rijndael key schedule?
Date: Sun, 24 Oct 1999 03:45:37 GMT
In article <7usskb$v75$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>A comment on the key schedule for Rijndael.
>
>Hello sci.crypt,
>
>I believe I have found a weakness in the key schedule for Rijndael. I
>turn to this august body for confirmation or harsh refutation of my
>theory. A quick note on my credentials. I am only an amateur
>cryptographer but a long time professional computer scientist. This
>post is a follow up to the 'Curious Keys in Rijndael' post.
>
>Abstract
>
>In this paper the block cipher Rijndael is analyzed. Rijndael is
>submitted as a candidate for the Advanced Encryption Standard. The
>cipher has variable key and block length. This paper focuses on the key
>length of 128 bits with the block length of 128 bits. The Rijndael
>cipher is an iterated ten round block cipher for this case. Here it is
>shown, the Cipher Key can be recovered if an attacker has the 'exclusive
>or' of several Round Keys. Moreover, one byte of key recovery can be
>mounted on Rijndael for certain key relationships and strange chosen
>cipher texts. Extension for this attack exist but appear to be
>impractical.
>
>This note is just the beginning of the full paper I am working on. If
>it turns out that I goofed up then this posting will save me the work:-)
>
>I will use the notation adopted in 'The Rijndael Block Cipher' by Joan
>Daemen and Vincent Rijmen. To understand the attack, you will have to
>read 'The Rijndael Block Cipher.'
>
>
I am not sure you understand that AES is not to be used for data that the
United States governement wants to be secure. It is for data that the US wants
every one else to use so the NSA can read the mail. You should not bother to
show weakness in the cipher till the AES weak cipher is adopted for use. Then
blow it all to hell. If your attack is strong enough the NSA my have to use
another of there trojan cyrpto methods in the contest. We ameturs should wait
until the phony crypto gods bless the final candidate.
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]
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 24 Oct 1999 03:39:23 GMT
In article <[EMAIL PROTECTED]>,
"Brian Gladman" <[EMAIL PROTECTED]> wrote:
>...
>If there are, say, two ciphers to choose from then 1-bit is necessary
>to make this choice so it is reasonable to ask which would be stronger
>when this scheme using n-bit ciphers is compared with the use of a
>single cipher with an (n+1)-bit key.
Interestingly enough, I discussed precisely this question in an older
post:
Take two ciphers A and B with keys of N bits. These ciphers must be
independent in the sense that physically breaking one does not help in
breaking the other. (By "physical break" I mean the work necessary to
recover the key when the cipher is already cryptanalyzed; "logical
break" would be the work necessary to successfully cryptanalyze a
cipher" - in what follows we discuss physical break only). Let us
suppose that these ciphers are not perfect; and therefore there exists
a method (known or unknown) to break them, which is more efficient than
brute force, i.e. the trying of all possible keys. For ciphers A and B
there exists then a method to break them at a cost comparable to 2^
(N*k) operations where k<1 (2^N corresponds to brute forcing them). If
you increase the key length by 1 bit, then you would need 2^((N+1)*k)
=2^N * 2^k operations to break A or B (here I assume A and B are
equally strong, a similar analysis can be done for the case k_A<>k_B ).
If you create a new cipher C with a key of N+1 bits where the last bit
is used to choose either A or B as the working cipher with a key of N
bits, then you must apply the A-attack, and with 50% probability the B-
attack also. The reason is that you don't know whether A or B has been
used; so you try the attack against A to see if it succeds. With 50%
probability it won't succeed and you will have to implement the attack
against B also. Here I assume that the best way to identify which
cipher is being used is that by breaking the cipher – with modern
ciphers I think this is a valid assumption.
So the cost for breaking C is 2^(N*k)+0.5*2^(N*k)=3/2 * 2^(N*k).
Therefore you need more effort to break C with a key of N+1 bits, than
either A or B with a key of N+1 bits, as long as k is less then ln
(3/2)/ln(2) = 0.58. If instead of two ciphers, you started with 2^M
different ciphers, then the results are more dramatic. The average
effort required for breaking the resulting cipher is now 2^(N*K-1)*
(2^M+1) and it will be stronger as long as k < 1/M*(ln(2^M+1)/ln(2) -1)
or for large M: k < 1 - 1/M. So, unless you are prety certain that your
cipher is perfect (k=1) then you are better off choosing one cipher
from as large a pool (M>>1) as possible. In a way, we get a security
amplifier with not cost in speed.
Let us assume, for example, that four AES finalists survive with a
flawless security record. Instead of using any one of them with a 128
bit key we could use the "fourAES" cipher with a 130 bit key. This
cipher will be stronger as long as k<0.66, i.e. as long as we assume
there exists an (unknown) attack that can break the AES finalists with
less than 2^(0.66*128)=2^84 cost. Is this a good assumption? Today, an
attack of 2^84 cost against a 128 bit AES candidate would certainly
kill it. What are the chances that in the next 50 years cryptanalysis
will improve to the level that such powerful attacks are discovered
against an AES finalist class cipher? The answer to that question is
anybody's guess, but it would be best to be on the safe side.
Observe that in my discussion above, the choosing of the cipher depends
on they key. It is not done randomly which would requiere us to add
information to the ciphertext about which cipher has been used. The
latter is probably a bad idea if we assume that the attacker has
sufficient resources to cryptanalyze all alternate ciphers - in that
case the attacker would first attack the ciphertexts produced by the
weakest cipher.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Note on Feistel Ciphers
Date: Sun, 24 Oct 1999 06:07:09 GMT
Mok-Kong Shen wrote:
> [EMAIL PROTECTED] wrote:
[...]
> > The Feistel structure is already powerful enough to
> > induce any bit permutation. The point is not that we
> > might actually want to implement a permutation as
> > Feistel rounds, but that the separation of the left
> > and right halves that one might intuitively suspect in
> > the Feistel structure does not in fact exist.
>
> Whether one can realize an arbitrary permutation with Feistel
> construct is not my concern. My point was that adding in a
> permutation step could render analyisis schemes that somehow exploit
> the seperation unworkable.
My point is that your concern, attacks that exploit
a separation between the halves in Feistel ciphers,
is of no concern at all. The separation is only in
the process of computation; it is known not to limit
the resulting dependencies. What does the
realization of arbitrary bit-permutations within the
Feistel construct prove? That any weakness that can
be repaired by adding bit-permutations is not
characteristic of Feistel ciphers.
> Adding permutations certainly contribute some complexity.
In the sense that adding most anything key-dependent
contributes some complexity to most any secret-key
cipher. The relevant point to a "Note on Feistel
Ciphers" is that Feistel ciphers already cover
bit-permutations.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 24 Oct 1999 10:18:04 +0200
Trevor Jackson, III wrote:
>
> Mok-Kong Shen wrote:
>
> > Trevor Jackson, III wrote:
> > >
> > > What do you belive is the difference between a MUST implement feature and a MAY
> > > implement feature?
> >
> > I am not sure in which sense your question is posed.
>
> You suggested that NIST recommend one MUST implement cipher and several MAY implement
> ciphers. They you said that implementors would not have to implement the MUST
> implement algorithm. This last statement appears to contradict the definition of
> MUST implement. It appears that you think the MUST implement cipher you think NIST
> should recommend is and implementation option. The MAY-implement ciphers are
> obviously optional as well. So why did you distingush between MUST and MAY if the
> difference makes no difference?
I am quite sure that you mis-read my sentences. I am quoting my
previous post below:
But I believe one could be satisfied with a compromise.
I guess that the possibility of NIST announcing, say, 3
candidates to be 'the' (all entirely equivalent) standards
is fiable. So letting one be the must and the others be may
could be a practicable solution out of the dilema. Note that
one must not use the MUST implementation at all. (I am aware
that my viewpoint is critisizable. )
I way saying that one (the user) must not use the MUST implementation,
not that the implementor may omit the MUST implementation. This
implies that, if e.g. there are rumors that the winner were broken, he
can simply drop that. While the analogy with standards in programming
languages is only partly appropriate (because we are in our case
considering a number of candidates that are functionally equivalent
to one another, not certain features that are necessary and others
that are not necessary in all situations) I do like to mention that
the language COBOL has 3 levels in its standard. All implementor must
implement the first level (without that no meaningful program can be
written), those that also implement the higher levels can claim that
their products provide these higher level features. So the market
demand will determine what kind of complilers at what price category
one will have. In our case a manufacturer that also implements the
two MAY algorithms can claim that the user can have a random choice
of the three available algorithms or do multiple encryption with them.
Those users that have very have good faith in the winner can buy a
product that only implements that at a lower price. Since all
implementations have the MUST algorithm, all users can at least
communicate with that and the issue of interoperability vanishes.
M. K. Shen
=======================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Crossposted-To: talk.politics.crypto
Subject: --- sci.crypt charter: read before you post (weekly notice)
Date: 24 Oct 1999 05:00:35 GMT
sci.crypt Different methods of data en/decryption.
sci.crypt.research Cryptography, cryptanalysis, and related issues.
talk.politics.crypto The relation between cryptography and government.
The Cryptography FAQ is posted to sci.crypt and talk.politics.crypto
every three weeks. You should read it before posting to either group.
A common myth is that sci.crypt is USENET's catch-all crypto newsgroup.
It is not. It is reserved for discussion of the _science_ of cryptology,
including cryptography, cryptanalysis, and related topics such as
one-way hash functions.
Use talk.politics.crypto for the _politics_ of cryptography, including
Clipper, Digital Telephony, NSA, RSADSI, the distribution of RC4, and
export controls.
What if you want to post an article which is neither pure science nor
pure politics? Go for talk.politics.crypto. Political discussions are
naturally free-ranging, and can easily include scientific articles. But
sci.crypt is much more limited: it has no room for politics.
It's appropriate to post (or at least cross-post) Clipper discussions to
alt.privacy.clipper, which should become talk.politics.crypto.clipper at
some point.
There are now several PGP newsgroups. Try comp.security.pgp.resources if
you want to find PGP, c.s.pgp.tech if you want to set it up and use it,
and c.s.pgp.discuss for other PGP-related questions.
Questions about microfilm and smuggling and other non-cryptographic
``spy stuff'' don't belong in sci.crypt. Try alt.security.
Other relevant newsgroups: misc.legal.computing, comp.org.eff.talk,
comp.org.cpsr.talk, alt.politics.org.nsa, comp.patents, sci.math,
comp.compression, comp.security.misc.
Here's the sci.crypt.research charter: ``The discussion of cryptography,
cryptanalysis, and related issues, in a more civilised environment than
is currently provided by sci.crypt.'' If you want to submit something to
the moderators, try [EMAIL PROTECTED]
---Dan
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 24 Oct 1999 01:08:06 -0700
<[EMAIL PROTECTED]> wrote in message news:7utv1b$ldc$[EMAIL PROTECTED]...
> Let us assume, for example, that four AES finalists survive with a
> flawless security record. Instead of using any one of them with a 128
> bit key we could use the "fourAES" cipher with a 130 bit key. This
> cipher will be stronger as long as k<0.66, i.e. as long as we assume
> there exists an (unknown) attack that can break the AES finalists with
> less than 2^(0.66*128)=2^84 cost.
Even if your analysis is correct, it is stronger by only a trivial
amount. It would be more secure to just increase the key size
by a few bits.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Key size vs number of rounds
Date: Sun, 24 Oct 1999 10:56:39 +0200
Recently in another thread Bryan Olson told us that Massey said
at the first AES conference that the number of rounds should
increase with the key size. Bruce Schneier pointed out on the
other hand that the designers of Twofish opted to increase the
complexity of each round rather than the number of rounds, as key
size increased.
These are interesting differing opinions. I tried hard to guess
what could be Massey's arguments but sofar can come up only with
the following plausible but fairly vague argumentation:
The key size (and related block size) and number of rounds are two
orthogonal dimensions. To achieve an optimum, they should be in
some proportion to each other. Hence, in order to obtain higher
strength both should be increased. Analogy: If you want to increase
the volume of a box, it suffices to increase breadth, depth or
height, but for obtaining a nice looking box you'll increase all
three dimensions simultaneously.
But I am afraid my argumentation above is far from being satisfactory.
I should therefore very much appreciate discussions on the theme
indicated.
M. K. Shen
========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 24 Oct 1999 09:05:43 GMT
On Sun, 24 Oct 1999 01:08:06 -0700, in
<7uueot$[EMAIL PROTECTED]>, in sci.crypt "Roger Schlafly"
<[EMAIL PROTECTED]> wrote:
><[EMAIL PROTECTED]> wrote in message news:7utv1b$ldc$[EMAIL PROTECTED]...
>> Let us assume, for example, that four AES finalists survive with a
>> flawless security record. Instead of using any one of them with a 128
>> bit key we could use the "fourAES" cipher with a 130 bit key. This
>> cipher will be stronger as long as k<0.66, i.e. as long as we assume
>> there exists an (unknown) attack that can break the AES finalists with
>> less than 2^(0.66*128)=2^84 cost.
>
>Even if your analysis is correct, it is stronger by only a trivial
>amount. It would be more secure to just increase the key size
>by a few bits.
Using different ciphers is fundamentally different from simply
increasing the keyspace. We have plenty of keyspace, or could have it
if we wanted it. Using different ciphers is not an attempt to gain
more keyspace.
One difference is that we expect a particular attack on a cipher to
work independent of key. Adding keyspace is probably not going to
make a successful attack much more difficult. But we do *not* expect
the same attack (other than in handwave generalities) to work on a
*different* cipher.
By changing the cipher we thus terminate any existing break which we
cannot expect to know about anyway. We also complicate the ciphertext
situation for anyone trying to distinguish the particular ciphertext
belonging to a particular cipher. Accumulating ciphertext from a
particular cipher would seem to be necessary for most real attacks.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.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
******************************
