Cryptography-Digest Digest #951, Volume #8 Fri, 22 Jan 99 21:13:02 EST
Contents:
Re: Help: Which secret key cipher? (Dorina Lanza)
Re: Help: Which secret key cipher? (Dorina Lanza)
Re: Cayley (John Savard)
Re: Pentium III... ([EMAIL PROTECTED])
Re: Strong Encryption for 8086 (16 bit) (Phil Carmody)
Re: Cayley (John Savard)
Re: Metaphysics Of Randomness ("Trevor Jackson, III")
Re: Metaphysics Of Randomness ("Trevor Jackson, III")
Re: Pentium III... (Terry Ritter)
Re: Metaphysics Of Randomness ("Trevor Jackson, III")
Re: Metaphysics Of Randomness ("Trevor Jackson, III")
S-box cycles ([EMAIL PROTECTED])
Re: Help: Which secret key cipher? ("Trevor Jackson, III")
Re: 3DES in EDE mode versus EEE mode ([EMAIL PROTECTED])
----------------------------------------------------------------------------
Date: Fri, 22 Jan 1999 18:23:46 -0500
From: Dorina Lanza <[EMAIL PROTECTED]>
Subject: Re: Help: Which secret key cipher?
Terry Ritter wrote:
> On Fri, 22 Jan 1999 10:21:56 -0500, in <[EMAIL PROTECTED]>,
> in sci.crypt Dorina Lanza <[EMAIL PROTECTED]> wrote:
>
> >[...]
> >The other complaint about OTP-style security is that it takes too much pad
> >material. However, the density of data storage is now so high that very
> >infrequent use of a secure channel can support long term (months or years)
> >worth of traffic in most cases.
>
> That sounds *extremely* dangerous. As long as that data exists, it is
> a danger to information past and future.
True. The same applies to all crypto keys. Dpes this mean we dispose of them
after a year? No, we retain them for a long as necessary and no longer
> The ideal would be to get weekly or daily pads, use what is needed,
> and discard the rest. In this way any compromise of a particular pad
> ends when we get a new one.
What compromise threats are you concerned about? Copying the pad? Size helps
you there.Frequent usage of a physical channel invites interception. The idea
that a "secure channel" is perfect is ludicrous given the ease with which they
can be violated. Consider that a "brute force" attack has a completely
different meaning in the real world. Thus we want to limit the risks of the
overall system by minimizing the amount of traffic that has to be physically
secured rather than logically secured.
> A huge pad not only risks more messages, but, since it is held for a
> long time, is more likely to be compromised.
No more so than any other key we have to hold for decades. After all, we have
to secure the plaintext somehow if it is to be retained. Whatever provision we
use fo the plain text will be suitable for the pads.
------------------------------
Date: Fri, 22 Jan 1999 18:26:23 -0500
From: Dorina Lanza <[EMAIL PROTECTED]>
Subject: Re: Help: Which secret key cipher?
Darren New wrote:
> > The ideal would be to get weekly or daily pads, use what is needed,
> > and discard the rest. In this way any compromise of a particular pad
> > ends when we get a new one.
>
> Or... copy the pad onto a number of individual CDs/tapes/hard drives and
> then blow away the DVD, using it only to transport the pad.
>
> I think a more interesting question is whether it's possible to build a
> physical environment that makes tampering impossible. I.e., unless I
> personally courier it, how do I know the courier didn't copy the pad? Is
> there secure envelope technology that would make it prohitively
> expensive to access the DVD and put it back without someone else
> noticing?
You can probably make copying arbitrarily hard by spending lots of money on
it, but an alternate path to security is to reduce the set of *people* who
have to be trusted (couriers of whatever) to the minimum by amking the best
use of the few who are most trusted. Data density help here.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cayley
Date: Fri, 22 Jan 1999 23:21:51 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>[EMAIL PROTECTED] wrote:
>> The logical next step after quaternions, therefore, had to use a different
>> name - octaves - when it was developed...by Cayley. An octave has eight
>> components, one real and seven imaginary.
>Could you give a literature reference to octaves? Thanks in advance.
Hmm. My reply from home hasn't showed up on this server.
Early books on vector algebra or quaternions - such as one by Tait and
Mortimer - should have such references. Even an old Britannica might.
I looked up the table in General Algebra by Kurosh.
But it shouldn't be *too* hard to hunt them down in a math library.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Pentium III...
Date: Fri, 22 Jan 1999 22:36:32 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> [EMAIL PROTECTED] wrote, in part:
>
> >John, the random number generators found in hardware and software today are
> >almost always 32-bit generators, meaning they have only 32-bit internal
> >states. This is equivalent to a 32-bit crypto key, which is far too small to
> >make a secure cryptographic system. Nobody will worry about exporting such a
> >chip.
>
> >If you are looking for something more secure, see my article "One-Time Pad
> >Cryptography" in the Oct. 1996 Cryptologia.
>
> I'm sure I've seen the article, even if I don't remember it offhand.
> Could it be the one where the claim that the one-time-pad is
> "impractical" is countered?
>
> I'm well aware that typical 'random number generators' are mixed
> congruential - with 32-bit, or even 16-bit, internal states.
>
> However, unless I am very much mistaken, the reference to a 'hardware
> random number generator' on the Pentium III does *not* refer to
> anything of that type, but to a built-in source of true randomness, by
> means of electrical noise or the like. It is that which is at the
> present awkward and expensive to add to a PC, while a PRNG is easy to
> write in software (and Windows even provides a shared PRNG with a
> global seed, seeded by the clock at startup, to approximate true
> random behavior - in a fashion adequate, say, for games, if not for
> cryptography), and thus it is that which remedies a fundamental
> omission.
>
> John Savard
> http://www.freenet.edmonton.ab.ca/~jsavard/index.html
>
It would be very nice if there was a true random source since one
could use it to raise the entropy of messages before they are encrypted.
But in reality. It would be very hard to check from a user point
of view as to the fact that it is a true random number generator.
Remember how the NSA cooked the Swiss crypto stuff. That was
overseas. With intel being here in the US. The odds of no NSA
involwment begins to approach that of a snowball in hell.
David A. Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Phil Carmody <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.asm.x86
Subject: Re: Strong Encryption for 8086 (16 bit)
Date: 22 Jan 1999 21:04:58 GMT
Andrew Lord wrote:
> I'm looking for a *strong* encryption algorithm the has been implemented
> in 8086 assembler to use on the Psion PDA. ( Eg TwoFish, SkipJack. )
> I've got "intermediate" 8086 experience, lots of C and ZERO cryptoanalysis, so
> I could struggle at porting some C code, but it would be ever so nice if
> someone has implemented and tested this for 8086 already. Or can recommend an
> algorithm that is the easiest to implement on a 16bit processor.
Borrow Bruce Schneier's Cryptography book from your library, it has C
source.
Then don't be to fast too assert that you must use assembly language
until you are certain that C (for example) won't do the job.
'_The_ Psion PDA' - which Psion PDA?
In particular which Psion has an x86 processor? Mine's ARM powered.
FatPhil
--
Phil Carmody
Not speaking for or on behalf of Nokia Telecommunications.
"At the showing of blue movies at Scotland Yard I take the precaution
of removing my glasses, which reduces the whole messy business to an
impressionist blur." John Mortimer, QC, 1978
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cayley
Date: Fri, 22 Jan 1999 23:50:21 GMT
Oh, yes: you can also try
http://math.ucr.edu/home/baez/week61.html
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
Date: Fri, 22 Jan 1999 19:23:10 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
R. Knauer wrote:
> On Fri, 22 Jan 1999 11:31:27 -0500, Dorina Lanza <[EMAIL PROTECTED]>
> wrote:
>
> >No. The filtered key stream is not biased. Every entry in the pool is equally
> >probable.
>
> A TRNG must be capable of generating all possible sequences of a given
> length, as well as each of them being equiprobable. A filtered pool
> does not meet the first criterion, even though it meets the second.
Why? Please defend your claim regarding the first criteria.
> >he fact that the poll contains 2^N - 2 entries instead of 2^N entries
> >does not create a vulnerability.
>
> I fully agree. I am an advocate of using the two pathological
> sequences, 000...0 and 111...1, as diagnostics for a broken TRNG,
> since both are symptomatic of the two most common failiure modes - an
> shorted output and an open output respectively.
>
> But when you start filtering for such conditions as bit bias or other
> statistical conditions, then you are distrubing the distribution in a
> way that could lead to vulnerability.
In a related post I proposed a drastic filtration system. Please quantize the
vulnerability it creates.
------------------------------
Date: Fri, 22 Jan 1999 19:20:44 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
R. Knauer wrote:
> On Fri, 22 Jan 1999 11:28:39 -0500, Dorina Lanza <[EMAIL PROTECTED]>
> wrote:
>
> >Perhaps every message should look like a false one.
> >I.e., every plaintext should be enciphered not so it looked like garbage, but that
> >it looked like a letter from long lost Aunt Jane. This could be implemented by
> >defining a search path through the available OTP pad space. Given a plaintext one
> >searches for an appropriately formatted ciphertext. Is this less secure that
> >plain-in-garbage-out? Not that I can see.
> >
> >The above description is silly not because it would be ridiculously slow, but
> >because every message would need a prefix of the form "pad number N" to enable the
> >receiver to recover the original message. The width of the pad number is of the
> >same size as the length of the entire message *space*. So the prefix size would
> >exceed the size of the actual cipher text. But it would be secure. (Let's see,
> >it's provable, obscure, and inefficient; best of all worlds!)
>
> If you XORed the message with the Aunt Jane text, you would generate a
> key to send that key thru a secure channel, then the Aunt Jane cipher
> could be decrypted on the other end.
>
> But this system is vulnerable - the key has been generated from mixing
> two text streams which results in a poorly constructed key for the OTP
> cryptosystem.
>
> If a secure OTP could be generated from the XOR of two text streams,
> who needs a TRNG?
Sure. That's a valid criticism of the letter-from-Aunt-Jane kind of camoflage, but
only if you start with a given letter from Aunt Jane. If you're willing accept *any*
letter than looks like it came from Aunt Jane then you aren't mixing two text streams.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Pentium III...
Date: Sat, 23 Jan 1999 00:15:02 GMT
On Fri, 22 Jan 1999 20:19:47 GMT, in
<78amgn$eu7$[EMAIL PROTECTED]>, in sci.crypt [EMAIL PROTECTED]
wrote:
>[...]
>1) clock skew bit generator
>
>Basically spin the processor incrementing a memory location (at like 200
>million increments/sec) and then periodically (from a different clock source)
>interrupt the processor and extract a single bit from the count. Repeat this
>for as many bits as needed. Production rate as high as 1000 bits/sec can be
>achieved. Unless the processor code path, cache hits, bus wait states, etc.
>between each bit sample is identical, the bit will not be predictable. Also
>the small jitter in the two clock sources will cause the relationship between
>them to jitter, causing the sample value to vary. Typical clock crystals are
>I believe +/- 25 ppm.
I think this has taken on the status of a crypto "old wives tale,"
and one might well wonder where it comes from. I have been writing
about it for quite some time (see:
http://www.io.com/~ritter/RAND/NICORAND.HTM
especially
http://www.io.com/~ritter/RAND/92062703.HTM
and
http://www.io.com/~ritter/RAND/92110301.HTM ),
and I dispute the idea that this is particularly "random." What it is
is "complex," but this is the complexity of digital logic state
machines whose structure is known.
Computer clock signals are developed from analog crystal oscillators,
specifically *because* they are fairly accurate and do not drift much
over time. Although crystals do have slightly different frequencies,
if we know approximate frequencies, we can develop the precise ratio
by looking at the sampled results. Although crystal oscillators do
drift over time and temperature, they don't drift very much, and they
tend to follow a similar pattern from power-on when they do.
One can handwave about "processor code path, cache hits, bus wait
states," but the "processor code path" is the program, and it seems
quite likely that the program used for random bits once will be used
again. So the cache contents will tend to be the same, as will the
bus wait states. We are talking about essentially error-free digital
systems: There is no reason to expect these things to be "random,"
just complex.
In practice, the major factor which encourages the belief in the
"randomness" of such systems is probably memory refresh, which
interrupts processing periodically and -- on the surface --
unexpectedly. But by "periodically" we typically mean a
crystal-controlled precise period between interrupts. We will know
the expected period, as well as the computation consequences when the
interrupt is taken, and any deviations from this will just help us to
further refine the exact internal state of the hardware.
The "jitter" in a crystal oscillator is best modeled as noise in the
analog-to-digital conversion -- a bipolar cycle-by-cycle phase
difference. The magnitude is tiny and typically normally-distributed,
so small values are frequent, but large values are rare. So the
probability that this sort of jitter will affect the digital result in
any particular cycle is very small. But it *will* show up eventually,
and when it does, it will reveal the exact internal state of the
oscillator. (That is, that it was close enough to the digital
square-wave edge to be affected by the tiny noise variation.)
I claim that these sorts of RNG are best understood as fairly-complex
PSEUDO-random generators, with only small amounts of uncertainty
beyond their internal hardware state. It would be extremely unwise to
hope they could oppose a well-equipped and well-financed attack on
their sequence.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Date: Fri, 22 Jan 1999 19:16:16 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
Patrick Juola wrote:
> In article <[EMAIL PROTECTED]>,
> Dorina Lanza <[EMAIL PROTECTED]> wrote:
> >Patrick Juola wrote:
> >
> >> In article <[EMAIL PROTECTED]>,
> >> Dorina Lanza <[EMAIL PROTECTED]> wrote:
> >> >> > You are making the mistake of trying to characterize a number as
> >> >> > random on the basis of some inherent property, like lack of
> >> >> > correlation or bias or somesuch. But we know that a characterization
> >> >> > like that will not properly characterize crypto-grade random numbers.
> >> >> > Only the characterization of the generation process is proper.
> >> >>
> >> >> Holy Cow Bob, if I give you a certifiably random string (say, with a
> >> >> gorgeous Allan Deviation plot) and present it to you as crypto-grade, and
> >> >> you give me one of your crypto-grade strings, I'll be able to test and
> >> >> certify that your crypto-grade string is random, but you have no way of
> >> >> knowing that I fibbed to you about the string I gave you because there is
> >> >> no test to distinguish between crypto-grade strings and random strings. We
> >> >> have discovered a distinction without a difference!
> >> >
> >> >I think it's worse than this. The statement that the output of a filtered
> >> >random source is non-random is false. If, for crypto purposes, we exclude
> >> >pathological values such as zero from a TRNG we still have an equiprobable
> >> >selection from a pool of possible values. The fact that the pool is slightly
> >> >smaller does not reduce the randomness because the selection process is the
> >> >same. The entropy would be slightly less, but not the independence of the
> >> >samples.
> >>
> >> "The entropy would be slightly less" is sufficient to make the
> >> resulting system less than perfectly secure. At this point it's
> >> just Yet Another stream cypher.
> >
> >False. A filtered pad is not less secure than an unfiltered pad. (Now, before we
> >spin lock on yes/no/yes/no..., please give a summary of your reasons for
> >concluding the filtering weakens an OTP.
>
> Simple statistics. If you filter the pad -- and I know that (and how)
> you filter the pad, which is a standard and defensible assumption --
> then I can eliminate potential decryptions.
>
> A simple example : if I know that your two possible messages are
> "attack at noon" and "attack at dawn", and I receive a cyphertest message
> reading "attack at noon", I cannot, in fact, infer that you intend to
> attack at noon *OR* at dawn.
>
> If I know that you throw away all pads that are all zero, and I receive
> the message above, I know that you do *NOT* intend to attack at noon,
> I therefore know that you will attack at dawn.
>
> q.e.d.
>
> Unlikely? Yes -- but no more unlikely than the all zero pad being
> generated in the first place.
>
> (n.b. -- if the message I receive reads "attacd at nown", and you use
> a stronger filter of never allowing six successive zeros, then I can
> still unbutton your message. The reason being the pad necessary to
> produce "attack at noon" would be an illegal pad -- and hence you're
> still attacking at dawn).
We are covering two issues as if they are one. The original premise was that filtering
renders TRNG was unsuitable for use in an OTP. We're now debating whether a filtered
key is less strong than an unfiltered key.
The answer to the former is NO, noy at all. The answer to the latter is YES, but by
very little..
Of course a key generated from a smaller space is less strong. If we throw out the all
zeros case we reduce the key space by 1/(2^N), thus reducing the cost of a brute force
attack by a like percentage. Whoop de do.
> >My reasons for concluding the opposite are contained in this
> >gedanken experiment. [snip]
>
> Math generally trumps gedanken experiments. Math *plus* examples generally
> trumps even math. 8-)
Crap. There's an obvious answer to this objection. Assume we drastically increase the
filtration by raising the acceptability threshold to invalidate any key more than
approx 0.675 standard deviations from the mean. This will eliminate one half of the
potential keys. This is a real strength reduction in contrast to the immeasurably
small one described above.
Now, as cipher designer, I have to fix this "weakness" in the cipher. Whatever shall I
do? I'll add one, single, extra bit of padding to the message. Now, since I'm
probably implementing this on a computer using eight bit bytes, I'll probably add at
least eight bits. Since modern processors cluster near 32 bits let's assume my block
processing operates on 32-bit quantities. Thus, on average, I'll have to pad the
message by 16 bits.
Viola. Given 16 bits of padding on average, I could raise the filtration threshold
until the density of ones and zeros was very close to even and still be secure.
> >
> >> As to whether or not the loss of entropy is significant to make a
> >> practical difference -- that depends on the degree of filtering.
> >> What you do really buy by doing the filtering? Not much --- and
> >> every time the filter triggers introduces a weakness.
> >
> >Among other things, a crypto system needs to inhibit the identity operation on
> >plaintext. I.e., the idea of a crypto system that includes the possibility that
> >ciphertext == plaintext has a flaw. Mathematically, the system including the
> >possibility is infinitesimally "stronger" due to the larger search space, but
> >that's not the unit of measure for crypto strength.
>
> This is simply and utterly false. This is, in fact, one of the major
> weaknesses in the Enigma system. By inhibiting the identity operation,
> one made it very much easier to evaluate and discard wrong or unlikely
> decryptions.
This is an unrelated reference. It may also be malformed. IIRC, which I admit I may
not be, the enigma system had a symmerty in that the connections went back through
every rotor, and this symmetry reduced the search space so much the analysts were able
to deduce the conection pattern.
I agree that zeros are often way out of proportion in importance. I think Heinlein
said that most hard-science Nobel prizes are based on a previous researcher missing a
trivial root, a zero, somewhere.
Inhibiting the identity operation is not a "flaw" in a modern cipher. For example, how
many of the AES candidates allow identity operations? Without looking, I'd bet real
money that none of them do.
You did not respond to the concepts presented in the tail of the original post. Do you
intend to?
------------------------------
Date: Fri, 22 Jan 1999 20:14:11 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
Patrick Juola wrote:
> In article <[EMAIL PROTECTED]>,
> Dorina Lanza <[EMAIL PROTECTED]> wrote:
> >R. Knauer wrote:
> >
> >> On Thu, 21 Jan 1999 13:26:52 -0500, Dorina Lanza <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >> >I think it's worse than this. The statement that the output of a filtered
> >> >random source is non-random is false. If, for crypto purposes, we exclude
> >> >pathological values such as zero from a TRNG we still have an equiprobable
> >> >selection from a pool of possible values. The fact that the pool is slightly
> >> >smaller does not reduce the randomness because the selection process is the
> >> >same. The entropy would be slightly less, but not the independence of the
> >> >samples.
> >>
> >> >This idea of post-processing contaminating the source is fallacious.
> >>
> >> What you have just said is completely incorrect for crypto-grade
> >> random numbers.
> >>
> >> If you do what you have just proposed, you will be vulnerable to a
> >> Bayesian Attack.
> >
> >No. The filtered key stream is not biased. Every entry in the pool is equally
> >probable. The fact that the poll contains 2^N - 2 entries instead of 2^N entries
> >does not create a vulnerability.
> >
> >Please indicate otherwise if you are able.
>
> The filtered keystream, treated as a set of all possible 2^N strings, is
> biased. Since the possible plaintext is one of that set, you need to
> do the stats over the entire set -- not only over the set of potential
> keys.
You are using the term "biased" in a manner with which I am not familiar. Bit bias
would indicate a difference in the incidence of ones and zero. Throwing out the two
homogeneous values would not change the relative incidence of ones and zeros. Until I
know you're definition I'm going to assume you mean "damaged" in some sense. (I think
there's no problem here, but I want to be sure).
> Reductio ad absurdam -- instead of throwing out only 2 keys, throw out
> K. If K == 2^N - 1, you have no security whatsoever. Please define
> the maximum K at which you have "perfect security" and provide reasons
> for your answer.
>
> -kitten
>
> (Hint : the minimum such K is zero.)
OK. First, I think we agree that "perfect security" means maximum attacker effort per
bit. Further, the maximization of that function is acheived when the search space is
as large as possible. Clearly the maximum is 2^N. However, I defy you to find a
non-cryptologist customer who thinks that a system in which the ciphertext might be
the same as the plaintext is "perfect". I believe that the "neighborhood" of 2^N,
such as 2^N-1, is effectively as secure as "perfect" security. Mathematically, it is
(N-1)/N as secure.
Now there's an interesting question regarding the "per bit" above. What kind of bit?
If it is per message bit, we can xmit more cipher text than there is plain text. If
it is per xmitted bit we'll want to keep the ciphertext close to the same size as the
plaintext. If we compromise by saying the ciphertext can be as much as twice the
plaintext, we can support exremely radical filtration without damage to our security.
For example, if we filter all keys but those with perfectly even ratios of ones and
zeros, we'll throw out most of the keys, leaving those that change half the bits in
the plain text. By using a key twice the size of the plain text (ridiculously
inefficient, but we're only interested in strength in this example), we can provide
more to search than 2^N "perfect" keys.
Note that this is way too extreme for my taste, but it's a point at which I think
there might be weaknesses you can identify. Can you?
------------------------------
From: [EMAIL PROTECTED]
Subject: S-box cycles
Date: 22 Jan 1999 23:50:45 GMT
I have what I think is a simple question:
How important, in terms of cryptographic strength, is whether or not
an S-box's cycle length is equal to its size?
------------------------------
Date: Fri, 22 Jan 1999 20:31:45 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Help: Which secret key cipher?
Terry Ritter wrote:
> [major snip]
> We don't remember one-time pads.
True. We shred/burn/stir-ashes or whatever. I do not recommend keeping OTP CDs
around at all. I'd recommend magnetic media that can be erased after each chunk is
used.
There's a major difference between the distribution media in which density is an
issue, and the repository media in which convenience is an issue.
I shouldn't have snipped so much because there no reason NOT to encrypt an OTP. A
hierarchy of pads is easy to envision. Assume a master key in some heavily guarded
repository and message keys masked by the master. This would provide some internal
security in the organizations using the system.
As you described previously, we usually have layers of protection for keys. We'd
still need that.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 3DES in EDE mode versus EEE mode
Date: Sat, 23 Jan 1999 01:06:45 GMT
[EMAIL PROTECTED] wrote:
> When just one key is used in 3-DES EDE, key schedule cannot be simply
> repeated 3x in exaustive key search, which affords a slightly higher workload
> per searched key than EEE in specialized hardware (and in software, of
> course) that could pre-compute the key schedule just once for all 3x.
Did I miss something? One key encrypt-decrypt-encrypt is equivalent
to a single encrypt. If I'm testing keys to break 1-key EDE, of course
I'm going to run encrypt, not encrypt-decrypt-encrypt.
--Bryan
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** 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
******************************
