Cryptography-Digest Digest #774, Volume #11 Mon, 15 May 00 00:13:00 EDT
Contents:
Re: S-BOX Construction Tutorial? (John Savard)
Re: Notes on the "Vortex" block cipher (Tim Tyler)
Re: (May 11, 2000) Cipher Contest Update (Tim Tyler)
Re: Destructive crypting (Tim Tyler)
Yet another sci.crypt cipher (Tom St Denis)
Re: Unbreakable encryption. (Anthony David)
Re: S-BOX Construction Tutorial? (Terry Ritter)
Re: Notes on the "Vortex" block cipher (Terry Ritter)
Definition of "Broken" Cipher (Tom St Denis)
Re: Notes on the "Vortex" block cipher (Tom St Denis)
Re: S-BOX Construction Tutorial? (Tom St Denis)
Re: Yet another sci.crypt cipher (Tom St Denis)
Re: Key generation for lja1 (Benjamin Goldberg)
Re: About Hardware RNG ("Steve and Darla Wells")
Re: How does one test an encryption algorithm? (SCOTT19U.ZIP_GUY)
Snappy Block Cipher (key schedule) (Tom St Denis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: S-BOX Construction Tutorial?
Date: Mon, 15 May 2000 00:01:58 GMT
On Sun, 14 May 2000 20:43:51 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>My approach is to try to eliminate every ghost of weakness I can see.
>I suppose others have different approaches.
It does appear that many others seem to have the approach of not
putting anything in a cipher that they don't understand...which leads
to using only things that _are_ potentially weak (but strong enough
not to fall to known attacks).
I prefer your approach, and I try to use it myself.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Notes on the "Vortex" block cipher
Reply-To: [EMAIL PROTECTED]
Date: Sun, 14 May 2000 23:42:03 GMT
Bruce Schneier <[EMAIL PROTECTED]> wrote:
: Tom St Denis <[EMAIL PROTECTED]> wrote:
:>I noted in the F function there is a very simple compression of four 16
:>bit values given
:>
:>F(a, b, c, d) = ((a ^ b) + c) ^ d -> a'
:>
:>Then only a' is passed thru the sboxes.... Wouldn't it be possbible to
:>create a quadruple so that the input difference is fixed?
: All the non-linearity is in the carry bit. If this is a straight
: Feistel network with this round function, you're going to need a LOT
: of rounds to be secure.
I don't think that's what is being proposed.
The round function seems to be quite complicated.
It appears that there's also an 8-bit s-box, applied to both halves of a,
b, c and d in turn, and then to all the bytes in the block.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: (May 11, 2000) Cipher Contest Update
Reply-To: [EMAIL PROTECTED]
Date: Sun, 14 May 2000 23:55:08 GMT
David A Molnar <[EMAIL PROTECTED]> wrote:
: What about an attack which just distinguishes the cipher from an
: "ideal" or "truly random" permutation over the blocksize? That is,
: suppose I am able to prove that a cipher always outputs blocks with even
: parity or something else that doesn't "look random," but I can't turn
: that into a key-recovering or plaintext-recovering attack. What happens
: then? [...]
I think a block cypher [i.e. keyed permutation] that always outputs blocks
with even parity is impossible ;-)
As for distinguishing the output from that of a random permutation - I
personally think some sort of attack that provides information about
key or plaintext bits - and which takes less effort than brute force -
should be required.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ This tagline no verb.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Destructive crypting
Reply-To: [EMAIL PROTECTED]
Date: Mon, 15 May 2000 00:07:13 GMT
Daniel Åkerud <[EMAIL PROTECTED]> wrote:
: Is there a one-way hash algorithm that takes an arbitrary key as a parameter?
Yes: "Message Authentication Codes" (MACs).
Sometimes folks seem to use use Hash(Key,Message) as a way of building
MAC(Message). Doing this may be slower than using a dedicated MAC.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Goodbye cool world.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Yet another sci.crypt cipher
Date: Mon, 15 May 2000 01:52:18 GMT
I just finished my package for another block cipher. I don't have the
warm fuzzy feeling about it, but I would still like to see what you
guys can do to it. (no claims here).
The cipher is geared towards small systems and only requires 16 bytes
to hold the key, it's not terribly fast but it is very compact and
simple to code even from memory (minus the sbox).
You can get the paper from
http://www.tomstdenis.com/snappy.txt
(hopefully Adam will add this to the pile).
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Unbreakable encryption.
From: Anthony David <[EMAIL PROTECTED]>
Date: 15 May 2000 12:09:14 +1000
[EMAIL PROTECTED] writes:
[boggling stuff snipped]
Let me guess.
Anthony Stephen Szopa rang you up and told you that
sci.crypt had a free Snake Oil slot?
--
=========================================================
Gambling: A discretionary tax on | Anthony David
those who were asleep during high | Systems Administrator
school mathematics classes |
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: S-BOX Construction Tutorial?
Date: Mon, 15 May 2000 02:09:39 GMT
On Sun, 14 May 2000 21:12:56 GMT, in <8fn4sg$81r$[EMAIL PROTECTED]>, in
sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Terry Ritter) wrote:
>>
>> On Sun, 14 May 2000 15:53:28 GMT, in <8fmi5k$kl1$[EMAIL PROTECTED]>, in
>> sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>>
>> >In article <[EMAIL PROTECTED]>,
>> > [EMAIL PROTECTED] (Terry Ritter) wrote:
>> >>
>> >> On Sat, 13 May 2000 14:49:10 -0700, in
>> >> <8fjm8v$nqr$[EMAIL PROTECTED]>, in sci.crypt "Simon
>Johnson"
>> >> <[EMAIL PROTECTED]> wrote:
>> >>
>> >> >Does any one have a PDF or HTML S-BOX construction tutorial?
>> >> >If So please, leave a post with the URL as a reply to this message
>> >thanxs.
>> >>
>> >> "S-boxes" are used in different ways in different ciphers, making
>> >> different things more or less important. Any particular
>construction
>> >> approach probably will be oriented toward a particular design, and
>the
>> >> approach you need should be oriented toward your particular needs.
>> >
>> >Some overall characteristics such as linearness and differential xor-
>> >pair tables are universally important. If your sbox is a linear
>> >mapping of Fn -> Fm then it's kinda useless isn't it?
>>
>> That depends upon what one wants to do. Now, an "identity
>> transformation" *would* be useless . . . unless of course that happens
>> to be the extremely-improbable side-effect of choosing tables at
>> random. There is *always* a possibility of weakness in ciphering: An
>> opponent just might happen to choose the right key at random.
>
>Which means the keyspace isn't flat. That's a bad thing.
What are you talking about?
Every enciphering has some key. Any opponent might just try that key
at random. Does that make the cipher weak? Does that make the
keyspace non-flat?
Similarly, if we construct S-boxes such that they are a "random"
selection from among the universe of such S-boxes, does the fact that
one of these is the "identity transformation," others are close, and
many are somewhat linear make any difference at all (assuming the
universe of possible S-boxes is "large enough")?
>>> Typically, a modern S-box has an even binary power number of elements
>> >> (e.g., 2**4 or 16, 2**8 or 256, etc.). There is one element of
>each
>> >> possible value and these are permuted or shuffled. Up to this
>point,
>> >> all we need to know is how to count and how to shuffle.
>> >>
>> >> Some designs use "small" (e.g., "4-bit") S-boxes, but such small
>boxes
>> >> are often weak, and so should be tested before being used. There
>are
>> >> various tests including diffusion, Boolean function nonlinearity,
>> >> etc., with at least one new test found for every new attack on S-
>box
>> >> structure. An alternative is to use "large" ("8-bit" or larger)
>> >> S-boxes, but that is a cipher design decision.
>> >
>> >Yeah I agree with the less-non-linearness of small sboxes, but can
>you
>> >point me to an attack on Serpent that relies on the sboxes?
>>
>> That is a fundamentally wrong question: If we must actually break a
>> cipher to consider it weak, we will never have time to show just how
>> weak our many ciphers may be. It is unreasonable to simply assume
>> that a cipher strong unless explicitly proven weak. Just because you
>> don't see a way to exploit the problem is no reason to allow the
>> problem to exist to somehow be exploited.
>>
>> My approach is to try to eliminate every ghost of weakness I can see.
>> I suppose others have different approaches.
>
>Conversely why is it a problem if it cannot be exploited? Using finite
>sized keys is a problem of *all* symmetric ciphers, but is that cause
>for alarm?
The problem is that we cannot prove that the problem cannot be
exploited. Just because *we* don't know how to do it does not mean
that it cannot be done. So, in my opinion, yes, having a preventable
weakness that we think is hidden and which we think cannot be used is
still cause for alarm.
The ideal would be to have several layers of different operations,
each of which we think is secure, and which would require every layer
to be somehow compromised before the cipher is broken. Having one
layer with a known weakness would seem to be both ignoring the goal
and tempting fate.
That said, it is of course trivially true that weak functions are used
in ciphers. I suppose the serious issue occurs when we have some
known weakness which, if somehow exploited, would accomplish one of
the steps needed for a break.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Notes on the "Vortex" block cipher
Date: Mon, 15 May 2000 02:11:27 GMT
On Sun, 14 May 2000 21:14:48 GMT, in <8fn500$82o$[EMAIL PROTECTED]>, in
sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Terry Ritter) wrote:
>>
>> On Sun, 14 May 2000 15:45:04 GMT, in <8fmhlt$k30$[EMAIL PROTECTED]>, in
>> sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>>
>> >[...]
>> >Yeah but in blowfish all of the input goes thru the sboxes. So you
>> >can't just say "Blowfish is similar so my cipher must be secure too".
>>
>> ...especially since there is no way to know that Blowfish is secure in
>> the first place.
>
>There has been some scrutiny of blowfish. I would trust it.
You can wish and hope and believe what you want, but there still is no
scientific basis for such trust.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Definition of "Broken" Cipher
Date: Mon, 15 May 2000 02:18:05 GMT
It's quite simple. You don't say your car is broken because of a dent
in the fender right?
Well if I can attack a cipher X, in 2^100 steps is it really broken?
Let's see, does it secure information? Yes. How is that broken?
I think the definition of "broken" for a cipher is when finding the key
and/or plaintext from ciphertext only is easier then brute forcing the
key.
Let's be realistic, getting 2^50 pairs of plaintext/ciphertext is not
possible for two reasons. a) Bandwidth, b) smart people re-key their
ciphers.
Realistically from a personal computer you may get around 2^10
ciphertext blocks from a single key, and maybe 2^20 from a server at
the most (if they don't re-key often).
Let's not forget that AES ciphers can fall with only 2^128 known pairs,
but have 256 bit keys, so is that technically broken? I don't think
so, but using common crypto-lingo it is technically easier to find
2^128 pairs then trying 2^256 possible keys, and therefore a "break".
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Notes on the "Vortex" block cipher
Date: Mon, 15 May 2000 02:38:56 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
>
> On Sun, 14 May 2000 21:14:48 GMT, in <8fn500$82o$[EMAIL PROTECTED]>, in
> sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> >In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (Terry Ritter) wrote:
> >>
> >> On Sun, 14 May 2000 15:45:04 GMT, in <8fmhlt$k30
$[EMAIL PROTECTED]>, in
> >> sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
> >>
> >> >[...]
> >> >Yeah but in blowfish all of the input goes thru the sboxes. So
you
> >> >can't just say "Blowfish is similar so my cipher must be secure
too".
> >>
> >> ...especially since there is no way to know that Blowfish is
secure in
> >> the first place.
> >
> >There has been some scrutiny of blowfish. I would trust it.
>
> You can wish and hope and believe what you want, but there still is no
> scientific basis for such trust.
By that same token, never drive a car, ride a bus, fly a plane, get in
an elevator, etc.. because you would have to trust those engineers too.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: S-BOX Construction Tutorial?
Date: Mon, 15 May 2000 02:37:52 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
> Every enciphering has some key. Any opponent might just try that key
> at random. Does that make the cipher weak? Does that make the
> keyspace non-flat?
>
> Similarly, if we construct S-boxes such that they are a "random"
> selection from among the universe of such S-boxes, does the fact that
> one of these is the "identity transformation," others are close, and
> many are somewhat linear make any difference at all (assuming the
> universe of possible S-boxes is "large enough")?
Actually yes it does. Blowfish can be attacked if any pair of entries
in the sboxes are the same. These sboxes are random as you would say.
Replace the sboxes with ones from CAST and you have a 'more' secure
block cipher.
> >>> Typically, a modern S-box has an even binary power number of
elements
> >> >> (e.g., 2**4 or 16, 2**8 or 256, etc.). There is one element of
> >each
> >> >> possible value and these are permuted or shuffled. Up to this
> >point,
> >> >> all we need to know is how to count and how to shuffle.
> >> >>
> >> >> Some designs use "small" (e.g., "4-bit") S-boxes, but such small
> >boxes
> >> >> are often weak, and so should be tested before being used.
There
> >are
> >> >> various tests including diffusion, Boolean function
nonlinearity,
> >> >> etc., with at least one new test found for every new attack on
S-
> >box
> >> >> structure. An alternative is to use "large" ("8-bit" or larger)
> >> >> S-boxes, but that is a cipher design decision.
> >> >
> >> >Yeah I agree with the less-non-linearness of small sboxes, but can
> >you
> >> >point me to an attack on Serpent that relies on the sboxes?
> >>
> >> That is a fundamentally wrong question: If we must actually break
a
> >> cipher to consider it weak, we will never have time to show just
how
> >> weak our many ciphers may be. It is unreasonable to simply assume
> >> that a cipher strong unless explicitly proven weak. Just because
you
> >> don't see a way to exploit the problem is no reason to allow the
> >> problem to exist to somehow be exploited.
> >>
> >> My approach is to try to eliminate every ghost of weakness I can
see.
> >> I suppose others have different approaches.
> >
> >Conversely why is it a problem if it cannot be exploited? Using
finite
> >sized keys is a problem of *all* symmetric ciphers, but is that cause
> >for alarm?
>
> The problem is that we cannot prove that the problem cannot be
> exploited. Just because *we* don't know how to do it does not mean
> that it cannot be done. So, in my opinion, yes, having a preventable
> weakness that we think is hidden and which we think cannot be used is
> still cause for alarm.
My point was that we don't know it's actually a weakness until it can
be exploited.
> The ideal would be to have several layers of different operations,
> each of which we think is secure, and which would require every layer
> to be somehow compromised before the cipher is broken. Having one
> layer with a known weakness would seem to be both ignoring the goal
> and tempting fate.
We only think the operations are secure because we say so, most of the
time.
> That said, it is of course trivially true that weak functions are used
> in ciphers. I suppose the serious issue occurs when we have some
> known weakness which, if somehow exploited, would accomplish one of
> the steps needed for a break.
Well typical "weak" steps are linear transforms to promote avalanche...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Yet another sci.crypt cipher
Date: Mon, 15 May 2000 02:42:12 GMT
In article <8fnl8e$p1m$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> I just finished my package for another block cipher. I don't have the
> warm fuzzy feeling about it, but I would still like to see what you
> guys can do to it. (no claims here).
>
> The cipher is geared towards small systems and only requires 16 bytes
> to hold the key, it's not terribly fast but it is very compact and
> simple to code even from memory (minus the sbox).
>
> You can get the paper from
> http://www.tomstdenis.com/snappy.txt
>
> (hopefully Adam will add this to the pile).
>
> Tom
I sincerely with all my being hate the keyschedule I put into that
cipher. I am kinda scrapping the bottom of the barallel for a good key
schedule. Basically I want some permutation of 0..15 that is algebraic
and takes three inputs (x, y, j) where (x, j) belong to 0..7 and (j)
belongs to 0..15.
Basically the cipher looks like
for y = 0 to rounds do
for x = 0 to 7 do
for j = 0 to 7
get a T
block[x] = block[x] ^ T
So as we step x/j it should touch as many as the key bytes as
possible...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Key generation for lja1
Date: Mon, 15 May 2000 03:23:53 GMT
Andru Luvisi wrote:
>
> Because the hash function for lja1 is basically an eight bit codebook
> run in cipher block chaining mode, and long periods are generally
> considered a good thing in a block cipher, I suspect keys which would
> have a cycle of length 256 would be stronger than keys with shorter
> cycles. In an extreme case, if every key[i] = i, then the compression
> function would not change the accumulator when hashing zero bytes.
>
[original code snipped]
> Andru
While I understand what you want to do, the code you gave is a bit
difficult (for me, at least) to understand. Perhaps this version
would better:
void lja1_makekey(
unsigned char *key,
int (*number_generator)(void *closure, int modulo),
void * ng_closure)
{
int pool[255], i, j, k;
for( i = 0; i < 255; --i )
pool[i] = i;
for( i = 0; i < 255; --i ) {
j = (*number_generator)(ng_closure, 255);
k = pool[i];
pool[i] = pool[j];
pool[j] = k;
}
k = 255;
for( i = 0; i < 255; ++i ) {
key[ k ] = pool[i];
k = pool[i];
}
key[ k ] = 255;
}
------------------------------
From: "Steve and Darla Wells" <[EMAIL PROTECTED]>
Subject: Re: About Hardware RNG
Date: Sun, 14 May 2000 20:20:59 -0700
"Guy Macon" <[EMAIL PROTECTED]> wrote in message
news:8fmt2k$[EMAIL PROTECTED]...
> In article <8fmhqq$kib$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom St
Denis) wrote:
> >
> >In article <kezT4.357$[EMAIL PROTECTED]>,
> > "Steve and Darla Wells" <[EMAIL PROTECTED]> wrote:
> >> Although such circuits generate entropy, they typically generate
> >detectable
> >> weaknesses through either interference coupling and/or bias with the
> >> environment. Be sure to post process the result well.
> >
> >The device I am building will feed the output to a data pin on a AVR
> >2313, which will hash it (using MD2). I currently have it set to hash
> >256 bytes downto 16 bytes before outputting.
> >
> >The device will be the size of a wallet and have a simple RS-232
> >interface. A tiny TTY host in the AVR will allow the users to
> >request 'x' amount of bytes, afterwhich the device will go to sleep
> >mode.
> >
> >I hope to build a prototype this week (I want to make an AVR eval
> >board, and just stick the RNG device on it).
>
> Your use of a hash implies that you expect the output to a data pin on
> the AVR 2313 to be less than perfectly random. Would you care to list
> what kind of biases you expect and how severe you expect them to be?
>
Perfect entropy is not something to expect from a physical system,
especially analog electrical circuits which are always much more complicated
that our simplifying abstractions might suggest. Some bottom end estimate
of average and worst case entropy and various bit-bit correlation values (1
bit away, 2 bits away, 3 bits away, etc) is always required before an
entropy refinement strategy can be take on. A great caution is required in
using XOR reduction is bit-bit correlations! (i.e. 1 xor 1 = 0 xor 0 = 0,
i.e. no entropy!)
Finally, most entropy refinement strategies I've seen tend to go way
overboard. For example, if you had 200 real bits of entropy in a 256b seed,
it would take on average 2**199 search attempts. Using 0.693kT/b minimum
energy, a quick calculation shows this to be about 1 million years of energy
from the sun. Probably good enough for a PRNG seed.
---Steve
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: How does one test an encryption algorithm?
Date: 15 May 2000 03:38:55 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote in <[EMAIL PROTECTED]>:
>
>On Sun, 14 May 2000 15:39:25 GMT, in <[EMAIL PROTECTED]>,
>in sci.crypt [EMAIL PROTECTED] (Bruce Schneier) wrote:
>
>>On Thu, 11 May 2000 00:37:29 GMT, [EMAIL PROTECTED] wrote:
>>
>>>I have an dynamic encryption algorithm and it needs to be tested. Is
>>>there a newgroup or a group of freelance hackers :-) or some place
>>>where I could test by hiring services.
>>>
>>>All I want to know is that if my algorithm is tough to crack.
>>>
>>>How does one estimate the confidence factor of an encryption algorithm?
>>>Are there any metrics defined?
>>
>>See:
>>
>> http://www.counterpane.com/crypto-gram-9810.html#cipherdesign
>
>...where we see the same old pablum about getting experts to "analyze"
>the cipher, and then -- somehow -- leaping to a belief in its
>strength.
>
>Absent a mathematical proof of strength in practice, there is no
>scientific basis for a belief in cipher strength. Indeed, the entire
>history of cryptography has been about the unexpected weakness of
>commonly-accepted ciphers.
>
>---
One danger of even trying to get the pseudo experts including
Mr BS and David Wagner is that if you don't program in there
narrow way of thinking they will say your cipher is weak no matter
what. As they did with my cipher which has survived several large
cash contests of the type they are afraid to run. Also Mr Wagner
claimed that my scott16u.zip was destroyed by his great Slide
Attack. Of course when people who read here actaully looked at it
he was full of shit and admitted that he could not follow the code.
You can forget get about them following a new encryption when they
can't even follow complilable source code. About the only time
you can expect an honest anwser from them is if it is one of the
more common well known ciphers that is weak. Then you will get the
phony lecture that you should leave cipher development to them and
that your no good. They are really great at patting them sevles on
the back. I think about the only good way to test a cipher is to have
a cash contest where you supply the souce code.
david scott
http://members.xoom.com/ecil/index.htm
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Snappy Block Cipher (key schedule)
Date: Mon, 15 May 2000 03:49:24 GMT
I posted an update to my Snappy Block Cipher to use what I think is an
improved key schedule. You can get the mini-paper from
http://www.tomstdenis.com/snappy.txt
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
