Cryptography-Digest Digest #304, Volume #14 Sun, 6 May 01 16:13:00 EDT
Contents:
Re: research on polymorphic crypto/Best Possible Privacy? ("Mark G Wolf")
Re: research on polymorphic crypto/Best Possible Privacy? ("Mark G Wolf")
Re: Best encrypting algoritme ("Tom St Denis")
Re: free en/decryption library ("Tom St Denis")
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: Tiny s-boxes ("Tom St Denis")
Re: Tiny s-boxes (Tim Tyler)
Re: research on polymorphic crypto/Best Possible Privacy? (SCOTT19U.ZIP_GUY)
Re: Best encrypting algoritme (SCOTT19U.ZIP_GUY)
Re: free en/decryption library ("Jack Lindso")
Re: Best encrypting algoritme ("Tom St Denis")
Re: free en/decryption library ("Tom St Denis")
Re: LUCIFER ("Henrick Hellstr�m")
Re: free en/decryption library (Jim Gillogly)
Re: research on polymorphic crypto/Best Possible Privacy? ("Mark G Wolf")
Re: free en/decryption library ("Tom St Denis")
Re: LUCIFER ("Tom St Denis")
----------------------------------------------------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: research on polymorphic crypto/Best Possible Privacy?
Date: Sun, 6 May 2001 13:19:43 -0500
Are you from the propaganda ministry? Or just plain stupid?
This is the future of cryptography. Done right, it's unbreakable.
It's from the Germans, that should make it obvious that it's good.
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: research on polymorphic crypto/Best Possible Privacy?
Date: Sun, 6 May 2001 13:20:00 -0500
Are you from the propaganda ministry? Or just plain stupid?
This is the future of cryptography. Done right, it's unbreakable.
It's from the Germans, that should make it obvious that it's good.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best encrypting algoritme
Date: Sun, 06 May 2001 18:22:04 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Actaually in the first type of challenge What I send is irrelavent
> i send you cipher text and it makes no real differnence what the key
> is since there will be 4 messages that map from the cipher text to
> the key. Here is such a method
> let the identity trandform be used for all files but 8 files
> the eight files being message 1 to 4 and the bytes 00000001 to 00000100
> if you send somthing other than the 8 files. I just xor the key 00 01 10
> or 11 to the first byte. If it is one of the specail 8 i map
> if 00 I map message1 to 00000001 and message 2 to 00000010
> and so on. I also map the reverse so 000000001 goes to message 1
This means the message is part of the system not the ciphertext. This is
not a real system. For example what if I want to send "What a nice day it
is". Your system can't do that.
> if I an using 01 as key i map do as above but map message 2 to 00000001
> so I just rotate and I think it obvious how I do the rest. IN
> each case those four messages map to the set of 1 to 4 in a single byte
> and vica versa.
>
> There I have described a full system for you. the ouput is 00000001
> which message was it or which key. Fact you can't tell.
> Message 1 is "Tom lacks the knowledge to understand bijective encryption"
> Message 2 is "Will tommy every grow up."
> Message 3 is "I douby tommy will ever learn crypto"
> message 4 is "Crypto is to hard for tommy boy"
Your system is different. You prestore possible messages and select them.
That's wholly inefficient since you would need a database of all possible
messages then you just select one. The security of this system remains in
the order of the database and the key, i.e obscurity.
Show me a system where the value '1' (eigith bits) will map to four
different +10 byte messages and I will send you 100,000$. (Assuming all of
the entropy of the four messages is in the single byte). You make no sense.
How can you encrypt different length messages to the same size ciphertext
(except for padding upwards) when a) the ciphertext is smaller and b) the
amount of entropy in the ciphertext is less than the plaintext.
Also may I note that I am the only one humouring your posts so I wouldn't be
so hostile.
> the message was encrypted to 00000001 what was the key or which one
> of the message did I use. You have the complete cyrpto system tommy
> boy what is it or what is the key.
Your "system" is nothing like a real crypto system. In a real system the
ciphertext is a function of the plaintext not of a database that must be
stored. I.e if you want to encrypt a 10 byte message you must pad it upto
16 bytes (or whatever the block length is) and encrypt the block. Not
encrypt a counter into a huge database. Also remember that in real
cryptosystems the entropy of the output (ciphertext) is not smaller than the
input.
> >> IN this second mode where bijectivity rains supremium.
> >
> >You mean by obscurity? The original question related to finding the key
> >not the algorithm.
>
> I just gave you an example of first type for free guess which of the
> messages is sent or what the key was you get only one guess since there
> are only 4 anwsers. If you guess it today in next post I'll sen you
> the money.
How about doing the real challenge? The challenge was you encrypt a message
using AES or some other well known cipher in your padding/bijective mode and
I crack it. This is nothing like the original challenge you stipulated. In
fact I think you are trying to escape it!
> In the second challenge I am limited in the games I can play and
> since a four state machine you should be able to get the anwser
> especailly since I give you so much info where you see how alternate
> files encrypt and decrypt. Hard isn't it. Well its only 2 bits Tommy
> and I can see real crypto even at 2 bits is to hard for you.
Stop insulting me. I am trying to be nice and help cryptanalyze your system
but you just keep insulting me and saying "hhahahaha I know more than you".
Your above system is fictious and nobody in their right mind would use it
simply because it's not efficient.
> >
> ><snip>
> >
> >Ok since your not being halfway intelligent about this. This is the
> >real challenge.
> >
> >You send me the program (complete source code) along with an encrypted
> >message (for our purposes using a small symmetric key) using some known
> >cipher say RC5 or TEA or something. Then I mount the brute force attack
> >to find the key (if possible).
>
> IF I send you the program I want to use it would be with BICOM
> or scott19u as part of it. I know these are more complicated than the toy
> cipher you wish me to use but I wont use RC5 or TEA I wanted something
> designed to be somewhat more secure than the kind you play with.
Why not? Show me a break on RC5 or TEA. See the way you think is broken.
You assume because you didn't invent it, it must be wrong or weak or stupid
or <negative quality>.
> and with scott19u and bicom with 4 states that worked for any key
> yes you can plug in the 4 values but still your guessing which of the
> four solutions it is. Granted it may be hard to find places where all
> four are ascii messages if I allow all files. But there are there.
If your system works by using the cipher on the text in some chaining mode
(whatever you use) and whatever codec you use I can still break it given
enough ciphertexts.
> >My clain is that with about 8kb of text I could easily find the correct
> >key with virtually 100% certainty. (assuming the keyspace is small
> >enough).
>
> your clain is bogus. I just gave you such a system that is fully
> bijective. We can repeat message 1 and 2..4 or add words of your
> choice till its 8k in length. Then you can't do it. Wake up Tommy
> smell the coffee. Try to think before you shoot your mouth off.
Hmm I would say the same to you. Your challenge above is not what we were
talking about earlier.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: free en/decryption library
Date: Sun, 06 May 2001 18:22:52 GMT
"Frank Uepping" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi,
> I am new with en/decryption and I am looking for a free and open
> en/decryption C/C++ library that compiles with gcc and C++ Builder.
May I suggest... READ A TEXT ON THE SUBJECT FIRST!!!!!!!!!!!!!!
(Applied Crypto, Handbook of Applied Crypto and Neal Koblitz's "A course in
number theory and Cryptography" come to mind).
Tom
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Sun, 6 May 2001 13:20:59 -0500
> See: http://www.io.com/~ritter/GLOSSARY.HTM#DynamicSubstitutionCombiner
Thanks, great link.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Tiny s-boxes
Date: Sun, 06 May 2001 18:23:20 GMT
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tim Tyler <[EMAIL PROTECTED]> writes:
> > : 3way is described in Applied Cryptography.
> >
> > Thanks. I /did/ look there - but I went to the index - and there were
> > no entries under "3" or the author's name...
>
> It's definitely in there. Look under Three-way, or in the table of
> contents, or just flip through the chapter on block ciphers til you find
it.
Any rate 3WAY is neat but inefficient on desktops afaik.
Tom
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Tiny s-boxes
Reply-To: [EMAIL PROTECTED]
Date: Sun, 6 May 2001 18:19:02 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
:> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> :> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
:> :> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> :> :> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
:> :> :> To be honest I haven't yet investigated in any depth how best to
:> :> :> implement tiny s-boxes in software.
:> :>
:> :> : Generally in software you group the bits. I.e two 4x4's into one 8x8
:> :> : etc...
:> :>
:> :> Yuck ;-) If someone told me that I had to do things like that then I
:> :> reckon I would be hard-pressed to make a case for using small s-boxes.
:>
:> : In GOST [...] In software you can compute the entire round function
:> : with four 8x32 lookups and three OR's. That's fast.
:>
:> GOST must have some order in its boxes (or something) to pull a trick
:> like that. Four 8 bit table lookups do not the block width of GOST make.
: Hmm that's not clear to me. The round function in GOST is eight parallel
: 4x4 look ups followed by a rotate by 11 bits. You can do both as one set of
: four 8x32 tables.
I had some confusion that stemed from unfamiliarity with GOST.
GOST is a 64 bit block cypher. It's round function involves passing
half the bits through without feeding them through s-boxes. I wasn't
properly acquanted with these facts. GOST's round can be fast because
it isn't doing anything like as much work as I had thought.
:> I'm not sure I'm convinced about this big LUT idea. ISTM that - with
:> my tiny s-boxes - a promising approach would be to shift left 1, and 2
:> places, right 1 and 2 places, and then perform a sequence of masked
:> AND, OR and XOR operations, which calculated all the s-box outputs
:> for a single word in parallel. This wouldn't have to use a LUT at
:> all. The bigger the word size, the more attractive it would be.
:>
:> /Maybe/ if all the LUTS for all the combinations of s-boxes in your cypher
:> fit into your cache then a LUT approach would not work too badly.
: I don't follow ya. GOST, Rijndael, Twofish, Square, etc can be
: done either as 8x8's (or 4x4s for GOST) or as a set of 8x32's...
I figure - with tiny s-boxes - you could do the work with suitable code
a whole word at a time, rather than use LUTs and combine the results.
LUTs might be OK, provided everything fits into your cache at once.
Either approach indicates to me that the lack of divisibility of
2^n by 3 is likely to be the cause of irritating alignment niggles in
each word (rather than in each block as I had originally thought),
when in software.
--
__________ http://rockz.co.uk/ http://alife.co.uk/ http://hex.org.uk/
|im |yler http://atoms.org.uk/ http://mandala.co.uk/ [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: research on polymorphic crypto/Best Possible Privacy?
Date: 6 May 2001 18:31:32 GMT
[EMAIL PROTECTED] (Mark G Wolf) wrote in <9d44me$4epi$1@newssvr06-
en0.news.prodigy.com>:
>Are you from the propaganda ministry? Or just plain stupid?
>
>This is the future of cryptography. Done right, it's unbreakable.
>
>It's from the Germans, that should make it obvious that it's good.
>
>
>
Actaully that portion of german blood in my viens
feels sick when you say its good becasue it german. It is
not very good. Don't forget engima which is actually better
was German.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best encrypting algoritme
Date: 6 May 2001 19:23:50 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<gDgJ6.31116$[EMAIL PROTECTED]>:
>Show me a system where the value '1' (eigith bits) will map to four
>different +10 byte messages and I will send you 100,000$. (Assuming all
>of the entropy of the four messages is in the single byte). You make no
>sense. How can you encrypt different length messages to the same size
>ciphertext (except for padding upwards) when a) the ciphertext is
>smaller and b) the amount of entropy in the ciphertext is less than the
>plaintext.
I doubt the honesty of your comment. But if you were capable of
following the thread "BENNY and the MTB". Its very possible. Its a matter
of fact that one could encrypt more then 256 probable messages to
a one byte output file. THe output file only having the "11111111"
pattern in it.
I think it due to the power of bijective compression encryption. I
don't have a 100,000 but It would be more than willing to send
a hundred dollars to Shaw to hold the cash if you do likewise.
To show you just how much of an asshole you are. Plus I doubt you have
100,000 dollars to bet unless you don't plan on paying it off.
Let my try to explain it to you again. If I had a small key even
the punny AES 256 bit key. There could be 2**256 different messages
that could map to that single byte. With that single value. That is
what bijective compression encryption is all about. Its not the phony
crap the so called crypto gods push.
Yes Tommy boy this is with real crypto so 4 valid 10+ bytes
messages. would be possible. even with a 2 bit system, in a properly
designed bijective cyrpto system. Even if the output file for the
four message map to the same vlaue '11111111". Give a 100 to a trusted
third party member and I will show you again. Where you thinking is scrwed
up. Can you actaully put up or shutup Tom. Crypto is not what your limited
mind thinks it is.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Jack Lindso" <[EMAIL PROTECTED]>
Subject: Re: free en/decryption library
Date: Sun, 6 May 2001 22:36:22 +0200
I think it's very noble of you Tom to volunteer for the job of this
newsgroup's guard.
Cheers.
--
Anticipating the future is all about envisioning the Infinity.
http://www.atstep.com
====================================================
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:0EgJ6.31123$[EMAIL PROTECTED]...
>
> "Frank Uepping" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Hi,
> > I am new with en/decryption and I am looking for a free and open
> > en/decryption C/C++ library that compiles with gcc and C++ Builder.
>
> May I suggest... READ A TEXT ON THE SUBJECT FIRST!!!!!!!!!!!!!!
>
> (Applied Crypto, Handbook of Applied Crypto and Neal Koblitz's "A course
in
> number theory and Cryptography" come to mind).
>
> Tom
>
>
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best encrypting algoritme
Date: Sun, 06 May 2001 19:48:00 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Tom St Denis) wrote in
> <gDgJ6.31116$[EMAIL PROTECTED]>:
>
>
> >Show me a system where the value '1' (eigith bits) will map to four
> >different +10 byte messages and I will send you 100,000$. (Assuming all
> >of the entropy of the four messages is in the single byte). You make no
> >sense. How can you encrypt different length messages to the same size
> >ciphertext (except for padding upwards) when a) the ciphertext is
> >smaller and b) the amount of entropy in the ciphertext is less than the
> >plaintext.
>
> I doubt the honesty of your comment. But if you were capable of
> following the thread "BENNY and the MTB". Its very possible. Its a matter
> of fact that one could encrypt more then 256 probable messages to
> a one byte output file. THe output file only having the "11111111"
> pattern in it.
Hmm if the output is always constant how do you tell one message from
another?
> I think it due to the power of bijective compression encryption. I
> don't have a 100,000 but It would be more than willing to send
> a hundred dollars to Shaw to hold the cash if you do likewise.
> To show you just how much of an asshole you are. Plus I doubt you have
> 100,000 dollars to bet unless you don't plan on paying it off.
Again the insults.
> Let my try to explain it to you again. If I had a small key even
> the punny AES 256 bit key. There could be 2**256 different messages
> that could map to that single byte. With that single value. That is
> what bijective compression encryption is all about. Its not the phony
> crap the so called crypto gods push.
Um wrong. In AES only one input maps to one output under one key. With a
256-bit key one input could map to any of 2^128 different outputs.
> Yes Tommy boy this is with real crypto so 4 valid 10+ bytes
> messages. would be possible. even with a 2 bit system, in a properly
> designed bijective cyrpto system. Even if the output file for the
> four message map to the same vlaue '11111111". Give a 100 to a trusted
> third party member and I will show you again. Where you thinking is scrwed
> up. Can you actaully put up or shutup Tom. Crypto is not what your limited
> mind thinks it is.
Stop being so mean. I am trying to be helpful.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: free en/decryption library
Date: Sun, 06 May 2001 19:48:20 GMT
"Jack Lindso" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I think it's very noble of you Tom to volunteer for the job of this
> newsgroup's guard.
> Cheers.
I do what I can :-)
Tom
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: LUCIFER
Date: Sun, 6 May 2001 21:55:54 +0200
"John Savard" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> On 6 May 2001 00:10:54 -0800, [EMAIL PROTECTED] (Ryan Sorensen) wrote,
> in part:
>
> >I would appreciate it if someone could point me to a paper outlining
LUCIFER.
>
> >I've read the "Cryptography and Computer Privacy" article, but that
wasn't
> >directly on LUCIFER.
> >If the only way I can find a paper on it, specifically "LUCIFER, A
> >Cryptographic Algorithm", is by purchasing the back issue of
Cryptologia,
> >let me know.
>
> That is the only published paper I know of that includes a full
> description of LUCIFER, but there was a paper about the cryptanalysis
> of LUCIFER by Eli Biham that described it fairly well.
>
> However, my web site, at
> http://home.ecn.ab.ca/~jsavard/crypto/co0401.htm
> includes a full, detailed description of the LUCIFER algorithm also.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/
I found something confusing:
| Permute the 64 bits of the result, numbered from 0 (for the most
significant bit) to 63 (for the least significant bit), by the following
permutation:
| 10 21 52 56 27 1 47 38 18 29 60 0 35 9 55 46
| 26 37 4 8 43 17 63 54 34 45 12 16 51 25 7 62
| 42 53 20 24 59 33 15 6 50 61 28 32 3 41 23 14
| 58 5 36 40 11 49 31 22 2 13 44 48 19 57 39 30
I guess this is a permutation in map notation (rather than cyclic
decomposition notation) with implicit order, eight rows in two columns. So
the cyclic decomposition should be:
(0 10 4 27 40 34 60 19 24 58 44 51 32 18 20 59 48 50 28 11 8 26 36 35)(21
...
Why wasn't it a single cycle transposition?
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: free en/decryption library
Date: Sun, 06 May 2001 13:02:57 -0700
Frank Uepping wrote:
> I am new with en/decryption and I am looking for a free and open
> en/decryption C/C++ library that compiles with gcc and C++ Builder.
There are several good ones. Try (as a randomly selected example)
the OpenSSL package at www.openssl.org . If it's a mission-critical
project (i.e. your pension depends on getting it right), you should
get someone with crypto experience involved. If not, you've have
some interesting learning ahead of you.
--
Jim Gillogly
15 Thrimidge S.R. 2001, 20:00
12.19.8.3.11, 6 Chuen 9 Uo, Eighth Lord of Night
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: research on polymorphic crypto/Best Possible Privacy?
Date: Sun, 6 May 2001 15:02:14 -0500
> Actaully that portion of german blood in my viens
> feels sick when you say its good becasue it german. It is
Hey, what do you call someone who hates Germans, "Nazi" is clearly
inappropriate. Jew perhaps.
> not very good. Don't forget engima which is actually better
> was German.
Well basically they're both kind of the same idea really.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: free en/decryption library
Date: Sun, 06 May 2001 20:04:47 GMT
"Jim Gillogly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Frank Uepping wrote:
> > I am new with en/decryption and I am looking for a free and open
> > en/decryption C/C++ library that compiles with gcc and C++ Builder.
>
> There are several good ones. Try (as a randomly selected example)
> the OpenSSL package at www.openssl.org . If it's a mission-critical
> project (i.e. your pension depends on getting it right), you should
> get someone with crypto experience involved. If not, you've have
> some interesting learning ahead of you.
The stressed part here is not only get the right tools but know how to use
em. Just using OpenSSL is not enough to make a secure application.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: LUCIFER
Date: Sun, 06 May 2001 20:06:40 GMT
"Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
news:9d4ad6$dr8$[EMAIL PROTECTED]...
> "John Savard" <[EMAIL PROTECTED]> skrev i meddelandet
> news:[EMAIL PROTECTED]...
> > On 6 May 2001 00:10:54 -0800, [EMAIL PROTECTED] (Ryan Sorensen) wrote,
> > in part:
> >
> > >I would appreciate it if someone could point me to a paper outlining
> LUCIFER.
> >
> > >I've read the "Cryptography and Computer Privacy" article, but that
> wasn't
> > >directly on LUCIFER.
> > >If the only way I can find a paper on it, specifically "LUCIFER, A
> > >Cryptographic Algorithm", is by purchasing the back issue of
> Cryptologia,
> > >let me know.
> >
> > That is the only published paper I know of that includes a full
> > description of LUCIFER, but there was a paper about the cryptanalysis
> > of LUCIFER by Eli Biham that described it fairly well.
> >
> > However, my web site, at
> > http://home.ecn.ab.ca/~jsavard/crypto/co0401.htm
> > includes a full, detailed description of the LUCIFER algorithm also.
> >
> > John Savard
> > http://home.ecn.ab.ca/~jsavard/
>
>
> I found something confusing:
>
> | Permute the 64 bits of the result, numbered from 0 (for the most
> significant bit) to 63 (for the least significant bit), by the following
> permutation:
> | 10 21 52 56 27 1 47 38 18 29 60 0 35 9 55 46
> | 26 37 4 8 43 17 63 54 34 45 12 16 51 25 7 62
> | 42 53 20 24 59 33 15 6 50 61 28 32 3 41 23 14
> | 58 5 36 40 11 49 31 22 2 13 44 48 19 57 39 30
>
> I guess this is a permutation in map notation (rather than cyclic
> decomposition notation) with implicit order, eight rows in two columns. So
> the cyclic decomposition should be:
>
> (0 10 4 27 40 34 60 19 24 58 44 51 32 18 20 59 48 50 28 11 8 26 36 35)(21
> ...
>
> Why wasn't it a single cycle transposition?
Another question. I am new to group theory (heck I am new to all theory
essentially). I know what a single cycle (convolution) is but what is a
"cyclic decomposition"?
Is that related to Cauchy's theory of composition of all permuations can be
formed by a set of disjoint permutations? (arrg... been a while since I
looked at any of this)
Tom
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************