Cryptography-Digest Digest #517, Volume #11 Sun, 9 Apr 00 08:13:01 EDT
Contents:
Re: Stream cipher from FSE 1 ([EMAIL PROTECTED])
Re: Pre-whitening? (Was: RC-5 modification) ("Adam Durana")
Re: Pre-whitening? (Was: RC-5 modification) (Guy Macon)
Re: Is AES necessary? (Mok-Kong Shen)
Re: Is AES necessary? (Mok-Kong Shen)
Re: Is AES necessary? (Mok-Kong Shen)
Re: Is AES necessary? (Mok-Kong Shen)
Re: Is AES necessary? (Mok-Kong Shen)
Re: Is AES necessary? (Mok-Kong Shen)
Re: Q: Entropy (Mok-Kong Shen)
Re: GSM A5/1 Encryption (Paul Schlyter)
Re: Is AES necessary? (Tom St Denis)
Re: Is AES necessary? (Svend Olaf Mikkelsen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Stream cipher from FSE 1
Date: Sun, 09 Apr 2000 05:04:33 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On Fri, 07 Apr 2000 05:00:49 GMT, [EMAIL PROTECTED] wrote, in
> part:
>
> >IIRC, in FSE 1 Ross Anderson suggested a stream cipher
> >formed by using an LFSR to turn the wheels of a three-wheel
> >rotor system. Has there been any cryptanalysis of this?
> >Or any other kind of -analysis?
>
> It sounds like a good idea. However, as an LFSR is linear, it might be
> weaker than the SIGABA, which used one set of rotors to turn another
> set of rotors, with only the first set of rotors being turned in a
> regular way.
My brief description probably did not do the idea full justice. To add
some detail: the 3 rotors have 256 settings, and the low (or high?)
3 bytes of the LFSR set the rotor positions. The LFSR is stepped
8 times for each byte of output. (This means the setting of the third
rotor for byte n is the same as the setting of the second rotor for byte
n-1, and so on, but Anderson seemed to think this would not be a
problem.)
>
> If two banks of rotors were used, or the LFSR was used to feed a
> MacLaren-Marsaglia construct before controlling the rotors, the result
I don't know what a MacLaren-Marsaglia construct is; it doesn't seem
to be mentioned in *Applied Cryptography*.
> ought to be more comparable with the SIGABA. With eight rotors at the
> end instead of three, I don't think that the threat of cryptanalysis
> would be an issue; of course, the system would no longer be as fast.
>
Yes. Would such a scheme be too slow to be practical as a stream
cipher? RC4 generates a byte with 3 table-lookups, 3 additions
(mod 256) and a swap; 8 rotors would seem to take 8 lookups and 9
additions (mod 256), which looks to be less than half as fast as
RC4. My mind reels with possible variations on this idea, but
I have no idea how to analyze them.
--
Dave Empey
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Pre-whitening? (Was: RC-5 modification)
Date: Sun, 9 Apr 2000 02:27:38 -0400
Pre-whitening is just xor'ing some key bits with the plaintext before it
enters the first round. Post-whitening is exactly the same but the key bits
are xor'ed with the ciphertext after the last round.
So..
M = M xor K1 (pre-whitening)
... Encryption rounds ...
M = M xor K2 (post-whitening)
So its pretty simple you see. I forget the exact figures but I do remember
it increases the strength of the cipher. Its in Applied Cryptography
somewhere. I believe Rivest is credited with "inventing" it.
"Guy Macon" <[EMAIL PROTECTED]> wrote in message
news:8coacn$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Tom St Denis) wrote:
>
> >If you are talking about the 'pre-whitening'
> >step, that is generally a good thing to keep
> >as it increases the difficulty of an attack
> >without much extra cost [note DESX].
>
> Could someone give a simple explaination or link
> about this? Is it something that one could use
> when noodling around with ciphersaber variants
> as a learning tool?
>
> Please note that my ciphersaber variant that turned
> out to be a really slow way of turning plaintext to
> the same plaintext has NEVER had it's internal
> structure derived by cryptoanalysis... :)
>
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Pre-whitening? (Was: RC-5 modification)
Date: 09 Apr 2000 04:32:43 EDT
In article <1jVH4.11847$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Adam Durana) wrote:
>
>
>Pre-whitening is just xor'ing some key bits with the plaintext before it
>enters the first round. Post-whitening is exactly the same but the key bits
>are xor'ed with the ciphertext after the last round.
>
>So..
>
>M = M xor K1 (pre-whitening)
>
>... Encryption rounds ...
>
>M = M xor K2 (post-whitening)
>
>So its pretty simple you see. I forget the exact figures but I do remember
>it increases the strength of the cipher. Its in Applied Cryptography
>somewhere. I believe Rivest is credited with "inventing" it.
Ah. I understand. are the key bits repeated again and again so you
don't need as many bits as your plaintext has? Are they varied in any way?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Sun, 09 Apr 2000 10:44:46 +0200
Andru Luvisi wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> [snip]
> > However, does the amount of informations, that really deserve
> > the etikette of secrets, have proportionately increased?
> [snip]
>
> If you only use encryption for the things that "need" it, then it
> becomes very easy to identify the "important" traffic. If everyone
> uses encryption as a matter of course, then it won't be "suspicious"
> for those who need it to use it.
That's an excellent observation. If everyone encrypts his e-mails,
whether using strong or weak algorithms, the machineries of the
malicious agencies, that under the cover of crime suppression
intrude the private spheres of innocent people and conduct
commercial espionages, would be bogged down due to the enomous
load to decrypt and analyse these. Crime suppression is certainly
important for our society. But I believe that the trade-off is
simply not tolerable, if we entirely opfer our freedom of privacy
for that. (Just think of a related question: Who of us wish to
live under the regime of a big dictator, where there is some
'good order' maintained by secret police?) In a recent thread of
mine, I pointed out that one effective method of jamming Echelon
and its counterparts is that one regularly appends to e-mails
bogous ciphertexts consisting of several lines of random hex digits
and also publish such stuffs on one's web page (with frequent
updating) to exhaust the computing capacities of the agencies.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Sun, 09 Apr 2000 10:45:19 +0200
David Crick wrote:
>
> Mok-Kong Shen wrote:
> >
> > I am virtually ignorant in hardware matters. But I wonder why
> > pipelining is not applicable to 3DES, i.e. the 3 modules may be
> > processing 3 consecutive blocks of informations simultaneously.
> > That way, there would be no time penality, excepting the setup
> > time of the pipe.
>
> 3DES used in this mode is susceptible to shortcut attacks that
> render it as only 2^56 strength (i.e. same as DES). 3DES used
> in the slower, (outer feedback mode I believe?) mode gives us
> the usual 168/112-bit strength.
>
> See Applied Cryptography and the paper referenced therein.
But isn't exactly the outer feedback mode, where the 3 modules
are put one after the other, i.e. the output of one is fed into
the other without any other (subsidiary) connection paths, that
is an excellent candidate for pipelining? (Otherwise, pipelining
could be more difficult.)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Sun, 09 Apr 2000 10:45:36 +0200
Svend Olaf Mikkelsen wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> >> I am virtually ignorant in hardware matters. But I wonder why
> >> pipelining is not applicable to 3DES, i.e. the 3 modules may be
> >> processing 3 consecutive blocks of informations simultaneously.
> >> That way, there would be no time penality, excepting the setup
> >> time of the pipe.
> >
> >Just off the top of my head, you can't use CBC mode with that can you?
>
> Decryption, yes.
> Encryption, no.
I don't understand. Could you please explain that?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Sun, 09 Apr 2000 10:45:29 +0200
Tom St Denis schrieb:
>
> Mok-Kong Shen wrote:
> >
> > Bruce Schneier wrote:
> > >
> > > <[EMAIL PROTECTED]> wrote:
> >
> > > >3DES is currently yet strong enough. If that's too weak, we could
> > > >use 5DES etc.
> > >
> > > Basically, I agree. It only makes sense to use AES for applications
> > > where:
> > >
> > > the performance of triple-DES is just too slow
> > >
> > > the gate count of triple-DES is just too large
> > >
> > > the block size of triple-DES is just too small.
> > >
> > > Triple-DES is still the conservative choice.
> > >
> > > And forget about 5-DES. Triple-DES is fine for the forseeable future.
> >
> > I am virtually ignorant in hardware matters. But I wonder why
> > pipelining is not applicable to 3DES, i.e. the 3 modules may be
> > processing 3 consecutive blocks of informations simultaneously.
> > That way, there would be no time penality, excepting the setup
> > time of the pipe.
>
> Just off the top of my head, you can't use CBC mode with that can you?
You simply consider 3DES as a black box and do CBC in the way known.
> > > >We could employ some trivial variants of DES that enable expansion
> > > >of the effective key space (e.g. permutation of the subkeys or
> > > >the S-boxes).
> > >
> > > No.
> >
> > Could you please elaborate a bit on that? (See my recent thread
> > 'Variants of DES' of 3rd April which BTW refers also to your book.)
> > Many thanks in advance.
>
> Because most re-arrangements of the sboxes are linearly weak. I have a
> paper on it [that I found off the web] if you like I could email it to
> ya.
It is better if you tell the URL, so that all of our group could
benefit from that information. As said in another thread, I suspect
(because I haven't the paper at hand to verify) that Biham and
Shamir examined only the case where re-arrangements are done
identically in all rounds. Doing different re-arrangements in
different rounds would even essentially render their differential
analysis difficult (as compared to the standard arrangement), I
conjecture. I mentioned about the eventual possibility of weakness.
My point is that that can be (highly) over-compensated by the
increase of effective key length, resulting in a high netto
increase of strength of the algorithm.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Sun, 09 Apr 2000 10:45:13 +0200
[EMAIL PROTECTED] wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > However, does the amount of informations, that really deserve
> > the etikette of secrets, have proportionately increased? Certainly
> > not. Due to the fact that most informations being exchanged today
> > are interceptable by malicious agencies and due to the developments
> > in economy etc. etc., there are doubtless more informations that
> > need to be protected than previously, but rate of this increase is
> > incomparably slow as compared to the rate of increase of the total
> > volume of informations being processed, transmitted and stored, I
> > am convinced. (BTW, I very much doubt that top diplomatic secrets
> > today need to be formulated much longer than at the time of WWII.)
>
> My point was that in industry today (the people the federal encryption
> standard are designed for :) there are two common scenarios.
>
> 1. They have a vast amount of confidential information that they'd
> like to store on encrypted disks. (Historical records, off-site
> backups, trade secrets, etc) For terabytes of information, the speed
> of the cipher is important.
>
> 2. They have vast amounts of confidential data online and traversing
> the wire. They know it's a risk, but they really need to link the
> computer systems in Akron and Moscow. Depending on the size of the
> link, speed is also an issue.
As I said, the volume of informations that need protection has
much increased compared to the past. But not all such informations
need to be protected by strong algorithms. Juwels and diamonds
need to be put in a strong safe, but, to avoid tables and chairs
from being stolen, locking one's door is sufficient. Isn't
the fast (though 'broken') DES sufficient for protecting most
of the security sensitive stuffs. For the rest, it is my point
that one could use 3DES and also adapt DES (using minor variations)
to achieve higher strength, so that AES is not yet necessary.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Sun, 09 Apr 2000 10:45:49 +0200
Tom St Denis wrote:
> I don't understand what MK's original argument is? Serpent for example
> is directly *based on* the analysis of previous ciphers, that's why it's
> so secure. So what is wrong with AES?
The point is that one can effectively USE the previous ciphers,
without spending great efforts to design new ones. If the elevator
of a building is defect, one tries to repair it. One doesn't pull
down the building and build a new one for that.
> The whole purpose of AES were to find a replacement for DES stronger
> then 3des right? Then all the AES finalists are *already* better then
> 3des?
Maybe, maybe not. Who REALLY knows (or will REALLY know)?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Date: Sun, 09 Apr 2000 10:53:31 +0200
Johann Hibschman wrote:
>
> Mok-Kong Shen writes:
>
> > I am afraid that because of my poor knowledge I am yet far from a
> > proper understanding of your argumentation.
>
> > The card is an ace has 0.391 bits.
>
> > The card is not an ace has 0.115 bits.
>
> > Now whether the card is an ace or not can be considered to be
> > a binary decision. How could the sum 0.391 + 0.115 = 0.506
> > be less than 1?
>
> It's because you already know what the most likely answer is.
> Odds are, if you guess "not an ace", you'll be right.
I don't understand. There are only two possible answers. I just
look at the 'answering device' as a black box and want to know
how many bits come out of it.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: GSM A5/1 Encryption
Date: 9 Apr 2000 09:54:35 +0200
In article <[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> Guy Macon wrote:
>>
>> In article <8cnq2j$kjs$[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] (David A. Wagner) wrote:
>>>
>>>In article <8clt2n$skh$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>>>> A Silent Frame is a Silent Frame regardless if the cipher is strong or
>>>> week, and will provide plaintext to the cryptoanalyst....My question
>>>> was, how to avoid that?
>>>
>>>With a (modern) strong cipher, there's no need to avoid it,
>>>because (modern) strong ciphers are supposed to remain unbreakable
>>>even if the adversary has some known plaintext.
>>
>> I disagree based on philosophy. One should do both. Use a cipher
>> that is believed to be resistant to known plaintext attacks, *AND*
>> avoid having known plaintext in case you are wrong. In general,
>> avoiding standard beginning and ending texts (From: Guy Macon and
>> most 4 line sigs come to mind) is cheap insurance. I usually add
>> a random number of random bytes at the beginning and end of my
>> plaintext and don't bother with a removal method on the other
>> end - any human reading it can tell when the random stops. This
>> is also very cheap insurance.
>
> Your thinking is flawed. The very definition of a secure cipher is one
> where you can't learn anything from a relatively short amount of known
> plaintext.
Your thinking is what's flawed. Of course of the cipher is truly secure,
it's not needed. But how do you know if it really is truly secure? I.e.
how can you be certain that no future advance in cryptology will break
the cipher, it that the cipher doesn't contain some hidden flaw nobody
has discovered yet?
By avoiding to provide known plaintext one adds some protection in
the case the cipher in the future would turn out to be less secure
than currently believed.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Sun, 09 Apr 2000 11:00:47 GMT
Mok-Kong Shen wrote:
>
> Tom St Denis wrote:
>
> > I don't understand what MK's original argument is? Serpent for example
> > is directly *based on* the analysis of previous ciphers, that's why it's
> > so secure. So what is wrong with AES?
>
> The point is that one can effectively USE the previous ciphers,
> without spending great efforts to design new ones. If the elevator
> of a building is defect, one tries to repair it. One doesn't pull
> down the building and build a new one for that.
Yea, but for anyone designing new applications [like me] why would I
want to go back to that old, slow cipher? That doesn't make much sense
from where I am sitting.
> > The whole purpose of AES were to find a replacement for DES stronger
> > then 3des right? Then all the AES finalists are *already* better then
> > 3des?
>
> Maybe, maybe not. Who REALLY knows (or will REALLY know)?
Well I think the leading cryptographers in the field really have a good
feel for what they can do, and for the most part they can tell when a
cipher is secure and when one is not.
Tom
------------------------------
From: [EMAIL PROTECTED] (Svend Olaf Mikkelsen)
Subject: Re: Is AES necessary?
Date: Sun, 09 Apr 2000 11:55:54 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Svend Olaf Mikkelsen wrote:
>>
>> Tom St Denis <[EMAIL PROTECTED]> wrote:
>>
>> >> I am virtually ignorant in hardware matters. But I wonder why
>> >> pipelining is not applicable to 3DES, i.e. the 3 modules may be
>> >> processing 3 consecutive blocks of informations simultaneously.
>> >> That way, there would be no time penality, excepting the setup
>> >> time of the pipe.
>> >
>> >Just off the top of my head, you can't use CBC mode with that can you?
>>
>> Decryption, yes.
>> Encryption, no.
>
>I don't understand. Could you please explain that?
In CBC (Cipher Block Chaining) mode encryption you XOR the plaintext
with the previous ciphertext before encryption.
In CBC mode decryption you XOR plaintext with the previous ciphertext
after decryption.
I.E.: For encryption you do not know the initialization vector before
the previous block is done. For decryption you know all initialization
vectors from the beginning.
It applies to all block ciphers that CBC mode decryption can be done
in parallel on multiprocessor machines.
--
Svend Olaf
------------------------------
** 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
******************************
