Cryptography-Digest Digest #989, Volume #12 Mon, 23 Oct 00 18:13:00 EDT
Contents:
Re: Huffman stream cipher. (Tom St Denis)
Re: toy cipher question (Tom St Denis)
Re: toy cipher question (Tom St Denis)
Re: Hypercube/FFT encryption (James Felling)
Re: Problem with the CS-Cipher (Tom St Denis)
Re: My comments on AES (Tony L. Svanstrom)
Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
Re: Steganography books (wtshaw)
Re: How about the ERIKO-CHAN cipher? ("Mark Dowdey")
Re: ---- As I study Rinjdael... (SCOTT19U.ZIP_GUY)
Re: ---- As I study Rinjdael... (Mok-Kong Shen)
Re: Rijndael implementations (Tim Tyler)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Huffman stream cipher.
Date: Mon, 23 Oct 2000 19:55:43 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Maybe the 19x19 bit S tables are bigger than what most people are
> use to.
Yes I would say a 19x19 table is not only crazily large but terribly
inefficient. Sure I could make a secure block cipher (Bruce Schneier
like rant comming up...) out of 128 rounds of a simply stupid round
function.... however.... good crypto is about doing good things with
less and faster. Using a 19x19 table is hardly a sign of "doing things
with less or faster"
> I guess you don't realize that warning is not the same as error.
> I use to get warning from compliers all the time. It just means becare
> or use at you on risk which really goes with all software. But a
> warning is not an ERROR. Portability to other systems is not a high
> priority with me. Getting code to work on the machine I use is. Hell
> when I worked for the US gorvernment people who thought they were
using
> portable fortran also got a shock when there code did not work the
same
> on next verison of fortran on the same machine. I don't like to change
> compiler versiions even in C. I would not be surprised in the next
> release of GNU C for DJGPP it may not work. But it does for the
current
> version. One could chase portability issues for ever but you never
> really know the code is portable until you test it on the machine.
> My fun is getting it to work on the machine I have access to with the
> tools I have. I figure if some one wants to use it in another machine
> or compiler of there choice they have to get it to work. However
> since I am retired I would be willing to work for CASH to get it to
> work on another machine and or version of a compiler.
Not only is your thread (with Richard) off-topic (move to comp.lang.c
please) but your statement is plainly wrong. Good C code should
compile without fuss on any platform with sufficient resources. For
example the source code to my block ciphers (well some of them)
compiles without fuss for an Intel 8051 as it would for a pentium
(while the pentium is much much faster... that's another story).
Also I use "void main(void)" quite a bit, I know it's wrong, and not at
all portable. I really should be carefull.. You're right that in all
honesty it doesn't matter, but if you're trying to impress others or
write code that is semi-portable you're better off cleaning up the code.
> C was not designed for portability. It was designed to make
programing
> easyer on NEW machines without having to rely soley on machine
language
> it is a tool to help nothing more.
I would say you're full of it now. C was purely designed to be
portable. That is why a "standard library" was developped shortly
after the syntax was born. In fact the library was standardized much
before the syntax "such as quarky things like "auto"". I think you
should read "K&R C" the official C bible (it's only 40 bucks) or
perhaps the second edition for some references.
Just because you're code is not portable doesn't mean C wasn't designed
to be portable...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: toy cipher question
Date: Mon, 23 Oct 2000 20:01:07 GMT
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> I have a few functions that I want to use as components of a cipher,
and
> I want to know how secure they are on their own (ie, if used as
complete
> ciphers)... Or at least, how strong are they relative to each other,
> using various values for the "rounds" variable. Assume that k
contains
> (2*rounds) truly random bytes, and sbox8 and sbox16 have "good"
> properties.
>
> void toya( unsigned char *ct, unsigned char *pt, unsigned char *k )
> {
> char a = pt[0], b = pt[1], i;
> for( i = 0; i < rounds; ++i ) {
> a = sbox8[a + *k++], b = sbox8[b + *k++];
> a += (b += a); }
> ct[0] = a; ct[1] = b;
> }
>
> void toyb( unsigned char *ct, unsigned char *pt, unsigned char *k )
> {
> char a = pt[0], b = pt[1], i;
> for( i = 0; i < rounds; ++i ) {
> a += sbox8[b + *k++];
> b += sbox8[a + *k++]; }
> ct[0] = a; ct[1] = b;
> }
>
> void toyc( unsigned char *ct, unsigned char *pt, unsigned char *k )
> {
> short a = (pt[0]<<8) | pt[1], i;
> for( i = 0; i < rounds; ++i, k += 2 )
> a = sbox16[ a + (k[0]<<8) + k[1] ];
> ct[0] = a >> 8; ct[1] = a & 0xFF;
> }
>
> Yes, I know that toyb is just a fiestel, but think of this as an
> experiment with toyb as a control. The toya function, with rounds=1,
is
> the mixing function used in Tom Denis's TC2. The toyc function uses
an
> sbox that is probably overlarge for practical use.
Wow, I'm famous.
Well toya is a simple SP-Network like in TC2 as you mentioned.
If "sbox" has ideal properties I would argue that it acts like a
decorrelation module on vectors of two components (i.e you cannot
predict the output difference with a probability higher then 1/p).
Toyb is a feistel network, I would say a similar idea applies. Given
enough rounds it would act like a decorrelation module.
Toyc is a recursive type substitution as used in Twofish to make the
8x8 sboxes. Note that storing a 16x16 sbox is a bad idea (hey why not
use toyb or toya?). Similarly given sufficient rounds it is immune to
simple attacks.
All three look neat, the problem is how many rounds are required? In
TC8 (note: the source on the page is nothing like the one I want to
present to CHES) I use a three-round Feistel which is not immune to
differential attacks primarily to save resources and time.
For example, I could take toyb with the sbox from TC5, with five rounds
(and five unique key bytes) the function is immune to differential and
linear cryptanalysis but not impossible differential cryptanalysis.
With eight rounds the function is immune to all three attacks. Of
course at five rounds the function is slow...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: toy cipher question
Date: Mon, 23 Oct 2000 20:04:40 GMT
In article <[EMAIL PROTECTED]>,
"Kenneth Lantrip" <[EMAIL PROTECTED]> wrote:
> I'm not very proficient with C yet, as I'm just dabbling a bit in it
now.
> But from what I've gathered from studying a few of the famous
algorythms
> used, that any good algorythm must have a trap door function.
>
> If I have the cyphertext and the plaintext, is there any way to
recover the
> key, other than brute force? Or even give any clues to the key?
>
> If I have this function C = (P * K) mod 256... K cannot be
determined from
> knowing C and P. However if I have C = (P xor K), then K can be
determined
> from K = (C xor P).
That is not true. In C = PK (lets say in the ring Z), I can just do K
= PK/P. Note that in Z256 multiplication is not an invertable function
(unless K is odd).
Even with the famous C = (P * K) + K1 (see decorrelation theory) I can
extract K and K1 with only two known pairs.
> I didn't see any trap door functions used in your code. However, I
may be
> overlooking something as I'm not yet proficient with the C language.
>
> Others here may offer way more insight as to the rights and wrongs of
the
> above logic.
>
> Disclaimer: I am just a beginner when it comes to state of the art
> encryption algorythms. I only know that I should not try to invent
my own
> cypher yet.
Well you made the first step. Realize your boundaries. But by all
means experiment and post your ideas here. It's good to see people
learning. And it's good for us post-beginners-pre-advancers to help
out and learn as we help.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Hypercube/FFT encryption
Date: Mon, 23 Oct 2000 15:16:54 -0500
>
> PS to Ritter, in one of your docs, you say that with 1 plaintext /
> ciphertext pair, you can probably uniquely identify a DES key... I
> believe the actual number required is 3 pt/ct pairs.
>
<snip>
What you say is true in one sense, and what he says is true in annother.
3pt/ct is the MAXIMUM ammount required. However, typically 1pt/ct pair will be
enough to do so, 3 merely confirms it beyond the shaddow of a doubt.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Problem with the CS-Cipher
Date: Mon, 23 Oct 2000 20:06:42 GMT
In article <[EMAIL PROTECTED]>,
Serge Vaudenay <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > I implemented the M-Function as described in CS-Cipher and I found
that
> > with a prob. of 65026/65536 that any two inputs (that differ by a
fixed
> > amount) will not be a multipermutation.
> >
> > Essentially I took a 16-bit input 'x' and a difference 'y' and
got 'z =
> > M(x) xor M(x xor y)' and counted the number of times either the low
or
> > high byte of 'z' is zero.
> >
> > Well actually I used a slightly different 'sbox' but I think the
idea
> > holds true.
> >
> > Am I mistaken or is their structure not a multipermutation?
> >
> > Tom
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> The multipermutation property says that you should never get a low of
> high zero
> byte for z whenever the low or high byte of y is zero: not for any y.
Basically I mistook the idea. My problem was that the input difference
had two bytes that differed.
Correction: The M-Function in CS-Cipher is really a (2,2)
multipermutation. Tom just needs more cafeine... hehehe
Sorry for the mistake Serge, I really do like your work (although some
of it's a blur to me...)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: My comments on AES
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Mon, 23 Oct 2000 20:24:20 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> James Felling wrote:
> >
> > An accademic attack is ANY attack that improves upon brute force. If you
> > can eliminate even a single key from the pool of potential candidates
> > via mathematical means it is a valid accademic attack. Heck if you can
> > assign an ordering of likelyhood to potential keys that is an attack.
> > Any method that is more efficient than straight brute force is an
> > attack.
>
> For me that has the flavour of department stores of having $99.99 instead
> of $100.00 counting as a discount.
It's more like cupons, where you might be able to add more and more of
them together until the discount is low enough to actually count...
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
on the verge of frenzy - i think my mask of sanity is about to slip
---���---���-----------------------------------------------���---���---
\O/ \O/ �99-00 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Mon, 23 Oct 2000 22:40:12 +0200
Bryan Olson wrote:
>
> James Felling wrote:
.......
[snip]
> Again I agree. In the long history of this thread, that was
> the basic line of my first attack. That attack depends upon
> each chosen message being encrypted using the same
> permutations. Shen now requires a constantly-updating PRNG
> state to generate the permutations.
I am very surprised by the word 'now' above. I answered
in a post to Tom St Denis that the PRNG is not to be
reset and that correspondence was before we start debating
with each other.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Mon, 23 Oct 2000 22:40:07 +0200
James Felling wrote:
>
> Mok-Kong Shen wrote:
>
> > James Felling schrieb:
> > >
> > > Perhaps I can help. I think I understand Mr. Olson's method, and I also
> > > think I may see the root of your objection.
> > >
> > > Proposed. Submit a block of form (u,v) to the code. out will come block
> > > (x,y) at the end.
> > >
> > > Attn Mok:
> > > If the PRNG's output is not keyed somehow to block number/message
> > > length then by repeatedly doing this single encryption. what will
> > > happen is that the set of all possible single block encryptions of (u,v)
> > > will be eventually generated. Similary by submitting a double block one
> > > may access a set of blocks that will allow you to identify special pairs
> > > of blocks from the 1 block stream. Your system falls in this case.
> >
> > Yes, all possible blocks will eventually be generated with
> > a fairly good chance, if one encrypts a very long message
> > with each block the same (u,v). So one can get a set of
> > possible blocks on the ciphertext side. With 8 cycles this
> > set is likely to be not too small and hence the message
> > length. One point I don't yet understand is how to pick
> > a 'particular' subset from that set that promises to well
> > deliver information about the key and moreover what is the
> > chance of picking that. Could you help me a bit on that?
> > Thanks in advance.
> >
> > M. K. Shen
>
> No. I am NOT claiming a long message. What is being done is a single
> block(u,v) is submitted and encrypted. producing output (x,y). If the PRNG is
> keyed in the proper manner(i.e. Message M with key K at time T encodes to a
> different value than Message M with Key K at time T+1), then there are 64
> possible outputs from this program, which will apear at random and one can by
> repeatedly submiting 1 block messages to the system eventually see in the
> outputs all 64 possible messages. Then one may submit 2 block messages in
> the same manner. This will produce a substantially larger space of possible
> outputs( and once a sulficient proportion of those are collected the "special"
> pairs drop out, and the attack procedes as normal.
>
> Mr. Olson is not submitting a stream of messages, he is submitting very small
> messages repeatedly. This allows him to use statistical tools to pull out the
> special pairs, and then make the attack.
The PRNG is set only once at the start of the session, so
different messages tends to get different permutations.
It is in my view favourable for Bryan Olson's attack to use
a sufficiently long single message than using many messages.
But that probably isn't important for the issue, if I don't
err.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Steganography books
Date: Mon, 23 Oct 2000 14:15:25 -0600
In article <8t1og6$5s3$[EMAIL PROTECTED]>, zapzing <[EMAIL PROTECTED]> wrote:
> >
>
> Actuall since inked or uninked paper is a
> solid, the term "spectral lines" doesn't
> really even apply, since solids generally
> do not have spectral lines, but rather
> retransmit over a continuous region of the
> spectrum.
>
Then, according to this line of thinking, problems that exist should not.
After exitation, atoms radiate according to their specific quantum jumps
to lower states releasing vibrating photons of various frequencies.
Colored radiations have spectra, which is the area that I am looking at.
How true the colors are as spit/sensed is the crux of the problem.
Illumination sources makes a difference in resonance with sensor
capabilities, as certain frequencies excite certain orbital changes better
than others.
--
52) *Part of job is making whimsical, zippy, and vexing key sequences.
------------------------------
From: "Mark Dowdey" <[EMAIL PROTECTED]>
Subject: Re: How about the ERIKO-CHAN cipher?
Date: Mon, 23 Oct 2000 17:09:55 GMT
Musashi <a [EMAIL PROTECTED]> wrote in message ...
>
> Well, not only does the government use things like cryptography in, say,
> a battlefield radio, but other techniques too. I have no idea what
> crypto the SINCGARS radioset uses, but I know that in addition to it, it
> changes frequencies every second (synched with the other radios on the
> net). Seems to me that it's a good idea not to put "all the eggs in one
> basket".
>
Actually, SINCGARS radios hop (change frequencies) 100 times per second, but
the reason for frequency-hopping is to make them harder to jam and harder to
DF (direction find), NOT to provide any more security for the encrypted
transmission. I don't know anything about the actual crypto algorithm used
in these radios, either.
-- Mark Dowdey
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: ---- As I study Rinjdael...
Date: 23 Oct 2000 21:05:18 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in
<[EMAIL PROTECTED]>:
>
>
>"SCOTT19U.ZIP_GUY" wrote:
>>
>> [EMAIL PROTECTED] (Mok-Kong Shen) wrote:
>> >
>> >Greggy wrote:
>> >>
>> >> As I study Rijndael, I am constantly haunted by the question I hope
>> >> someone can answer:
>> >>
>> >> If Rijndael is so strong, why does the US government choose NOT to
>> >> use it for ANY (not all) classified information?
>> >
>> >I am not aware that the US government 'chooses' not to use
>> >Rijndael for any classified information. Why should it tell
>> >you what it uses to encrypt classified information? By
>> >definition, classified information doesn't concern you
>> >as normal citizen at all. (You are not supposed to care
>> >about it.)
>> >
>> >M. K. Shen
>>
>> Actually every concerned citizen should care about what
>> the government ecnrypts otherwise we will go down the same
>> path as the soviets. The amount and type of information the
>> government tries to hide should be closely watched unless one
>> wants to be taken care of cradle to grave with little contorl
>> over ones life. The govenment assumes it knows more than
>> every one else so they use internal methods that have an additional
>> security feature of the algorithms being kept secret. Rijndael
>> fails since the method is not secret. I also suspect it may fail
>> since there is a gook chance the NSA can already break it. Unless
>> one uses a chaining mod like "wrapped PCBC" and those kind of
>> modes will not be approved for use.
>
>Aren't you suggesting that a government should keep no
>secret so that it is entirely open even to hostile
>foreign countries?
>
>M. K. Shen
>
I don't know why I am replying to you. I guess I don't learn.
That is not what I meant. I think due to secrecy my country is
being more and more corrupted by the few. Look at our elections
we critisize other countries for having unfair elections. But
look how my country is running this one. There is no doubt in my
mind. Gore we win because the government is more corrupt than
ever.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: ---- As I study Rinjdael...
Date: Mon, 23 Oct 2000 23:36:08 +0200
John Savard wrote:
>
> Also, from various comments appearing in this newsgroup and other
> things that have appeared in print, because Rijndael is "key agile" -
> it's key schedule runs as quickly, or more quickly, than encipherment
> - one could, using Rijndael, throw together something that may even
> possibly vaguely resemble some techniques actually used on classified
> information, and which is likely to be comparable in security.
>
> 1) Generate 256 bits of true random information. Use this as the first
> 256 bits of your ciphertext.
>
> 2) For each 128 bits of your plaintext, do the following:
>
> - encipher the preceding 256 bits of ciphertext using Rijndael with a
> 256-bit block size, and with the actual message key.
>
> - using the 256-bit result of that encipherment as the key, and a
> 128-bit block size, encipher your 128-bit plaintext block.
>
> - the result of this encryption is the next 128 bits of your
> ciphertext.
I see with interest that you are suggesting a scheme that
employs variable keys for encryting the 128-bit plaintext
blocks. Such variability eliminates from the ground the
opponent's chance of getting the (commonly huge) amount
of materials required for differential analysis etc., as
I noted in a post quite a time back.
BTW, in another post (I can't trace it out presently) you
recently described the idea of interleaving the cycles of
two different block ciphers, if I don't err. I think
that's novel and interesting. (Or does anyone know that
that has ever been proposed before?)
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
Reply-To: [EMAIL PROTECTED]
Date: Mon, 23 Oct 2000 21:53:34 GMT
Richard Heathfield <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Daniel James <[EMAIL PROTECTED]> wrote:
:> : In article <[EMAIL PROTECTED]>, Tim Tyler wrote:
:> :> Perhaps there's an existing technical term for 32-bit units.
:>
:> : I quite like "mouthful" for 4 bytes []
:>
:> Wonderful. You could even spell it "moythful" [...]
: [...] for a 32-bit quantity, 'dynner' is already in the literature. ;-)
Goodness: http://info.astrian.net/jargon/terms/n/nybble.html has
crumb(2), nickle(5), deckle(10), playte(16), chawmp(16), dynner(32) and
gawble(32)!
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Surf against sewage.
------------------------------
** 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
******************************
