Cryptography-Digest Digest #276, Volume #12 Mon, 24 Jul 00 02:13:00 EDT
Contents:
Re: RC4-- repetition length? (Guy Macon)
Re: 8 bit block ciphers (Ray Dillinger)
Re: Practical application of Ciphersaber (Was: RC4-- repetition length?) ("Scott
Fluhrer")
Re: 8 bit block ciphers ("Douglas A. Gwyn")
Re: RC4-- repetition length? ("Joseph Ashwood")
Re: Hash function? ("Scott Fluhrer")
Re: Practical application of Ciphersaber (Was: RC4-- repetition length?) ("Joseph
Ashwood")
Re: RC4-- repetition length? (Jim Gillogly)
Re: Proving continued possession of a file (Bryan Olson)
Re: RC4-- repetition length? ("Joseph Ashwood")
Re: 8 bit block ciphers (Mack)
Re: RC4-- repetition length? (Jim Gillogly)
Re: 8 bit block ciphers (Mack)
Re: 8 bit block ciphers (Mack)
Re: 8 bit block ciphers (Mack)
Re: 8 bit block ciphers (Mack)
Re: 8 bit block ciphers (Mack)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: RC4-- repetition length?
Date: 23 Jul 2000 23:34:52 EDT
Bill Unruh wrote:
>
>
>In <8ldejt$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Guy Macon)
writes:
>
>
>>There are a lot of folks like me who are interested in ciphersaber
>>( http://www.ciphersaber.gurus.com ) but are a bity shy of the horsepower
>>to tell the good arguments in this thread from the bad. Could one of
>>the experts post a practical summary when this discussion is complete?
>
>This thread has nothing to do with ciphersabre.
You may have noticed that:
[1] I mearly mentioned ciphersaber as background to why I am interested
in a summary, followed by a request for a summary about RC4.
[2] I started another thread to discuss ciphersaber without sidetracking
what seems to be a useful thread about RC$ repitition length.
I might add that what a thread has to do with is whatever those posting
to it choose, and that I have as much or as little say as you do on that.
>They got involved by making confusing statements about their
>implimenation of RC4 or ARC4.
May I suggest that you repeat this in the ciphersaber thread? You
are violating your own dictate about what this thread is about.
>The main topic of this thread was how long the repetition cycles tend to
>be in ARC4, and has digressed to how much output you need to tell the
>difference (just by looking at the output statistics) between the output
>of ARC4 and a truely random sequence.
Thanks for the overview, but I have been reading the posts too, and
thus do not require yoiur assistance.
>Read the snake-oil FAQ published here regularly.
I have. I have also read many books and web pages on the subject.
Others here will tell you that I am progressing nicely, but am still
quite the clueless newbie.
>Look at what they offer. Ask if their key generation routines are
>replaceable
They are.
> and open source.
They are.
> Ask what the exact specification of the output is.
Don't have to. It's publised.
> Ask for an exact specification of all algorithms used.
They not only give you the algorithms, they encourage you to
do your own implementation.
I wouls like evidence for your claim of "confusing statements",
but I would prefer that you explain in the ciphersaber thread.
------------------------------
From: Ray Dillinger <[EMAIL PROTECTED]>
Subject: Re: 8 bit block ciphers
Date: Mon, 24 Jul 2000 03:46:23 GMT
Mack wrote:
>
> Does anyone have any information on 8 bit block
> ciphers? I don't mean simply shuffling an array.
> And I am aware that it is simple to do a dictionary
> attack. I am looking for methods that can be used
> instead of array shuffling.
Hmmm. "An 8 bit block cipher" is just a substitution
cipher on a single byte, and easily cracked by a
frequency count using pencil and paper in an hour
or less.
You could use a linear congruential generator to
generate a pseudo-random sequence of 8-bit
numbers and Xor your plaintext with the next one in
order to encode it -- In a linear congruential
generator, you store three numbers A B and C, and
each new "random" number is A times the last one,
plus B, with the sum taken modulo C. If C is 256,
which is easy -- you just take the low-order byte
of the sum -- then the numbers A and B, together
with the last pseudorandom generated, describe a
permutation of the 8-bit numbers starting right after
the last pseudorandom generated. In order to get
a period of 256, you will need to pick a prime N at
random and use 512N + 1 for A, and use a Prime
number for B.
This would make a Streaming cipher. It would have
better security, but still not very good; in particular,
the modulus 256 will force short cycles in the low-order
bits because it's a power of 2. A cryptanalyst would
measure the coincidence level on individual bits, and
observe the rightmost bits having coincidences distances
measured in powers of two, with higher powers the further
left he went. If it were used on a natural language,
would be able to work out the entire key (the 256 byte
cycle) from a message of only 256 bytes! However, this
would require *some* cryptographic knowledge to figure,
and doing it by hand would take more than one sitting.
It's probably about 5 times as secure as an 8-bit block
cipher.
In the kind of limited environment you describe, I would
recommend a 16-bit streaming cipher consisting of Xor
with a pseudo-random stream generated by a linear
congruential generator, under a modulus of (2^16)-1
and using prime numbers for A and B.
That will get you a block of almost 64K before the coincidence
becomes apparent -- but it's still not something that
ought to be called a "secure" method. While it's a thousand
times better than an 8-bit block cipher, Once a message goes
over 64K you hit a big coincidence spike at your modulus and
a cryptanalyst can quickly break the system if he gets a 128K
message. On shorter messages, if he can catch you encrypting
a known plaintext he can recover your pseudo-random sequence
and then the cryptographic technique of spectral analysis will
cheerfully break a 16-bit linear congruential generator in
about ten minutes of computer time.
With only 32 bytes for data, it's very hard to come up with a
good encryption/decryption algorithm.
Good luck.
Ray
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Practical application of Ciphersaber (Was: RC4-- repetition length?)
Date: Sun, 23 Jul 2000 20:41:31 -0700
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
[Re: Guy Malcom's method of marking messages within a long random stream by
using a fixed 64 bit marker symbol]
> Your special code may be a problem. I'd recommend using each only once.
Question: why? What potential weaknesses are you worried about?
--
poncho
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: 8 bit block ciphers
Date: Mon, 24 Jul 2000 00:09:49 -0400
Ray Dillinger wrote:
> Hmmm. "An 8 bit block cipher" is just a substitution
> cipher on a single byte, and easily cracked by a
> frequency count using pencil and paper in an hour
> or less.
If it is used in ECB mode. Usually, block ciphers are
used in a feedback mode. Of course 8 bits isn't much,
but if the key is substantially longer and is used to
full advantage, it might not be an unmitigated disaster.
> With only 32 bytes for data, it's very hard to come up
> with a good encryption/decryption algorithm.
Amen to that.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: RC4-- repetition length?
Date: Sun, 23 Jul 2000 21:46:52 -0700
Actually, it is difficult (if not impossible) to prove but
it is quite intuitive that once you can distinguish
something like RC4 from random it can be broken, whether or
not the algorithm is known to us is a matter far removed
from it's existance. My statements about how much data to
trust to a given (or closely related) key descended from
that assumption. If you'd care to refute it, perhaps you'd
care to place what you believe to be a more reasonable
assumption in it's place.
Joe
"Bill Unruh" <[EMAIL PROTECTED]> wrote in message
news:8lg283$gdb$[EMAIL PROTECTED]...
> In <ukkqsZF9$GA.279@cpmsnbbsa07> "Joseph Ashwood"
<[EMAIL PROTECTED]> writes:
>
> >Well to make a potentially long summary quite short:
> >1) RC4 is good for a few megabytes of data, but starts
> >getting fairly bad around a gigabyte, very bad around 2
> >gigabytes, probably breakable around 16 gigabytes.
>
> ???? This comes from where? The evidence is that the
output is
> distinguishable from pure random at about 2GB (just) No
way of using
> that to break the cypher has been presented. We know all
private key
> cyphers are not random ( there is a very simply short
algorithm which
> generates them) Using that fact is the difficulty. So even
if we know
> rc4 is not exactly random , using that fact is the
difficulty.
>
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Hash function?
Date: Sun, 23 Jul 2000 21:49:03 -0700
Boris Kazak <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> To the judgement of sci.crypt posters and readers...
> Here is the proposal for a very simple hash function -
> scalable, fast, byte-oriented.
>
> Everything starts with an array of bytes. The size of array
> is equal to the size of future hash, and is named _buffer_.
>
> Array is initialized either with user's key, or, barring
> that, with consecutive bytes 1,2,3...
>
> There is a _magic_ 16-bit constant called SEED, equal to
> 0x6A09 hex, which happens to be first 4 hex digits SQRT(2),
> less initial 1.
>
> A byte is read from the hashed message (file), XORed into
> the 0-th element of _buffer_. Thereafter the 16-bit number,
> built from the 0-th and 1-st elements of _buffer_, is
> multiplied by SEED, yielding a 32-bit product.
>
> The 4 bytes of the product are XORed into the first 4
> elements of _buffer_.
>
> Thereafter _buffer_ is rotated
> left 1 byte. (Big-endian architecture assumed).
>
> After the EOF there are 4 more bytes to be hashed - the
> length of the file as 32-bit number.
>
> Finally, the buffer undergoes one more full cycle of
> multiplications-rotates, in order for the full avalanche
> to happen. The final hash is in the _buffer_.
>
> Hash function Pseudocode:
>
> /********************/
> // variables
> unsigned int32 product;
> unsigned int16 SEED = 0x6A09; file://first 4 hex digits SQRT(2), less
initial
> 1
> unsigned int16 multiplicand,i;
> unsigned byte BUFFER[HASHSIZE]; // whatever the HASHSIZE is #defined
> unsigned byte temp, prod[4];
>
>
> // BUFFER initialize
> for (0 to HASHSIZE-1)
> BUFFER(i) = i+1; // writing in there consecutive numbers.
> // Alternatively, BUFFER can be initialized with user's key
>
> // Hashing
>
> file://Before EOF
> While (temp = (READBYTE(InputFile)) != EndOfFile)
> BUFFER[0] = BUFFER[0]^temp; // XORing the new byte
> multiplicand = 256*BUFFER[0]+BUFFER[1];
> product = multiplicand*SEED;
> split _product_ into 4 bytes from prod[0] to prod[3];
> XOR prod[] bytes into BUFFER according to indices;
> Rotate BUFFER to the left 1 position;
> file://This implies BUFFER[HASHSIZE-1]=BUFFER[0],
> file://BUFFER[0]=BUFFER[1], BUFFER[1]=BUFFER[2], etc.
> Read new byte; Repeat;
>
> file://After EOF
> file://Optionally, if file length was determined in
> file://process of reading, the above procedure can be
> file://repeated 4 more times, hashing in the consecutive
> file://bytes of file length (32-bit number assumed)
>
> file://Thereafter, the final squashing
> For (0 to HASHSIZE-1)
> multiplicand = 256*BUFFER[0]+BUFFER[1];
> product = multiplicand*SEED;
> split product into 4 bytes from prod[0] to prod[3];
> XOR product bytes into BUFFER according to indices;
> Rotate BUFFER to the left 1 position;
> file://This is the same procedure as above, without
> file://reading new bytes, repeated for 1 full cycle
> file://in order to provide full avalanche.
>
> file://Final hash is contained in the BUFFER.
> *******************************
> N.B. In a practical program it is obvious, that instead of
> rotating in memory all the content of BUFFER, one can achieve
> same result by indexing the process cyclically (mod HASHSIZE).
>
> Any feedback will be appreciated.
According to my calculations, with 128 bit Kazakhash [1] using the default
array initialization (no user-provided key), and including the optional
length hashing, the following two files:
00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00
01 6a 0a 36 f9 a0 db c0 01 71 f9 e5 f8 f8 4d 0d
have the common hash value:
9c 60 63 b9 53 4b 4f 16 ed ac 98 41 90 f4 49 4c
I found these two files by looking for input streams whose input
differential (after the first byte, whose input differential I didn't bother
worrying about) is restricted to buffer[0], buffer[1], buffer[2] -- that is,
I choose the input streams so that buffer[0] immediately before the rotate
had a zero differential.
Further comments:
- The length hashing is optional??? That really doesn't make sense; it
should be either required or forbidden.
- And, if you are going to hash in a length, putting in a limit of
4Gigabytes is somewhat restrictive for applications with huge files -- a 64
bit length field is less restrictive.
- The "final squashing" is both unneeded and dangerous. It's unneeded
because the requirement on a hash function is to make forgery (either
finding preimages, or finding colliding messages) difficult, and this step
does nothing to make it any more difficult [2]. It's dangerous because the
operation is noninvertable, and so may generate additional collisions.
[1] I had to call it something...
[2] Ok, it does appear to make finding a file that files to a given value
more difficult, but that isn't a very common attack.
--
poncho
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Practical application of Ciphersaber (Was: RC4-- repetition length?)
Date: Sun, 23 Jul 2000 22:10:25 -0700
> I also hope you are not going to design a real-life system
based on what a
> couple of guys on sci.crypt said, but you will check it
out, right?
I second that. With computer security, there are no
absolutes, everything that has been said should be thought
of as certainly no more than a guideline, to truly determine
if a protocol/algorithm fits your use, requires an in depth
analysis of the system, and the creation of an accurate
threat model.
> > I bury my passphrase in an internal layer of a masked
IC; a
almost always a bad idea (dependant on the threat model), it
is almost always necesarry to have some exclusive shared
secret.
> > >1) RC4 is good for a few megabytes of data, but starts
> > >getting fairly bad around a gigabyte, very bad around 2
> > >gigabytes, probably breakable around 16 gigabytes.
> >
> > I have one system with a hardware RNG and a dedicated
> > communication channel and processor. I set it up so
> > that the sender is always encrypting random data (except
> > in the case where the random data contains a special 64
> > byte code - that get's discarded) and the reciever is
> > always decrypting and discarding the random data. Every
> > so often, the sender sends a fixed length message which
> > starts with the special 64 byte code. At 9600 bps and
> > 10 bits to form a byte, those limits above look like a
> > problem. Are they a problem in this application?
It may be a problem, it all depends on the ability of an
attacker to determine the timing of the real data, and the
determinism of the random data (is it trivially
distinguishable from random?). What you may want to do, is
transfer data in triples of (command, distance, length),
where the commands would be restricted to basically a bit
designating real/offset&ignore, distance is the number of
discarded RC4 operations befire the information(which will
not even be sent), and length of the actual command or the
data to be ignored. If the distance is chosen even semi
randomly you will leave holes in an attacker's knowledge
(unless they can determine the triples from the beginning).
It may or may not prove a useful change, but will almost
certainly require more silicon to incorporate. But I would
also agree with Scott's statement, 10-bit ARC4 will likely
be preferable to 8-bit, but again will require quite a bit
more silicon.
> > >2) The average-case repetition length of RC4 is
extremely
> > >long, the worst-case repetition length is still quite
large,
> > >the best-case repetition length is nearly astronomical
> >
> > The 1-16 GB range mentioned above, is that best,
average,
> > or worst case? Is there a way that I can avoid it by
avoiding
> > certain week passphrases?
Actually when I said extremely long, I meant that I am
unsure of what the value is, only that it is in excess of
reasonably reachable means. Your 9600 baud connection should
be able to run for decades without getting near the
repetition length. I also am unaware of the requirements for
weak passphrases, except for the well known firest byte
problem.
> > >3) If you're going to use RC4 make sure you throw away
the
> > >first several outputs
> >
> > Is this a proplem with ciphersaber as well? I often do
a
> > preprocessing stage where I add a random number of
random
> > bytes to the beginning and end of my plaintext before I
> > encrypt it. For humans, that's enough, as they can
plainly
> > see wher the garbaf=ge stops and the message starts.
For
> > applications where a microprocessor needs the plaintext,
> > I use a special 64 byte start of message code that is
never
> > found in the random data (I strip it out if it shows
up).
Easiest solution is to throw away a known number of the
initial values, I generally choose 512 because it is very
far beyond the known weakness, and it's a nice round number.
> > >4) Designing your own stream cipher is probably a
fool's
> > >pursuit
> >
> > Alas, I have to do my own implementation, and on
hardware
> > with a really strange instruction set. I am using
someone
> > elses design (ciphersaber-1).
Implementation is not a worry, as long as you implement it
correctly, I meant actually designing your own (see the
other message on this group about constructing one from
s-box data in blowfish that was shown immediately to be
weak).
Joe
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: RC4-- repetition length?
Date: Mon, 24 Jul 2000 05:16:52 +0000
Joseph Ashwood wrote:
>
> Actually, it is difficult (if not impossible) to prove but
> it is quite intuitive that once you can distinguish
> something like RC4 from random it can be broken, whether or
> not the algorithm is known to us is a matter far removed
> from it's existance. My statements about how much data to
> trust to a given (or closely related) key descended from
> that assumption. If you'd care to refute it, perhaps you'd
> care to place what you believe to be a more reasonable
> assumption in it's place.
It's not intuitive to me. It's been said that it's
possible to tell Cuban number-station transmissions from
random because the typists generating one-time-pads did
it out of their heads rather than according to some random
hardware. However, it wasn't non-random enough to break.
I don't know how true the story is, but I believe the
principle: a few years ago an ACA member produced some
cryptograms encrypted with pads with varying degrees of
randomness, starting from almost totally non-random. It
wasn't too long before I and better cryppies than me were
stumped.
I would say that the ability to distinguish a stream from
random can be used to give you good confidence in some
kinds of hypotheses that aren't available with a one-time pad
(e.g. determining whether an encrypted message represents a
particular very long known plaintext), but it's quite possible
that no amount of data will allow a practical break in
reasonable time if the non-randomness is small enough.
--
Jim Gillogly
Trewesday, 1 Wedmath S.R. 2000, 05:09
12.19.7.7.5, 6 Chicchan 8 Xul, First Lord of Night
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Proving continued possession of a file
Date: Mon, 24 Jul 2000 05:09:24 GMT
Mark Wooding wrote:
> A while ago, I was asked to come up with some mechanism
> whereby a server could ascertain whether a client,
> which had previously transferred a particular file to
> the server, still had a copy of that file itself.
I'd guess that to make the problem and suggested
solution interesting, you actually had another
requirement: The space needed on the server must be
constant in the size of the file and the number of
times the client will prove possession.
Then I think I agree, let's not jump to conclusions
but the protocol does seem kind of cool.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: RC4-- repetition length?
Date: Sun, 23 Jul 2000 22:28:50 -0700
But you forget, with a stream cipher of the nature of RC4,
there is no entropy being added after the initial keying.
That means that you get diminishing amounts of randomness in
the pad as it gets longer. It's easy to state that with a
pad with say 7.9 bits of randomness per byte, it's basically
unbreakable, but at any length RC4 can have no more than
2048 bits of total entropy, at 2048 bytes, there is 1 bit
per byte, at 2 gigabytes there is 1/1024 of one bit of
entropy per byte, that's small enough that it should be
breakable. Either argument should lead to the fact that at 2
gigabytes RC4 can be broken, I just don't know how to do it.
Joe
"Jim Gillogly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Joseph Ashwood wrote:
> >
> > Actually, it is difficult (if not impossible) to prove
but
> > it is quite intuitive that once you can distinguish
> > something like RC4 from random it can be broken, whether
or
> > not the algorithm is known to us is a matter far removed
> > from it's existance. My statements about how much data
to
> > trust to a given (or closely related) key descended from
> > that assumption. If you'd care to refute it, perhaps
you'd
> > care to place what you believe to be a more reasonable
> > assumption in it's place.
>
> It's not intuitive to me. It's been said that it's
> possible to tell Cuban number-station transmissions from
> random because the typists generating one-time-pads did
> it out of their heads rather than according to some random
> hardware. However, it wasn't non-random enough to break.
> I don't know how true the story is, but I believe the
> principle: a few years ago an ACA member produced some
> cryptograms encrypted with pads with varying degrees of
> randomness, starting from almost totally non-random. It
> wasn't too long before I and better cryppies than me were
> stumped.
>
> I would say that the ability to distinguish a stream from
> random can be used to give you good confidence in some
> kinds of hypotheses that aren't available with a one-time
pad
> (e.g. determining whether an encrypted message represents
a
> particular very long known plaintext), but it's quite
possible
> that no amount of data will allow a practical break in
> reasonable time if the non-randomness is small enough.
>
> --
> Jim Gillogly
> Trewesday, 1 Wedmath S.R. 2000, 05:09
> 12.19.7.7.5, 6 Chicchan 8 Xul, First Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: 8 bit block ciphers
Date: 24 Jul 2000 05:59:04 GMT
>
>
>Mack wrote:
>>
>> Does anyone have any information on 8 bit block
>> ciphers? I don't mean simply shuffling an array.
>> And I am aware that it is simple to do a dictionary
>> attack. I am looking for methods that can be used
>> instead of array shuffling.
>
>Hmmm. "An 8 bit block cipher" is just a substitution
>cipher on a single byte, and easily cracked by a
>frequency count using pencil and paper in an hour
>or less.
>
[snip]
I am aware of this. I am simply looking for a substitute
for array shuffling.
>This would make a Streaming cipher. It would have
[snip]
I really need something that works as an 8 bit
encryption. But thanks anyway.
>
>With only 32 bytes for data, it's very hard to come up with a
>good encryption/decryption algorithm.
My problem exactly.
>
> Good luck.
>
> Ray
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: RC4-- repetition length?
Date: Mon, 24 Jul 2000 05:59:23 +0000
Joseph Ashwood wrote:
>
> But you forget, with a stream cipher of the nature of RC4,
> there is no entropy being added after the initial keying.
> That means that you get diminishing amounts of randomness in
> the pad as it gets longer. It's easy to state that with a
> pad with say 7.9 bits of randomness per byte, it's basically
> unbreakable, but at any length RC4 can have no more than
> 2048 bits of total entropy, at 2048 bytes, there is 1 bit
> per byte, at 2 gigabytes there is 1/1024 of one bit of
> entropy per byte, that's small enough that it should be
> breakable. Either argument should lead to the fact that at 2
> gigabytes RC4 can be broken, I just don't know how to do it.
Are you sure it's "losing randomness", whatever that means?
The sequence may be distinguishable from random, but I'd still
like to see your proof that it's becoming progressively less
random. I don't find the hand-waving persuasive. I grant
that with RC4 (as with 3DES or RC6 or Twofish) there's enough
information after a few dozen bytes of known plaintext to
unambiguously break them -- but for none of these do people
know how to do it effectively. With just ciphertext it can
only be harder. If you can't break RC4 with two gigabytes
of chosen plaintext, you won't be able to do it with ciphertext
only either.
--
Jim Gillogly
Trewesday, 1 Wedmath S.R. 2000, 05:51
12.19.7.7.5, 6 Chicchan 8 Xul, First Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: 8 bit block ciphers
Date: 24 Jul 2000 06:00:27 GMT
>Ray Dillinger wrote:
>> Hmmm. "An 8 bit block cipher" is just a substitution
>> cipher on a single byte, and easily cracked by a
>> frequency count using pencil and paper in an hour
>> or less.
>
>If it is used in ECB mode. Usually, block ciphers are
>used in a feedback mode. Of course 8 bits isn't much,
>but if the key is substantially longer and is used to
>full advantage, it might not be an unmitigated disaster.
>
The 8-bit block cipher is going to be used as an S-box.
>> With only 32 bytes for data, it's very hard to come up
>> with a good encryption/decryption algorithm.
>
>Amen to that.
>
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: 8 bit block ciphers
Date: 24 Jul 2000 06:02:31 GMT
>--------------------
>Linearity or non-linearity is up to your design.
>You can, for example, take the two leftmost bytes from
>the register, multiply them into a 16-bit product,
>XOR this product back into the original bytes, then
>rotate 1 byte to the left. I have a key scheduler design
>that works like this.
>
>BTW, if you want the bytes in the stream to be non-
>duplicating before you scan the whole 256-element table,
>this is a serious weakness in the cipher design.
>Think yourself - in any 256-byte block there will be
>ALL 256 bytes exactly 1 time each... quite an invitation
>to analysis.
>
>Best wishes BNK
>
Still not quite what I am looking for. The
8-bit block cipher is to be used as an S-box.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: 8 bit block ciphers
Date: 24 Jul 2000 06:04:52 GMT
>Mack <[EMAIL PROTECTED]> wrote:
>> I am looking for something that could be implemented without
>> having the entire table in memory. For example only using
>> 32 bytes. This prevents shuffling from being useful.
>>
>> I am looking for something that will take a 32 byte key
>> and convert it to an 8 bit permutation. The permutation
>> should have a good non-linearity, good avalanche and
>> a good differential table. It should also be invertable.
>> Methods that use fewer key bytes are acceptable.
>> Basically it has to be a good 8-bit encryption method.
>
>Why not use a Feistel network, with a 4-bit F function?
>Encrypt for, say, 100 rounds or so (it can't hurt). The
>result requires a 16-nibble table for the F function, plus
>space to store the key.
>
>
That is basically what I am looking for. But does anyone
have a good one?
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: 8 bit block ciphers
Date: 24 Jul 2000 06:06:26 GMT
>Mack <[EMAIL PROTECTED]> wrote:
>> That is what I am looking for mathematical or encryption
>> methods of producing a 256 byte permutations.
>> No shuffling please.
>
>Why not use shuffling? It's the obvious answer.
>
>If you have some extra constraints, it seems hard to answer the
>question without knowing what they may be.
>
>
32 bytes of memory. It pretty much eliminates having the
whole table in memory. The 8-bit block cipher is going to
be used as an S-box.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: 8 bit block ciphers
Date: 24 Jul 2000 06:08:01 GMT
>In <[EMAIL PROTECTED]> [EMAIL PROTECTED]
>(Mack) writes:
>]That is what I am looking for mathematical or encryption
>]methods of producing a 256 byte permutations.
>]No shuffling please.
>
>Any permutation can be obtained by "shuffling", so it is unclear what
>you want.
>
>
I am looking for an 8-bit encryption method that can be used as
an S-box. Memory is very limited so shuffling is not feasible.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
** 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
******************************
