Cryptography-Digest Digest #277, Volume #10 Mon, 20 Sep 99 07:13:03 EDT
Contents:
Re: Sources of randomness (Mok-Kong Shen)
Re: Ritter's paper ([EMAIL PROTECTED])
Re: (US) Administration Updates Encryption Export Policy (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Sources of randomness
Date: Mon, 20 Sep 1999 06:08:28 +0200
[EMAIL PROTECTED] wrote:
>
> > If one consequently follows this line of reasoning, one finds that
> > it isn't necessary to employ physical sources but that text materials
> > etc. can serve the same purpose as well.
> One finds no such thing. A fixed text has zero entropy.
> A choice from N fixed texts has at most lg(N) bits. In
> general, selecting or generating the text requires at
> least as much entropy as it yields.
You seem to have negelected the fact that the communication partners
can choose N (unknown to the analyst) offsets to the texts.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Ritter's paper
Date: Mon, 20 Sep 1999 05:16:30 GMT
In article <iTWD3.4791$[EMAIL PROTECTED]>,
"Richard Parker" <[EMAIL PROTECTED]> wrote:
> If one assumed that the workload was shared in the development of the
> multiple ciphers, wouldn't this raise the possibility that the ciphers
> are not sufficiently independent? This presumably would suggest that
> a catastrophic failure of the multiple ciphers could occur - the
> failure mode that Terry Ritter hopes to avoid by not using a single
> cipher.
Using multiple ciphers (choosing one from a pool of candidates) makes
sense *only* if the number of candidates is very large (many thousands
at least), because only then is the analytic capability of the attacker
overwhelmed. As you point out the question now is: how do you build a
large pool of ciphers that are sufficiently independent? Here I discuss
three alternatives:
1. Asking people to submit thousands of ciphers will probably not do.
Designing a cipher is a difficult proposition.
2. A possible solution is to have a "variable" cipher or a "cipher
generator", that produces a different cipher depending on parts of the
key. Maybe it is possible to build a generator so that a sufficiently
large proportion of the ciphers it generates are good enough and
independent enough. Confidence in that generator could be achieved
using the same process that is used to gain confidence about a
particular cipher: open and intensive cryptanalysis. Building such a
generator may be an even more difficult proposition than building a
single good cipher, or maybe not. You see, it would be more important
to show that the generated ciphers are quite independent (i.e. to show
that an attack against a few of the ciphers will not work on the rest),
rather than to show that on average each cipher is very strong. In fact
each individual cipher could be quite weak against a "known cipher"
attack, as long as the attacker cannot gain any knowledge about which
cipher is being used. Suppose, for example, that a generator produces
2^128 ciphers, each of which can be analyzed at a cost of one dollar
and broken with 3 known plaintexts - but that this investment does not
help analyze and break any other of the ciphers. We would still have
very good security, as long as an attacker cannot find out which cipher
is used n each case.
At bottom, of course, a cipher generator is a cipher too, but there is
an important shift in perspective. The designer now does not try to
build one function C=f(K,T) that fulfils one difficult requirement
(strength), but rather a group of functions C=f_K1(K2,T) that fulfil a
different set of requirements (independence and opaqueness), which may
be less difficult to achieve.
3. User-modifiable ciphers. Here we start with one standard cipher,
such as the AES. Suppose now that very knowledgeable cryptanalysts
suggest a series of "transparent" modifications to that cipher which do
not decrease its strength in any way. For example, as far as I can see,
if you take any cipher based on successive rounds, and XOR an
additional secret key to the data stream between two rounds, then you
do not decrease that cipher's strength. Suppose now that over time more
and more approved modifications such as this one are stored in a pool.
Every programmer who writes a security application starts with the AES,
randomly chooses a few modifications, and produces his or her very own
AES variant (at a very low price in speed). The human input in the
process would make the resulting ciphers quite independent. If the
particular set of modifications is keyed then the resulting cipher
would be in principle unknown to the attacker - we would now have a
cipher generator, albeit one that can grow dynamically. In any case, we
would produce a highly chaotic world from the point of view of the
attacker.
In conclusion, even though I do not completely agree with Ritter's
article, I do share his preoccupation about building the information
society of the future on top of a single cipher - it's like putting all
the eggs in the world in a single basket. At the very least, as John
Savard suggests, we should combine AES in series with something else.
The possibilities are many, so I think it would be very useful to have
a standard in place that converts a ciphertext into a self-contained
object that includes information about the methods used in its
encryption. In a networked world, these methods need not form part of
the ciphertext; the ciphertext would only have to point to the methods
stored somewhere in the net. There are plenty of advantages here: a)
everybody could be talking to everybody else without the need for one
particular standard (the AES could be used as the default method
anyway), b) advances in cryptology could reach the market fast, c)
catastrophic failure in one method would become less global, d)
catastrophic failure in one method could be corrected almost
immediately for all future communications and could be corrected
relatively fast for saved data. Here I am making several implicit
assumptions: a) that most encryption in the future will be software
based, b) that a catastrophic failure in one method will be become
public knowledge. The last assumption is very questionable in the
current state of affairs but maybe will be a reality in the future.
This is so complicated! :(
I wish somebody would publish a practical and truly provably secure
cipher, so that we could stop worrying.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: (US) Administration Updates Encryption Export Policy
Date: Sun, 19 Sep 1999 21:31:49 -0700
Reply-To: [EMAIL PROTECTED]
Dmitri Alperovitch wrote:
> >Anthony Stephen Szopa wrote:
> >> 3) If this is anything to be concerned about then tell me, has the
> >> US government withdrawn its appeal in the Bernstein case? I doubt
> >> it because the government is not sincere and full of beans.
> >
> >No doubt, the government is healthy (full of beans). :-)
> >
> >The Bernstein case is a different matter. If in fact Bernstein was
> >in violation of a law that was current when he violated it, then a
> >later change in the law does not prevent prosecution for the earlier
> >crime, unless the new law specifically states that (which is rare).
> >But it seems we're now talking about an administrative policy, not
> >a law.
>
> Apparently, it is still illegal to export source code without a license.
> The BXA page points out that the new policy is for object code only.
>
> Regards,
>
> Dmitri
> [EMAIL PROTECTED]
I can't find the proper post to reply to so I will reply here:
The District Court in the Berstein case declared that the US BXA Regs were
unconstitutional. This means they apply to every case and every one: past,
present, and future.
UNCONSTITUTIONAL
------------------------------
** 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
******************************
