Cryptography-Digest Digest #771, Volume #11 Sun, 14 May 00 16:13:01 EDT
Contents:
Re: UK issue; How to determine if a file contains encrypted data? (wtshaw)
Re: Patentability of an innovation ... ("C. Prichard")
Re: Notes on the "Vortex" block cipher (Bruce Schneier)
Re: Notes on the "Vortex" block cipher ("Scott Fluhrer")
Re: Encryption of graphics by transposition (wtshaw)
Re: Encryption of graphics by transposition (Tom St Denis)
Hello All Mathamatics Question (Nemo psj)
Re: About Hardware RNG (Guy Macon)
Notes on the Pikachu cipher ([EMAIL PROTECTED])
Re: Notes on the "Vortex" block cipher ([EMAIL PROTECTED])
Re: AES Comment: the Hitachi patent (Mok-Kong Shen)
Re: Question regarding authentication implementation (Abid Farooqui)
Re: Notes on the Pikachu cipher (Tom St Denis)
Re: Hello All Mathamatics Question (Tom St Denis)
Re: Notes on the "Vortex" block cipher (Tom St Denis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: UK issue; How to determine if a file contains encrypted data?
Date: Sun, 14 May 2000 09:43:49 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> Beyond the UK, in countries where the simple possession of an
> encryption app might result in incarceration or even torture without
> trial, I suspect an app that is itself hidden would be a decided
> advantage. Especially since with the growing complexity of OSs, use
> of caches, registry keys, etc etc, it is getting beyond the capacity
> of all but the most sophisticated users to hide or remove all traces
> of an app. and its use.
I love it...in frustration of not knowing all about how an OS works, you
see that bad turns to worse, sour moves to bitter, but you don't have to
be subject to undue complications to do a simple thing like hiding a
program. Actually, if all the tools of knowledge about an OS are
available, countless ways to do unlimited creative things are possible;
trivial hiding is easy then, if you choose that route. Don't get bought
off by threats of terminal mismanagement and pleas to justify darkness and
snoopervision by people whose greatest mission is to keep you as a dumb,
begging sucker, ...and, their calloused succor.
--
Secrets that are told or availabe are not secrets anymore, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Patentability of an innovation ...
Date: Sun, 14 May 2000 16:28:40 GMT
FYI:
The 'CipherText' U.S. patent application is claiming that the use of an =
LRC-like checksum that involves all characters of the key to control its =
modified key rotation, is a novel innovation in cryptology. Serious =
implementation of the feature will likely see straight added sum and LRC =
values combined, however an LRC value seems to work well.
CipherText is a pseudo blocking cipher that has a data-dependent shift =
and has been optimized for Page Tag Encryption. It now exists in a Perl =
class module and has a new ASCII filter feature.
Thanks for the research Bruce.
Regards,
Charles Prichard
www.greentv.com
Bruce Schneier <[EMAIL PROTECTED]> wrote in message =
news:[EMAIL PROTECTED]...
> I just sent this comment to NIST:
>=20
> Bruce
>=20
> ********************************************************
>=20
> Hitachi has two U.S. patents, numbers 4,982,429 and 5,103,479, each of
> which is purported to cover "any" encryption system using rotations.
> These patents were filed in 1988. All of the five AES candidates use
> some kind of rotation, including Rijndael's ShiftRow operation.
> However, for what it's worth, it should be noted that Twofish can be
> implemented as a "straight Feistel cipher plus a final permutation,
> with rotations applied only within the round function, not in the
> Feistel XOR path.=20
>=20
> The authors of Twofish were unaware of these patents until recently,
> but the notion that such a broad claim could be valid seems quite
> ludicrous. he following well-known pieces of prior art would seem to
> at least dramatically limit the scope (if not completely invalidate)
> any such claims.
>=20
> 1) FEAL (1987) uses a rotation in its round function.
>=20
> 2) Madryga (1984) uses a variable rotation in its round function.
>=20
> 3) DES (1977) uses a rotation in each round of its key schedule.
>=20
> 4) DES (1977) uses a bit permutation (of which rotations are a
> special case) in every round.
>=20
> 5) GOST (1989) applies a bit permutation (that is a rotation) in
> each round after performing its S-box lookup
>=20
> 6) The very words "rotor" and encryption have been linked for a long
> time (e.g., the Caesar cipher, and Enigma)
>=20
> The concept of rotation in encryption was clearly neither novel nor
> unobvious at time these patents were filed. The fact is that EVERY
> microprocessor opcode has been considered for use in encryption, with
> rotation being just one example.
>=20
> This particular example is a counter to the "IP attack" argument
> espoused by some as a reason to select multiple AES algorithms instead
> of a single one. It is most likely that IP attacks, if any, will be
> based on very broad and ambiguous claims (like those of Hitachi) that
> the patent holder attempts to apply to all encryption systems.
>=20
> Niels Ferguson
> Bruce Schneier
> David Wagner
> Doug Whiting
> **********************************************************************
> Bruce Schneier, Counterpane Internet Security, Inc. Phone: =
612-823-1098
> 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
> Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Notes on the "Vortex" block cipher
Date: Sun, 14 May 2000 16:37:03 GMT
On Sun, 14 May 2000 14:34:26 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote:
>I noted in the F function there is a very simple compression of four 16
>bit values given
>
>F(a, b, c, d) = ((a ^ b) + c) ^ d -> a'
>
>Then only a' is passed thru the sboxes.... Wouldn't it be possbible to
>create a quadruple so that the input difference is fixed?
All the non-linearity is in the carry bit. If this is a straight
Feistel network with this round function, you're going to need a LOT
of rounds to be secure.
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Notes on the "Vortex" block cipher
Date: Sun, 14 May 2000 09:28:44 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:8fmdhi$ftu$[EMAIL PROTECTED]...
> I noted in the F function there is a very simple compression of four 16
> bit values given
>
> F(a, b, c, d) = ((a ^ b) + c) ^ d -> a'
>
> Then only a' is passed thru the sboxes.... Wouldn't it be possbible to
> create a quadruple so that the input difference is fixed?
Do a differential that flips an even number of the high bits of a, b, c, d.
Then, a' will be the same with probability 1. I haven't looked at the
cipher to see if this can be exploited.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Encryption of graphics by transposition
Date: Sun, 14 May 2000 09:54:26 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Bailey) wrote:
> 1) Are graphics encrypted with conventional encryption vulnerable to
> attacks different from (and possibly easier than) text encrypted with
> the same techniques?
> 2) If raster location transposition was used would graphic encryption
> be stronger?
If groupsize is small, a pattern of ciphertext may exhibit some picture
qualities if encrypted with a routine block algorithm. This clearly shows
a flaw of the same algorithms, including some of the most popular
ones...get the picture?
Certainly, features of really stong algorithms do not have this problem,
and traces of images need not be whitewashed if they are not there to
begin with. I'm not saying that graphics encryption is the end, but it
does show weaknesses in many algorithms that lots of folks have refused to
focus on, prefering that if not seen by myopic analysis, they are not
there.
--
Secrets that are told or availabe are not secrets anymore, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Encryption of graphics by transposition
Date: Sun, 14 May 2000 17:26:25 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (John Bailey) wrote:
>
> > 1) Are graphics encrypted with conventional encryption vulnerable to
> > attacks different from (and possibly easier than) text encrypted
with
> > the same techniques?
> > 2) If raster location transposition was used would graphic
encryption
> > be stronger?
>
> If groupsize is small, a pattern of ciphertext may exhibit some
picture
> qualities if encrypted with a routine block algorithm. This clearly
shows
> a flaw of the same algorithms, including some of the most popular
> ones...get the picture?
>
> Certainly, features of really stong algorithms do not have this
problem,
> and traces of images need not be whitewashed if they are not there to
> begin with. I'm not saying that graphics encryption is the end, but
it
> does show weaknesses in many algorithms that lots of folks have
refused to
> focus on, prefering that if not seen by myopic analysis, they are not
> there.
This makes no sense whatsoever. Try encrypting a two-color image with
Blowfish and tell me when you see the Mona Lisa.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Nemo psj)
Subject: Hello All Mathamatics Question
Date: 14 May 2000 18:59:02 GMT
Im in search of some good books that could help me out in my crypto ventures,
if any of you have any suggestions as to books on number theory ect. Please
let me know :)
Thanx very much
-Pure
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: About Hardware RNG
Date: 14 May 2000 14:59:32 EDT
In article <8fmhqq$kib$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom St Denis) wrote:
>
>In article <kezT4.357$[EMAIL PROTECTED]>,
> "Steve and Darla Wells" <[EMAIL PROTECTED]> wrote:
>> Although such circuits generate entropy, they typically generate
>detectable
>> weaknesses through either interference coupling and/or bias with the
>> environment. Be sure to post process the result well.
>
>The device I am building will feed the output to a data pin on a AVR
>2313, which will hash it (using MD2). I currently have it set to hash
>256 bytes downto 16 bytes before outputting.
>
>The device will be the size of a wallet and have a simple RS-232
>interface. A tiny TTY host in the AVR will allow the users to
>request 'x' amount of bytes, afterwhich the device will go to sleep
>mode.
>
>I hope to build a prototype this week (I want to make an AVR eval
>board, and just stick the RNG device on it).
Your use of a hash implies that you expect the output to a data pin on
the AVR 2313 to be less than perfectly random. Would you care to list
what kind of biases you expect and how severe you expect them to be?
------------------------------
From: [EMAIL PROTECTED]
Subject: Notes on the Pikachu cipher
Date: Sun, 14 May 2000 19:15:39 GMT
sci.crypt,
See the cipher at
http://www.wizard.net/~echo/pikachu.txt
The Pikachu cipher has been submitted to the cipher contest. No attack
have been shown so far although David Wagner had a near miss.
I have not been able to attack the full cipher. I wan to show my
various lines of attack.
The linear layer takes four bytes a,b,c,d and produces four bytes
a',b',c',d'
a' = 2a+ b + c + d
b' = 2a+ 2b +2c + d
c' = a+ b + 2c + d
d' = 2a+ b + 2c + 2d
Given two input a,b,c,d and c,b,a,d only the a and c output will
change. In a differential sense, we get (j,0,j,0)->(x,0,y,0). This is
called a truncated or partial differential because only some of the
bytes are predictable.
The next step is a pass through four different sboxes. It is possible
to get (x,0,y,0) -> (m,0,m,0). The probablity varies over the sboxes
but is around 2^-9.
What we have to hope for in the next round, is that the two keys and
the rotation take the differential (m,0,m,0)-> (a,b,c,d) ^ (c,b,a,d) so
that the pattern will repeat. The actual numbers need not be the same
in this round for a,b,c,d just the equalities.
The best chance I could find was about 2^-16, though. Only a four
round attack can be mounted with such a differential.
This is all quite similar to Mr. Wagner's attack but is a generalized
truncated differential.
Good work, Tom St Denis.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Notes on the "Vortex" block cipher
Date: Sun, 14 May 2000 19:38:03 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bruce Schneier) wrote:
> On Sun, 14 May 2000 14:34:26 GMT, Tom St Denis <[EMAIL PROTECTED]>
> wrote:
> >F(a, b, c, d) = ((a ^ b) + c) ^ d -> a'
> >
>
> All the non-linearity is in the carry bit. If this is a straight
> Feistel network with this round function, you're going to need a LOT
> of rounds to be secure.
>
> Bruce
> **********************************************************************
> Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-
1098
> 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
> Free crypto newsletter. See: http://www.counterpane.com
>
sci.crypt,
The cipher contest must be taking off if we can get the likes of Mr.
Schneier to comment! We need Eli Biham, Ron Rivest and Lars Knudsen
next :-)
Mr. Schneier,
The above quote was only part of the round function. The entire
function uses another s-box sub and a linear transform. The carry bit
helps but it by no means the extent of the non-linearity.
Here is some relevant code from the Vortex reference edition.
KeyXOR(plainLeft,keyStruct->roundKeys[keyCount]); // XOR in the round
key
...
MixWords(&cipherText); // the blow fish like transform with sbox
PHT(&cipherText); // from Twofish a= a+b b= 2a+b
Permute(&cipherText); // a linear mix
PHT(&cipherText);
Permute(&cipherText);
PHT(&cipherText);
Substitution(&cipherText); // The Rijndael s-box
...
SwapHalves(&plainLeft,&plainRight);
I invite you to take a closer look at the Vortex cipher at
http://www.wizard.net/~echo/crypto-contest.html
I would personally like to thank you for writing Applied Cryptography.
That book has opened up a whole new world for me. My copy is falling
apart from over use.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: AES Comment: the Hitachi patent
Date: Sun, 14 May 2000 21:59:45 +0200
Bruce Schneier wrote:
> The concept of rotation in encryption was clearly neither novel nor
> unobvious at time these patents were filed. The fact is that EVERY
> microprocessor opcode has been considered for use in encryption, with
> rotation being just one example.
I suppose it would be desirable if all AES submitters could joint effort
to create a precedence case to nullify patents that have been granted
undeservedly, thus improving the future practices of the patent offices
in GENERAL. On the other hand, crypto academics should in future
provide good 'examples' themselves to desist from applying patents
(use GNU's copyleft etc. instead).
M. K. Shen
===============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Abid Farooqui <[EMAIL PROTECTED]>
Subject: Re: Question regarding authentication implementation
Date: Sun, 14 May 2000 19:59:34 GMT
==============073948C3BE1E2E3CA843A562
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear Anne and Lynn Wheeler,
Although I appreciate your comments but my scenario is that my company is
touting this solution to be completely RSA algorithm based and following the
traditional PKI methodologies. Where you are coming from seems to be another
standard (using AADS and incorporating it within the traditional PKI method).
>From one of your own refs I quote:
"1.1 Background
A public-key digital certificate (hereinafter "certificate") binds a
public-key value to a set of information that identifies the entity
associated with the use of the corresponding private key. In a typical
transaction, some form of electronic document or transaction is
created and then digitally signed with the entity's private key. Then
the electronic document, the digital signature and a copy of the
certificate are combined together. It was possible to verify the
validity of the digital signature by referring to the contents of the
accompanying certificate."
My colleague is certainly not doing this because when the certificate queue is
loaded, he strips off everything from the certificate and only the public key
is loaded and hence there is little chance that he is verifying the validity
of the digital signature by referring to the contents of the accompanying
certificate as he does not actually have the whole certificate loaded into the
queue, only the public keys.
Also keep in mind that we are selling this product and claiming that it uses
CADS model (Certificate Authority Digital Signature model) and not AADS
(Account Authority Digital Signature model) whose draft I believe is submitted
to IEEE by First Data Corp and I am not sure of the status of the draft at
this point. Anyway my question remains, is my colleagues practices and logic
in accordance with the traditional PKI practices and procedures (CADS model).
If not then I have to raise a red flag.
Any input in this regard is appreciated.
Sincerely,
Abid Farooqui
Anne & Lynn Wheeler wrote:
> Abid Farooqui <[EMAIL PROTECTED]> writes:
> > A colleague of mine has developed using BSAFE libraries a security
> > application that does authentication at connection startup and
> > encryption when data is transferred. The client certificates, Root
> > certificates and client or partner certificates are stored in so called
> > queue. When you load a client/partner certificate you can VERIFY that
> > certificate against a list of available CA Root certificates that you
> > already have in the queue. This is a completely separate step and is
> > done in a non-active manner, meaning this happens way before the
> > client/partner is establishing any kind of connection to you.
> > Now, that you have a clinet/partner certificate loaded into a queue ...
> > when the client/partner establishes connection to you, he/she will send
> > a NONCE(Dummy message) signed with his/her private key to prove his
> > identity to you. When you receive the NONCE, you can try and decrypt it
> > using this partner's Public Key that you have already loaded into the
> > queue, if it decrypts etc. etc. then it must be the partner because only
>
> note that a certificate queue can be viewed as an account database ...
> and the public key and the associated id information represents an
> account record.
>
> if this information is pre-loaded ... then there is no need to
> transfer certificate(s) as part of each transaction.
>
> a simple version of this was demonstrated at PC/EXPO a couple years
> ago as "AADS" Radius ... i.e. Radius upgraded so that public key was
> registered in the Radius id database ... and a signed transaction
> (containing userid, time, & a couple other pieces) ... in place of
> userid/password sequence.
>
> the pre-loading can even be done w/o certificates of any kind ... in
> the Radius case ... basically substitute the password registration
> process with a public key registration process. it has the advantage
> of eliminating shared-secret ... vis-a-vis existing userid/passwords.
>
> misc. references:
>
> http://www.garlic.com/~lynn/aadsm3.htm#kiss3
> http://www.garlic.com/~lynn/2000b.html#14
> http://www.garlic.com/~lynn/draft-wheeler-ipki-aads-01.txt
>
> --
> Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
> http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
==============073948C3BE1E2E3CA843A562
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Dear Anne and Lynn Wheeler,
<br>Although I appreciate your comments but my scenario is that my company
is touting this solution to be completely RSA algorithm based and following
the traditional PKI methodologies. Where you are coming from seems to be
another standard (using AADS and incorporating it within the traditional
PKI method).
<br>From one of your own refs I quote:
<br>"1.1 Background
<p>A public-key digital certificate (hereinafter "certificate") binds a
<br>public-key value to a set of information that identifies the entity
<br>associated with the use of the corresponding private key. In a typical
<br>transaction, some form of electronic document or transaction is
<br>created and then digitally signed with the entity's private key. <b>Then</b>
<br><b>the electronic document, the digital signature and a copy of the</b>
<br><b>certificate are combined together. It was possible to verify the</b>
<br><b>validity of the digital signature by referring to the contents of
the</b>
<br><b>accompanying certificate.</b>"
<p>My colleague is <i>certainly not doing this because when the certificate
queue is loaded, he strips off everything from the certificate and only
the public key is loaded and hence there is little chance that he is verifying
the validity of the digital signature by referring to the contents of the
accompanying certificate as he does not actually have the whole certificate
loaded into the queue, only the public keys</i>.
<br>Also keep in mind that we are selling this product and claiming that
it uses CADS model (Certificate Authority Digital Signature model) and
not AADS (Account Authority Digital Signature model) whose draft I believe
is submitted to IEEE by First Data Corp and I am not sure of the status
of the draft at this point. Anyway my question remains, is my colleagues
practices and logic in accordance with the traditional PKI practices and
procedures (CADS model). If not then I have to raise a red flag.
<br>Any input in this regard is appreciated.
<br>Sincerely,
<br>Abid Farooqui
<p>Anne & Lynn Wheeler wrote:
<blockquote TYPE=CITE>Abid Farooqui <[EMAIL PROTECTED]> writes:
<br>> A colleague of mine has developed using BSAFE libraries a security
<br>> application that does authentication at connection startup and
<br>> encryption when data is transferred. The client certificates, Root
<br>> certificates and client or partner certificates are stored in so
called
<br>> queue. When you load a client/partner certificate you can VERIFY
that
<br>> certificate against a list of available CA Root certificates that
you
<br>> already have in the queue. This is a completely separate step and
is
<br>> done in a non-active manner, meaning this happens way before the
<br>> client/partner is establishing any kind of connection to you.
<br>> Now, that you have a clinet/partner certificate loaded into a queue
...
<br>> when the client/partner establishes connection to you, he/she will
send
<br>> a NONCE(Dummy message) signed with his/her private key to prove his
<br>> identity to you. When you receive the NONCE, you can try and decrypt
it
<br>> using this partner's Public Key that you have already loaded into
the
<br>> queue, if it decrypts etc. etc. then it must be the partner because
only
<p>note that a certificate queue can be viewed as an account database ...
<br>and the public key and the associated id information represents an
<br>account record.
<p>if this information is pre-loaded ... then there is no need to
<br>transfer certificate(s) as part of each transaction.
<p>a simple version of this was demonstrated at PC/EXPO a couple years
<br>ago as "AADS" Radius ... i.e. Radius upgraded so that public key was
<br>registered in the Radius id database ... and a signed transaction
<br>(containing userid, time, & a couple other pieces) ... in place
of
<br>userid/password sequence.
<p>the pre-loading can even be done w/o certificates of any kind ... in
<br>the Radius case ... basically substitute the password registration
<br>process with a public key registration process. it has the advantage
<br>of eliminating shared-secret ... vis-a-vis existing userid/passwords.
<p>misc. references:
<p><a
href="http://www.garlic.com/~lynn/aadsm3.htm#kiss3">http://www.garlic.com/~lynn/aadsm3.htm#kiss3</a>
<br><a
href="http://www.garlic.com/~lynn/2000b.html#14">http://www.garlic.com/~lynn/2000b.html#14</a>
<br><a
href="http://www.garlic.com/~lynn/draft-wheeler-ipki-aads-01.txt">http://www.garlic.com/~lynn/draft-wheeler-ipki-aads-01.txt</a>
<p>--
<br>Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
<br> <a href="http://www.garlic.com/~lynn/">http://www.garlic.com/~lynn/</a>
<a href="http://www.adcomsys.net/lynn/">http://www.adcomsys.net/lynn/</a></blockquote>
</html>
==============073948C3BE1E2E3CA843A562==
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Notes on the Pikachu cipher
Date: Sun, 14 May 2000 19:48:38 GMT
In article <8fmu0g$rj$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> sci.crypt,
>
> See the cipher at
> http://www.wizard.net/~echo/pikachu.txt
>
> The Pikachu cipher has been submitted to the cipher contest. No
attack
> have been shown so far although David Wagner had a near miss.
>
> I have not been able to attack the full cipher. I wan to show my
> various lines of attack.
>
> The linear layer takes four bytes a,b,c,d and produces four bytes
> a',b',c',d'
>
> a' = 2a+ b + c + d
> b' = 2a+ 2b +2c + d
> c' = a+ b + 2c + d
> d' = 2a+ b + 2c + 2d
>
> Given two input a,b,c,d and c,b,a,d only the a and c output will
> change. In a differential sense, we get (j,0,j,0)->(x,0,y,0). This
is
> called a truncated or partial differential because only some of the
> bytes are predictable.
> The next step is a pass through four different sboxes. It is possible
> to get (x,0,y,0) -> (m,0,m,0). The probablity varies over the sboxes
> but is around 2^-9.
>
> What we have to hope for in the next round, is that the two keys and
> the rotation take the differential (m,0,m,0)-> (a,b,c,d) ^ (c,b,a,d)
so
> that the pattern will repeat. The actual numbers need not be the same
> in this round for a,b,c,d just the equalities.
>
> The best chance I could find was about 2^-16, though. Only a four
> round attack can be mounted with such a differential.
How would you setup this attack? You start with
(a, b, c, d) where 'a = c' and 'b = c = 0'?
> This is all quite similar to Mr. Wagner's attack but is a generalized
> truncated differential.
>
> Good work, Tom St Denis.
Thanks, can you explain your attack a bit more. I don't doubt it
works, I just want to learn *how* it works. What are the steps for the
attack?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Hello All Mathamatics Question
Date: Sun, 14 May 2000 19:52:41 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Nemo psj) wrote:
> Im in search of some good books that could help me out in my crypto
ventures,
> if any of you have any suggestions as to books on number theory ect.
Please
> let me know :)
>
> Thanx very much
> -Pure
>
Try Applied Cryptography and "The Handbook of Applied Cryptography".
Both cool books.
You can get the latter off the net for free (somewhere...)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Notes on the "Vortex" block cipher
Date: Sun, 14 May 2000 19:51:42 GMT
In article <8fmvaq$2h4$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> The cipher contest must be taking off if we can get the likes of Mr.
> Schneier to comment! We need Eli Biham, Ron Rivest and Lars Knudsen
> next :-)
True, but we have already had David comment and I regard him as a good
cryptographer as well.
> Mr. Schneier,
>
> The above quote was only part of the round function. The entire
> function uses another s-box sub and a linear transform. The carry bit
> helps but it by no means the extent of the non-linearity.
>
> Here is some relevant code from the Vortex reference edition.
>
> KeyXOR(plainLeft,keyStruct->roundKeys[keyCount]); // XOR in the round
> key
> ...
> MixWords(&cipherText); // the blow fish like transform with sbox
> PHT(&cipherText); // from Twofish a= a+b b= 2a+b
> Permute(&cipherText); // a linear mix
> PHT(&cipherText);
> Permute(&cipherText);
> PHT(&cipherText);
> Substitution(&cipherText); // The Rijndael s-box
> ...
> SwapHalves(&plainLeft,&plainRight);
>
> I invite you to take a closer look at the Vortex cipher at
> http://www.wizard.net/~echo/crypto-contest.html
I will certainly take a look as well :)
> I would personally like to thank you for writing Applied Cryptography.
> That book has opened up a whole new world for me. My copy is falling
> apart from over use.
Ditto for me. Should get free replacement copies... :)
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
******************************
