Cryptography-Digest Digest #552, Volume #12 Mon, 28 Aug 00 02:13:01 EDT
Contents:
Re: Patent, Patent is a nightmare, all software patent shuld not be allowed (Mack)
Re: Destruction of CDs (Mack)
Re: An interesting cryptographic problem (Thierry Moreau)
Re: 4x4 s-boxes (Mack)
Re: 4x4 s-boxes (Mack)
Re: Serious PGP v5 & v6 bug! (Sundial Services)
Re: Pencil and paper cipher (Jim Gillogly)
Re: Pencil and paper cipher ("Douglas A. Gwyn")
Re: Patent, Patent is a nightmare, all software patent shuld not be allowed ("Paul
Pires")
Re: 4x4 s-boxes ([EMAIL PROTECTED])
Re: 4x4 s-boxes ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Patent, Patent is a nightmare, all software patent shuld not be allowed
Date: 28 Aug 2000 04:10:47 GMT
>Hi All,
>
>I just encountered this patent while surfing the net. How can the
>patent office issue a patent on such fundamental things? Anyone has
>some knowledge of PKI system will come out on this as a solutions. And
>PGP has long history of using public key to encrypted symmetric key for
>e-mail, document transferred, long before the so call patent. Any one
>has comments on this issue?
>
>=======
>Title: Method and system for dynamic server document encryption
>Assignee & Date: Tumbleeweed Comm. Corp. may/09/2000
>
>Abstract
>A method and system are provided for secure document delivery over a
>wide area network,
>such as the Internet. A sender directs a Delivery Server to retrieve an
>intended
>recipient's public key. The Delivery Server dynamically queries a
>certificate authority
>and retrieves the public key. The public key is transmitted from the
>Delivery Server to
>the sender. The sender encrypts the document using a secret key and
>then encrypts the
>secret key using the public key. Both encrypted document and encrypted
>secret key are
>uploaded to the Delivery Server, and transmitted to the intended
>recipient. The intended
>recipient then uses the private key associated with the public key to
>decrypt the secret
>key, and uses the secret key to decrypt the document. In an
>alternative, equally preferred
>embodiment of the invention, the sender uses the public key to encrypt
>the document.
>In yet another embodiment, the server transmits the document to the
>Delivery Server for
>encryption.
>
>Claims:
>1. A method for secure document delivery from a sender over a wide area
>network, comprising the
>steps of:
>a sender encrypting a document using a secret key;
>the sender contacting a Delivery Server to query a public key
>associated with an intended recipient;
>the Delivery Server dynamically retrieving the public key in real time
>from a certificate authority;
>the Delivery Server transmitting the public key back to the sender;
>the sender encrypting the secret key with the public key; and
>the sender transmitting the encrypted document and the encrypted secret
>key to the Delivery Server
>for transmission to the recipient.
>
hmm seems to cover most of what PGP servers have done for a while
and kerberos and various other methods. wonder when the patent
was applied for.
It may be facially invalid due to prior art.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Destruction of CDs
Date: 28 Aug 2000 04:24:50 GMT
>
>The metal in CD-RW discs melts at around 600 °C (1,112 °F) depending on
>the exact formulation. The crystallization temperature is much lower,
>roughly 200 °C (392 °F), which is enough to destroy the data.
>
Ie. blast furnaces will destroy the metal ... charcoal and car a/c blower
can be made to fit that bill. Not exactly easy but doable.
>CD-Rs are more complicated. The cyanine, phthalocyanine, and Metal Azo
>dyes used in CD-Recordable discs are organic photosensitive compounds,
>much like those used in making photographs (which explains why Fuji
>and Kodak are in the business.) When a CD-R is recorded, the dye is
>heated by the writing laser and becomes opaque (or absorptive).
>This is due to a combination of the photosensitive effect, chemical
>changes related to reaction to the heat, mingling with nearby melted
>polycarbonate, a depression in the dye layer caused by a deformation
>of the reflective layer beneath, bubble creation, and texture change.
>Unlike the CD-RW, the CD-R sets the laser power by doing a test write,
>so the actual temperature at the writing point varies widely, and there
>is no good method of determining the exact temperature.
>
>Polycarbonate starts to soften and deform at around 130 °C (266 ° F),
>is quite soft at 150 °C (302 °F). We mold CDs, CD-Rs and CR-RWs at
>271-293 °C (520-559 °F).
An oven probably wont do the trick then. At least not a kitchen oven.
certainly a ceramics kiln could destory CDs.
>
>I believe (but cannot prove) that the temperature at the CD-R writing
>spot is above the melting temperature of Polycarbonate. The temperature
>that will make the CD-R unusable will be much lower (does someone care
>to do some kitchen oven experiments and post the results?), but the
>temperature at which a determined attacker cannot distinguish the
>laser written spot from the rest is almost certainly higher than the
>melting point of polycarbonate. In fact, I doubt that any amount of
>heat will mimic the photosensitivity effect of a laser. For that, I
>would look for a way to turn the laser of a CD-R writer full on and do
>a 1X burn with it.
>
>(If anyone wants to hire an expert on this sort of thing, my resume
> may be found at [ http://users.deltanet.com/~guymacon ] )
Wonder if there is a market for an 'ultimate CD destroyer'?
>
>CD-R trivia: Take a new blank CD-R. Put it in your CD-R drive and
>try to read it. Repeat 101 times. The disc is now unwritable.
>If you know why, wait a day before posting the answer so those who
>don't know can take a few guesses.
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Thierry Moreau <[EMAIL PROTECTED]>
Subject: Re: An interesting cryptographic problem
Date: Sun, 27 Aug 2000 18:46:56 -0500
[EMAIL PROTECTED] wrote:
> In article <8o091n$24v$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> The ASK can also be changed. This involves creating a new ASK file with
> a randomly-chosen ASK embedded in it. To avoid attack by differential
> cryptanalysis, the new file should also contain a large amount of fresh
> pseudo-random data, making it extremely difficult to determine the key
> offsets within the file. The new ASK is never revealed to the user.
> This approach seems to be reasonably immune from attack. A malicious
> system administrator could disassemble the DLL to determine the ASK and
> then use this knowledge to decrypt password information - but this is
> an acceptable risk.
In some central systems like the one you are describing, the ASK is stored
and used solely in a secure tampere-proof cryptographic co-processor. At
one point, I was assuming that RDBMS vendors would offer some integration
of their packages with such secure crypto co-processors, but I was never
able to verify this fact. So I very much appreciate your concerns, and if
you have any bargaining power with your RDBMS supplier, you might submit
your requirements to them.
Good luck
- Thierry Moreau
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: 4x4 s-boxes
Date: 28 Aug 2000 04:39:45 GMT
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Mack) wrote:
>> >In article <[EMAIL PROTECTED]>,
>> > [EMAIL PROTECTED] (Mack) wrote:
>> >> Has anyone analyzed the number of s-boxes
>> >> that could be used for Serpent?
>> >>
>> >> more specifically, serpent s-boxes don't appear
>> >> to have particularly good avalanche characteristics.
>> >>
>> >> The criteria seem logic but is it possible that
>> >> the serpent s-boxes might have been chosen
>> >> using stricter criteria?
>> >
>> >My "serpent_sboxes" on my website are good candidates for replacement
>> >sboxes if needed.
>> >
>> >Tom
>> >--
>> >http://www.geocities.com/tomstdenis/
>> >
>>
>> I have looked at your program to produce s-boxes.
>>
>> My question is of a more general nature. ie. how many
>> s-boxes actually meet th Serpent criteria and could
>> we add additional criteria to the given ones that would
>> improve the characteristics without producing a null
>> set of s-boxes.
>>
>> for example. 4x4 s-boxes having the forward and
>> inverse both maximum non-linearity and meeting
>> sac are rare at best and non-existent at worst.
>> Does anyone know if such s-boxes exist?
>
>The sboxes I made have are completely non-linear i.e their "bent", they
>fullfil SAC and BIC to the order-3. Other then a DPmax of four they
>are perfect sboxes.
>
>Finding them is hard, it took about 8 hours of random searching with
>sboxgen. I am in the middle of making another set right now actually.
>
>Overall about 1 in 100 million are ok. This is really rough since I
>didn't keep track of the totals. This means about 1 in 2^27 are ok,
>and since there are only 2^44 possible sboxes, about 2^17 should exist.
>
>Tom
>
It is relatively easy to find s-boxes that meet the SAC, BIC and non-linearity
requirements in the forward direction. there are only 1368 boolean functions
of four variables that meet the non-linearity requirement of 4 and SAC. There
are even less that meet the requirement of 6.
Note that for a permutation to be bent it is not bijective. I am interested in
Bijective 4x4 s-boxes with equally good properties in both directions.
Have you found any s-boxes that are bijective (invertible) and
satisfy the nonlinearity of 4 and SAC in both directions?
"Good S-boxes are easy to find" by Adams and Tavares
says that there are 60 sboxes that meet SAC, non-linearity,
and BIC and are bijective with both the box and its inverse
meeting these properties. They list three S-boxes but they aren't
the ones that meet these criteria.
Does anyone actually have a list of the s-boxes?
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: 4x4 s-boxes
Date: 28 Aug 2000 04:54:15 GMT
>
>
>Mack wrote:
>>
>
>> My question is of a more general nature. ie. how many
>> s-boxes actually meet th Serpent criteria and could
>> we add additional criteria to the given ones that would
>> improve the characteristics without producing a null
>> set of s-boxes.
>
>I know too little in the issue. However, it seems to me to
>be certain, in view of the existence of several (instead of
>one) criteria, that there is generally no (one single) best
>S-box, but there are a number of S-boxes that are deemed to
>be satisfactory according to an evaluation that accords a
>chosen set of weights to the criteria. It would be
>interesting to know for a given block cipher what these
>weights are and the computed values pertaining to the
>individual criteria, I suppose. What I still believe to be
>disadvantageous (despite some counter-arguments I know of)
>is the commonly observed fact that there are too few number
>of S-boxes being used and the same set of S-boxes (and in
>the same ordering) is used for all rounds of the cipher.
>
>M. K. Shen
>
>
The ordering of the s-boxes in the rounds is very regular.
It makes implementation easy. However it would seem that
a more random ordering might be better.
ie 0 1 2 3 4 5 6 7 0 2 4 6 1 3 5 7 6 4 2 0 6 5 4 3 2 1 0 7 5 3 1
Not random but much nicer patterning. No s-box directly feeds
itself and s-boxes have different ones feeding them every time.
Has anyone studied the interactions of these s-boxes?
ie. if a different ordering would be better or worse?
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
Date: Sun, 27 Aug 2000 22:27:05 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
I think this whole thing is simply a demonstration of how crypto works
in real life. Someone thinks up what he considers to be a good or
necessary "feature," and envisions it (or at least, presents it to the
public) only in a good, positive light. But the very thing that
cryptography is designed to protect against is the -worst- that people
can be, the most -devious- or -nefarious-, not the best. And it is, or
should be, "a given" that the opponent is going to be as sneaky as
possible. The Greeks won the war because they didn't try to batter down
the Trojan walls by force.
It's perfectly reasonable, in cryptography, to assume that the opponent
has done something sneaky, and also to assume that you don't know
they've done it; that by all appearances it seems nothing is the
matter. Opponents around the globe know that if they can only achieve
-this- the rest is a non-issue.
Eventually, of course, someone "thinks like the bad-guys do" and writes
a nice public news-story about it. As is the case here.
>Hendrik wrote:
> This whole debacle is a nice example of how "market forces" can screw up
> what voluntary, open, public cooperation can do much better. :-)
>
> Hendrik
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Pencil and paper cipher
Date: Mon, 28 Aug 2000 05:31:53 +0000
Benjamin Goldberg wrote:
> Split the alphabet into 4 words, length 3, 5, 7, 11:
> AFN GTJIK DOSPEQB ULVHWMXRYCZ
>
> Now, multi-encipher the message using Vernam's method, using each string
> as a seperate key:
>
> ThisI sTheP laint extIH opeTh atItI sUnde ciphe rable
> AFNAF NAFNA FNAFN AFNAF NAFNA FNAFN AFNAF NAFNA FNAFN
> GTJIK GTJIK GTJIK GTJIK GTJIK GTJIK GTJIK GTJIK GTJIK
> DOSPE QBDOS PEQBD OSPEQ BDOSP EQBDO SPEQB DOSPE QBDOS
> ULVHW MXRYC ZULVH WMXRY CZULV HWMXR YCZUL VHWMX RYCZU
> -----------------------------------------------------
> QLDAM WCXMS GYEJV TPKKS TPKML CUOLQ DDXGW IBNAG KTYIC
>
> How would one break this cipher, and is a computer needed?
A known plaintext attack would need no more than 26 letters:
express each ciphertext letter as the sum of the 3 letters
in each column and the plaintext, and you have 26 independent
equations in 26 unknowns. I didn't check to see if you're
changing it based on upper/lower case, but that's just a few
more known plaintext letters. Should be dead simple.
If you really use words for your key, then a dictionary search
also works.
Ciphertext-only should also be possible, but more tedious.
--
Jim Gillogly
Trewesday, 6 Halimath S.R. 2000, 05:27
12.19.7.9.0, 2 Ahau 3 Mol, Ninth Lord of Night
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Pencil and paper cipher
Date: Mon, 28 Aug 2000 01:33:12 -0400
Benjamin Goldberg wrote:
> How would one break this cipher, and is a computer needed?
Similar methodology to Hagelin, and it is doable with pencil
and paper, although easier with a computer.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Patent, Patent is a nightmare, all software patent shuld not be allowed
Date: Sun, 27 Aug 2000 22:35:17 -0700
qun ying <[EMAIL PROTECTED]> wrote in message news:8oce2c$kkn$[EMAIL PROTECTED]...
> Hi All,
>
> I just encountered this patent while surfing the net. How can the
> patent office issue a patent on such fundamental things? Anyone has
> some knowledge of PKI system will come out on this as a solutions. And
> PGP has long history of using public key to encrypted symmetric key for
> e-mail, document transferred, long before the so call patent. Any one
> has comments on this issue?
>
> =======
> Title: Method and system for dynamic server document encryption
> Assignee & Date: Tumbleeweed Comm. Corp. may/09/2000
>
> Abstract
> A method and system are provided for secure document delivery over a
> wide area network,
> such as the Internet. A sender directs a Delivery Server to retrieve an
> intended
> recipient's public key. The Delivery Server dynamically queries a
> certificate authority
> and retrieves the public key. The public key is transmitted from the
> Delivery Server to
> the sender. The sender encrypts the document using a secret key and
> then encrypts the
> secret key using the public key. Both encrypted document and encrypted
> secret key are
> uploaded to the Delivery Server, and transmitted to the intended
> recipient. The intended
> recipient then uses the private key associated with the public key to
> decrypt the secret
> key, and uses the secret key to decrypt the document. In an
> alternative, equally preferred
> embodiment of the invention, the sender uses the public key to encrypt
> the document.
> In yet another embodiment, the server transmits the document to the
> Delivery Server for
> encryption.
>
> Claims:
> 1. A method for secure document delivery from a sender over a wide area
> network, comprising the
> steps of:
> a sender encrypting a document using a secret key;
> the sender contacting a Delivery Server to query a public key
> associated with an intended recipient;
> the Delivery Server dynamically retrieving the public key in real time
> from a certificate authority;
> the Delivery Server transmitting the public key back to the sender;
> the sender encrypting the secret key with the public key; and
> the sender transmitting the encrypted document and the encrypted secret
> key to the Delivery Server
> for transmission to the recipient.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Maybe this is a real injustice. Maybe not. Let me read you a few lines of code
and point out how stupid they are. Not hard to do. Consider the code as a whole,
with time for research and reflection. You may find me a boob. (Not hard to do).
No gasoline is required here. Heck, just toss in a match.
Paul
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 4x4 s-boxes
Date: Mon, 28 Aug 2000 05:39:38 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mack) wrote:
> >In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (Mack) wrote:
> >> >In article <[EMAIL PROTECTED]>,
> >> > [EMAIL PROTECTED] (Mack) wrote:
> >> >> Has anyone analyzed the number of s-boxes
> >> >> that could be used for Serpent?
> >> >>
> >> >> more specifically, serpent s-boxes don't appear
> >> >> to have particularly good avalanche characteristics.
> >> >>
> >> >> The criteria seem logic but is it possible that
> >> >> the serpent s-boxes might have been chosen
> >> >> using stricter criteria?
> >> >
> >> >My "serpent_sboxes" on my website are good candidates for
replacement
> >> >sboxes if needed.
> >> >
> >> >Tom
> >> >--
> >> >http://www.geocities.com/tomstdenis/
> >> >
> >>
> >> I have looked at your program to produce s-boxes.
> >>
> >> My question is of a more general nature. ie. how many
> >> s-boxes actually meet th Serpent criteria and could
> >> we add additional criteria to the given ones that would
> >> improve the characteristics without producing a null
> >> set of s-boxes.
> >>
> >> for example. 4x4 s-boxes having the forward and
> >> inverse both maximum non-linearity and meeting
> >> sac are rare at best and non-existent at worst.
> >> Does anyone know if such s-boxes exist?
> >
> >The sboxes I made have are completely non-linear i.e their "bent",
they
> >fullfil SAC and BIC to the order-3. Other then a DPmax of four they
> >are perfect sboxes.
> >
> >Finding them is hard, it took about 8 hours of random searching with
> >sboxgen. I am in the middle of making another set right now
actually.
> >
> >Overall about 1 in 100 million are ok. This is really rough since I
> >didn't keep track of the totals. This means about 1 in 2^27 are ok,
> >and since there are only 2^44 possible sboxes, about 2^17 should
exist.
> >
> >Tom
> >
>
> It is relatively easy to find s-boxes that meet the SAC, BIC and non-
linearity
> requirements in the forward direction. there are only 1368 boolean
functions
> of four variables that meet the non-linearity requirement of 4 and
SAC. There
> are even less that meet the requirement of 6.
I don't get the "requirement of 4". Generally you perform a WT or
FWT. In my case I chose th WT and I get -4/4 which is the best you can
get for a "bent" sbox.
> Note that for a permutation to be bent it is not bijective. I am
interested in
> Bijective 4x4 s-boxes with equally good properties in both directions.
Actually any bijection function will have an inverse with the same
linearnity. (this is really simple to prove too).
> Have you found any s-boxes that are bijective (invertible) and
> satisfy the nonlinearity of 4 and SAC in both directions?
Yes, my serpent sboxes. They have a WT of -4/4 (doesn't matter which
direction), a differntial xor-pair max of 4, fulfill SAC and BIC to
order 3 (which means no set of 3 4x1 outputs can be linearly related
via xor)
> "Good S-boxes are easy to find" by Adams and Tavares
> says that there are 60 sboxes that meet SAC, non-linearity,
> and BIC and are bijective with both the box and its inverse
> meeting these properties. They list three S-boxes but they aren't
> the ones that meet these criteria.
>
> Does anyone actually have a list of the s-boxes?
Um this is all wrong. There are 16! ~ 2^44 possible 4x4 sboxes, of
which many are nonlinear and differentially secure. For example the
following 1000 sboxes have a WT of -4/4, a DP max of 4. But they don't
nessasarily follow SAC or BIC. At the end there are 50 sboxes that
meet all of this in the forwards direction.
Check out my sboxgen at http://www.geocities.com/tomstdenis/ for more
info on making sboxes.
/* 1000, 4 by 4 sbox(es) */
const int sbox[1000][16] = {
{ 3, 7, 14, 1, 8, 2, 4, 12, 13, 11, 0, 9, 5, 6, 15, 10 },
{ 10, 15, 8, 4, 11, 5, 13, 1, 3, 6, 14, 12, 7, 9, 0, 2 },
{ 7, 4, 3, 11, 12, 5, 0, 13, 8, 6, 9, 14, 2, 1, 15, 10 },
{ 14, 8, 7, 6, 5, 10, 0, 4, 9, 15, 3, 11, 13, 1, 2, 12 },
{ 13, 2, 11, 6, 7, 5, 3, 4, 15, 8, 0, 1, 12, 9, 14, 10 },
{ 12, 6, 5, 7, 10, 9, 1, 15, 8, 13, 2, 4, 14, 0, 11, 3 },
{ 4, 7, 15, 8, 10, 2, 9, 13, 14, 3, 12, 6, 1, 0, 5, 11 },
{ 12, 13, 6, 3, 4, 0, 9, 11, 14, 1, 2, 8, 5, 10, 7, 15 },
{ 9, 6, 14, 10, 15, 12, 3, 8, 0, 5, 11, 2, 4, 1, 13, 7 },
{ 1, 12, 14, 5, 10, 11, 0, 7, 4, 15, 6, 3, 13, 9, 8, 2 },
{ 3, 9, 1, 13, 12, 15, 0, 6, 11, 10, 8, 5, 14, 4, 7, 2 },
{ 3, 12, 8, 10, 5, 9, 4, 14, 0, 11, 6, 1, 7, 13, 15, 2 },
{ 10, 8, 3, 1, 11, 5, 12, 13, 9, 7, 15, 6, 2, 14, 4, 0 },
{ 9, 15, 10, 5, 0, 1, 4, 7, 2, 3, 14, 12, 6, 11, 13, 8 },
{ 13, 6, 2, 11, 5, 4, 9, 7, 14, 0, 12, 1, 8, 10, 3, 15 },
{ 6, 0, 7, 11, 10, 15, 4, 9, 3, 8, 5, 1, 13, 2, 12, 14 },
{ 14, 9, 12, 11, 7, 5, 3, 10, 4, 13, 2, 0, 1, 15, 8, 6 },
{ 3, 1, 8, 12, 7, 4, 5, 2, 9, 6, 10, 13, 11, 0, 14, 15 },
{ 0, 13, 7, 15, 11, 1, 2, 5, 12, 6, 10, 4, 14, 3, 8, 9 },
{ 7, 10, 6, 0, 13, 12, 4, 15, 2, 1, 9, 3, 14, 5, 8, 11 },
{ 6, 10, 13, 14, 12, 3, 0, 11, 7, 5, 4, 9, 1, 2, 8, 15 },
{ 3, 13, 11, 10, 5, 8, 15, 6, 9, 0, 1, 4, 2, 7, 12, 14 },
{ 7, 11, 2, 13, 1, 8, 5, 12, 3, 15, 10, 0, 4, 6, 9, 14 },
{ 2, 14, 5, 13, 1, 4, 3, 6, 12, 8, 9, 15, 7, 0, 11, 10 },
{ 1, 11, 15, 5, 14, 9, 7, 2, 8, 12, 4, 10, 0, 3, 13, 6 },
{ 12, 1, 3, 13, 10, 11, 9, 15, 2, 7, 8, 5, 4, 14, 6, 0 },
{ 9, 2, 15, 3, 10, 8, 6, 1, 0, 11, 13, 5, 4, 12, 14, 7 },
{ 9, 1, 7, 13, 3, 11, 14, 8, 12, 0, 4, 6, 5, 2, 15, 10 },
{ 13, 15, 10, 0, 2, 9, 7, 12, 4, 8, 5, 11, 6, 3, 1, 14 },
{ 3, 5, 1, 14, 9, 0, 7, 10, 11, 8, 4, 12, 2, 15, 13, 6 },
{ 1, 4, 6, 14, 9, 3, 5, 7, 11, 10, 0, 8, 12, 15, 13, 2 },
{ 6, 5, 13, 7, 14, 12, 3, 10, 4, 11, 8, 15, 0, 1, 9, 2 },
<<snip>>
better sboxes
/* 50, 4 by 4 sbox(es) */
const int sbox[50][16] = {
{ 14, 0, 1, 8, 15, 7, 11, 12, 6, 2, 4, 3, 10, 9, 13, 5 },
{ 12, 5, 3, 0, 8, 13, 4, 6, 9, 15, 11, 7, 2, 14, 1, 10 },
{ 2, 12, 1, 8, 7, 4, 3, 9, 14, 11, 6, 0, 5, 13, 10, 15 },
{ 10, 4, 1, 0, 6, 7, 8, 5, 14, 12, 3, 13, 9, 2, 11, 15 },
{ 9, 10, 1, 5, 14, 4, 13, 12, 8, 6, 11, 0, 3, 7, 15, 2 },
{ 9, 11, 4, 0, 13, 10, 14, 6, 7, 8, 5, 12, 15, 3, 2, 1 },
{ 5, 14, 8, 10, 0, 12, 11, 2, 13, 9, 15, 1, 4, 7, 3, 6 },
{ 5, 11, 9, 13, 7, 2, 6, 12, 8, 0, 10, 1, 3, 4, 14, 15 },
{ 5, 12, 13, 9, 0, 10, 7, 6, 14, 2, 11, 8, 4, 3, 15, 1 },
{ 2, 0, 1, 8, 11, 6, 7, 9, 5, 4, 13, 3, 10, 12, 14, 15 },
{ 6, 15, 7, 0, 4, 2, 1, 8, 9, 11, 5, 13, 14, 3, 12, 10 },
{ 0, 9, 4, 6, 5, 3, 2, 11, 7, 13, 15, 8, 12, 1, 14, 10 },
{ 15, 12, 13, 0, 7, 10, 1, 2, 9, 5, 4, 6, 8, 14, 11, 3 },
{ 3, 1, 5, 4, 14, 6, 7, 8, 0, 9, 11, 13, 10, 12, 2, 15 },
{ 5, 1, 12, 14, 13, 3, 9, 8, 0, 15, 6, 7, 11, 2, 10, 4 },
{ 0, 9, 2, 4, 8, 5, 13, 6, 10, 12, 14, 7, 11, 15, 1, 3 },
{ 8, 9, 3, 13, 14, 10, 12, 1, 2, 0, 6, 15, 11, 4, 7, 5 },
{ 5, 9, 4, 12, 14, 13, 1, 7, 0, 3, 6, 11, 10, 2, 8, 15 },
{ 15, 4, 9, 11, 7, 3, 13, 6, 14, 10, 12, 2, 8, 1, 5, 0 },
{ 15, 13, 11, 5, 4, 9, 14, 12, 3, 2, 8, 7, 1, 0, 6, 10 },
{ 1, 5, 7, 6, 4, 12, 13, 10, 0, 11, 9, 15, 2, 8, 14, 3 },
{ 14, 13, 10, 15, 7, 3, 4, 12, 0, 9, 11, 5, 2, 8, 6, 1 },
{ 3, 11, 13, 0, 1, 6, 5, 7, 10, 14, 15, 4, 2, 12, 8, 9 },
{ 10, 9, 0, 12, 3, 14, 4, 6, 2, 11, 15, 8, 7, 1, 13, 5 },
{ 3, 4, 14, 12, 0, 8, 2, 15, 5, 13, 6, 11, 10, 9, 7, 1 },
{ 5, 1, 14, 7, 2, 3, 4, 11, 12, 15, 8, 6, 0, 10, 9, 13 },
{ 6, 3, 15, 7, 14, 0, 13, 10, 11, 9, 1, 4, 12, 5, 8, 2 },
{ 3, 15, 11, 10, 9, 14, 5, 1, 0, 2, 7, 8, 4, 12, 6, 13 },
{ 5, 10, 2, 11, 9, 8, 1, 15, 4, 0, 12, 14, 3, 13, 6, 7 },
{ 9, 7, 6, 5, 8, 10, 2, 15, 4, 1, 12, 0, 3, 11, 14, 13 },
{ 11, 3, 5, 0, 13, 14, 12, 2, 8, 9, 1, 7, 6, 10, 4, 15 },
{ 4, 2, 7, 8, 13, 9, 1, 0, 12, 6, 10, 3, 14, 11, 15, 5 },
{ 5, 2, 12, 1, 14, 6, 8, 3, 13, 15, 9, 7, 0, 4, 11, 10 },
{ 12, 0, 4, 7, 9, 1, 6, 8, 3, 2, 5, 10, 13, 11, 15, 14 },
{ 8, 11, 10, 6, 0, 4, 12, 15, 13, 1, 14, 5, 9, 2, 3, 7 },
{ 11, 6, 5, 4, 15, 7, 13, 10, 9, 12, 14, 0, 8, 2, 1, 3 },
{ 5, 7, 0, 4, 12, 1, 6, 9, 3, 14, 10, 2, 13, 15, 11, 8 },
{ 12, 10, 15, 7, 13, 4, 2, 6, 14, 1, 11, 9, 0, 5, 8, 3 },
{ 10, 1, 14, 0, 4, 13, 15, 9, 3, 5, 2, 11, 6, 7, 8, 12 },
{ 4, 12, 7, 1, 5, 2, 15, 6, 9, 14, 0, 8, 3, 10, 13, 11 },
{ 12, 6, 0, 5, 14, 10, 13, 3, 7, 1, 8, 9, 15, 4, 11, 2 },
{ 10, 2, 6, 4, 14, 1, 7, 8, 3, 5, 9, 0, 12, 13, 15, 11 },
{ 11, 13, 9, 8, 2, 15, 6, 5, 12, 0, 1, 10, 14, 4, 7, 3 },
{ 1, 15, 4, 13, 3, 2, 12, 10, 5, 6, 11, 14, 9, 7, 8, 0 },
{ 4, 0, 1, 10, 5, 6, 12, 8, 3, 9, 11, 14, 15, 2, 13, 7 },
{ 12, 14, 9, 0, 13, 5, 2, 4, 7, 10, 15, 11, 1, 6, 3, 8 },
{ 7, 8, 0, 4, 15, 9, 2, 10, 11, 3, 1, 6, 14, 5, 12, 13 },
{ 3, 9, 10, 15, 5, 2, 13, 7, 1, 4, 14, 6, 8, 0, 11, 12 },
{ 10, 15, 14, 6, 7, 0, 13, 12, 9, 5, 4, 3, 11, 1, 8, 2 },
{ 11, 5, 1, 8, 15, 14, 3, 13, 9, 10, 4, 12, 0, 6, 2, 7 } };
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 4x4 s-boxes
Date: Mon, 28 Aug 2000 05:44:23 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mack) wrote:
> Has anyone analyzed the number of s-boxes
> that could be used for Serpent?
>
> more specifically, serpent s-boxes don't appear
> to have particularly good avalanche characteristics.
>
> The criteria seem logic but is it possible that
> the serpent s-boxes might have been chosen
> using stricter criteria?
At http://www.geocities.com/tomstdenis/files/sboxes.c
You can find about 10000 4x4 sboxes that have a DPmax of 4, a LPmax of
4. They don't follow SAC/BIC in either direction.
This just goes to show that your citation from CAST was wrong.
It's true however that the number of sboxes that follow SAC/BIC in one
direction is quite a bit lower, and much lower in *both* direction.
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
******************************
