Cryptography-Digest Digest #564, Volume #9 Wed, 19 May 99 11:13:02 EDT
Contents:
Re: Security (Patrick Juola)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Security
Date: 19 May 1999 09:57:51 -0400
In article <7hu5j2$qda$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>
>
>> I think you are correct in that any algorithm will (potentially) leak
>some
>> information, as it is not a OTP, but in the case of a well designed
>> algorithm it might only allow the shaving of a bit off the key( or
>> potentially less) in an idealized attack protocol. Cryptanalisys is
>the
>> art of pulling every bit (or fraction thereof) of information
>leakage out
>> of a cypher. Yes for any algorithm there will be a faster than brute
>force
>> attack, but in the case of most well designed algoritims your ability
>to
>> break a 128bit cypher in (2^126.999998) trials with a space usage of
>the
>> same is a useless break.
>
>Ah, but a break none the less. What I am saying is that since
>encryption is a deterministic process there will always exist a counter
>deterministic process. Since the key is actually used it's presence is
>measurable (often not enough tough), etc... etc...
>
>A cipher is only provably secure if all outputs are possible (random
>distribution based on the key) given any input.
This is a stronger condition than necessary; all that is necessary
is that for all plaintext p, the set of possible cyphertexts is
the same (over all keys), irrespective of whether or not this
actually exhausts the set of possible cyphertexts. For example,
I could produce an OTP-variant in which each output bit is tripled
before transmission; this means that some outputs are not possible
(01010101001....) but the cypher is nontheless provably secure.
>How do you create this
>random distribution in one round? If there are any one round
>characteristics (or linear approximations) chances are the algorithm
>can be cracked in reduced-round variants (and possible full-round).
One obvious way to do it would be to insert random padding of some
sort in order to exhaust the set of possible outputs. As an example,
suppose that we agree to use a symmetric block algorithm, but every
block that I send will contain only one actual data byte and the rest of
the bytes will be randomly generated noise that I put in just to fool
the cryptanalysts. Of course, you just throw away all this noise when
you get it. And by careful design of the cypher, I can ensure that
the property I outline above holds.
-kitten
------------------------------
** 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
******************************
