Cryptography-Digest Digest #224, Volume #14 Tue, 24 Apr 01 14:13:00 EDT
Contents:
Re: OTP WAS BROKEN!!! (Ichinin)
Re: OTP breaking strategy (Ichinin)
node-to-node analysis vs. thread-type analysis ("Caleb Griffin")
Re: OTP WAS BROKEN!!! (Volker Hetzer)
Re: Security proof for Steak ("Tom St Denis")
Re: Security proof for Steak ("Henrick Hellström")
Re: Security proof for Steak ("Tom St Denis")
Re: Wolf's Secure Channel Theorem ("Mark G Wolf")
Scientists ask for free article archives ("Carpe Diem")
Re: C code for GF mults (Mike Rosing)
Re: counter intuative primes! (Bill Unruh)
Re: bogus speed claims (just wondering) (Mike Rosing)
Re: Censorship Threat at Information Hiding Workshop (Bill Unruh)
Re: OTP WAS BROKEN!!! (newbie)
Re: bogus speed claims (just wondering) ("Tom St Denis")
Re: 1024bit RSA keys. how safe are they? (Bill Unruh)
Re: Triple-DES vs. RC4 (Lassi =?iso-8859-1?Q?Hippel=E4inen?=)
Re: 1024bit RSA keys. how safe are they? ("Tom St Denis")
Re: Triple-DES vs. RC4 ("Tom St Denis")
Re: Security proof for Steak ("Henrick Hellström")
Re: Security proof for Steak ("Tom St Denis")
----------------------------------------------------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: OTP WAS BROKEN!!!
Date: Tue, 17 Apr 2001 22:51:05 +0200
newbie wrote:
<whatever>
Look, write a program that does this, if it manges to break an OTP > 128
bits more than 10 times in a row then i'll personally paint the moon
green!
Regards,
Ichinin
(...and people actually think that *I* am innoying - grrrmmmmblft!)
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: OTP breaking strategy
Date: Tue, 17 Apr 2001 22:57:38 +0200
Joseph Ashwood wrote:
<Snip>
Just a note:
There are smarter things one can do, some guy reverse engineered the RNG
of some electrical gambling machine in vegas, he implemented the thing
in a 6502 chip, hidden in his boot, then walked of with the cash.
Some other guy disassembled the slot machine when noone was looking,
making it caugh up the money.
/Ichinin
------------------------------
From: "Caleb Griffin" <[EMAIL PROTECTED]>
Subject: node-to-node analysis vs. thread-type analysis
Date: Tue, 24 Apr 2001 12:27:13 -0400
Would anyone be able to point me to an online reference that sufficiently
describes
the difference between these two types? node to node ... thread type
analysis
Thanks In Advance.
Caleb
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: OTP WAS BROKEN!!!
Date: Tue, 24 Apr 2001 18:44:52 +0200
Ichinin wrote:
>
> newbie wrote:
> <whatever>
>
> Look, write a program that does this, if it manges to break an OTP > 128
> bits more than 10 times in a row then i'll personally paint the moon
> green!
If you need someone to help you carrying the paint, send me an email.
Greetings!
Volker
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Security proof for Steak
Date: Tue, 24 Apr 2001 16:29:35 GMT
"Henrick Hellström" <[EMAIL PROTECTED]> wrote in message
news:9c4446$as8$[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
> news:HDfF6.44357$[EMAIL PROTECTED]...
> >
> > "Henrick Hellström" <[EMAIL PROTECTED]> wrote in message
> > news:9c3vtr$5id$[EMAIL PROTECTED]...
> > > "Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
> > > news:%MeF6.44155$[EMAIL PROTECTED]...
> > >
> > > > I wouldn't trust that design for one simple reason. It's too
> > complicated.
> > > > You think if RC4 was 100 lines long it would be so popular?
> > >
> > > There is no security proof of that magnitude for RC4, rather the
> opposite.
> > > And Steak is definetly less complicated than any secure block cipher I
> > know
> > > of, and, in fact, less complicated than most stream ciphers too.
> >
> > That's bullocks. Look at GOST, RC5 and Blowfish for example. They are
> all
> > trivially simple ciphers to implement.
>
> Maybe, bit firstly I wouldn't call 64-bit block ciphers secure, and
secondly
> the key stream function of Steak is actually just about as simple as far
as
> I can tell.
That's because you haven't done your homework. And why is a 64-bit cipher
insecure?
> The only complex part of the implementation of Steak is the initial key
set
> up, but that's because the initial key hashing is incorporated in the
> cipher, so that as much use as possible is made out of the 1 kilobyte
> maximum key size.
>
>
> > is your D sbox bijective?
>
> D is not really an s-box, but rather the composition of four s-boxes and a
> static invertible 32-bit matrix, in about the same way as e.g. the
software
> implementation of the s-boxes and the MDS function of TwoFish. Have a look
> at http://www.streamsec.com/mt.asp I even give you the inverse.
>
>
> > Long period != security.
> >
> > So what. a 128-bit LFSR has a huge period but it isn't secure either.
>
> Eh? You didn't understand the security proof, did you? ;-)
Whatever.... organize your crap into neater piles of crap.
Tom
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Security proof for Steak
Date: Tue, 24 Apr 2001 19:04:24 +0200
"Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
news:PRhF6.45456$[EMAIL PROTECTED]...
> > Maybe, bit firstly I wouldn't call 64-bit block ciphers secure, and
> secondly
> > the key stream function of Steak is actually just about as simple as far
> as
> > I can tell.
>
> That's because you haven't done your homework. And why is a 64-bit cipher
> insecure?
I was probably studying mathematics and computer science at the university
while you were still attending kindergarten. Why don't we stop insulting
each other and get serious.
The key stream function of Steak only adds a couple of additions and a
bitwise rotation to each round compared to the ciphers you mentioned. That's
even less than what TwoFish does.
And no, you're right, a 64 bit cipher is not necessarily insecure e.g. if
you use it as a combiner for an OTP key stream. Otherwise you would have to
deal with the expected 2**-32 collision rate. It is consequently not
recommended to use a 64-bit cipher as a MAC or in an authenticated mode. But
that's mostly a question of what security level you strive for. If you
settle for less than I do, that's fine by me.
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Security proof for Steak
Date: Tue, 24 Apr 2001 17:24:36 GMT
"Henrick Hellström" <[EMAIL PROTECTED]> wrote in message
news:9c4bo0$kbh$[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
> news:PRhF6.45456$[EMAIL PROTECTED]...
> > > Maybe, bit firstly I wouldn't call 64-bit block ciphers secure, and
> > secondly
> > > the key stream function of Steak is actually just about as simple as
far
> > as
> > > I can tell.
> >
> > That's because you haven't done your homework. And why is a 64-bit
cipher
> > insecure?
>
> I was probably studying mathematics and computer science at the university
> while you were still attending kindergarten. Why don't we stop insulting
> each other and get serious.
Probably so, but at least I know when to admit I am in need of some serious
academic kick arse. You obviously have some to learn about cryptography in
general. Just because you are math wiz doesn't mean your a cryptographer.
> The key stream function of Steak only adds a couple of additions and a
> bitwise rotation to each round compared to the ciphers you mentioned.
That's
> even less than what TwoFish does.
Wow. But your security still depends on your D box which you have yet to
mention any important chars about. Like is it a bijection, what is the
highest differential, linear approximation, etc..
> And no, you're right, a 64 bit cipher is not necessarily insecure e.g. if
> you use it as a combiner for an OTP key stream. Otherwise you would have
to
> deal with the expected 2**-32 collision rate. It is consequently not
> recommended to use a 64-bit cipher as a MAC or in an authenticated mode.
But
> that's mostly a question of what security level you strive for. If you
> settle for less than I do, that's fine by me.
Ok you keep believing that.
Tom
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Wolf's Secure Channel Theorem
Date: Tue, 24 Apr 2001 12:33:34 -0500
> This is incorrect since in that case you can remember everything which
was
> said and then learn the language ==> insecure.
Oh yeah, and who's going to teach you?
------------------------------
From: "Carpe Diem" <[EMAIL PROTECTED]>
Subject: Scientists ask for free article archives
Date: Tue, 24 Apr 2001 12:39:13 -0500
Sceintists threaten not to publish on journals that do not guarantee free
online access to their articles.
http://www.scientificamerican.com/explorations/2001/042301publish/
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: C code for GF mults
Date: Tue, 24 Apr 2001 12:32:48 -0500
Brian Gladman wrote:
> > Thanks for the explanation, I see how it doubles now. How do you connect
> > complex numbers with finite fields? I just worked out GF(16) elements in
> > a GF(148) field by solving g^16 = g over GF(148). This is simple. But
> it's
>
> You mean GF(128) don't you?
OOPS! I meant GF(2^148). 148 = 37*4 so g^(2^4) = g^16 is a subfield.
> The relationship is a homomorphism between different representations of a
> cyclic group with 15 elements.
>
> GF(16) is a field in which the non-zero elements form a cyclic group with
> respect to multiplication (with subgroups or order 3 and 5). The 15'th roots
> of unity in the complex plane also form a cyclic group with respect to
> multiplication with the same structure. So a relationship can be
> established between generators in the two different group reprsentations
> that will map one of these groups onto the other.
So to generalize, GF(2^n) has subgroups of order d|2^n-1 and there is a
relationship between the (2^n-1)th roots of unity and each element in
GF(2^n). And we can assign the order of each element equally too (i.e.
if a root of unity has order d', then there must be an element in GF(2^n)
with order d').
Thanks!
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: counter intuative primes!
Date: 24 Apr 2001 17:44:52 GMT
In <[EMAIL PROTECTED]> Paul Rubin <[EMAIL PROTECTED]> writes:
>"Tom St Denis" <[EMAIL PROTECTED]> writes:
>> Then I thought, well if the number is of the form N = MK + 1 where K is the
>> product of all 16 first primes, then N can't possibly be divisible by any of
>> them. This is true but this method takes longer to make primes then the
>> naive method.
This is the famous proof that there is no largest prime. Since if there
were, then the number you just wrote would be a prime which is larger
than any of the primes.
However, given that there is no largest prime it is not at all clear
that this number is a prime. It is exponentially larger than the first
16 primes and thus there are loads of other primes which could divide
it.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: bogus speed claims (just wondering)
Date: Tue, 24 Apr 2001 12:46:42 -0500
Tom St Denis wrote:
>
> I am just wondering who verifies the speed claims done by authors in
> algorithm designs? I know a few algorithms (read anything by the counterpane
> team) are a bit off. I wrote a simple cipher that employs a four 8x32's as
> a round function and I get about 20 cycles per byte as compared to the 18.
> Also the Twofish speed is far off afaik. Also they claim RC5 is slower then
> Blowfish which is not true since my version of RC5 can encrypt at 14 cycles
> per byte (RC5 with 16 rounds) as compared to the 24 they list.
>
> What am I missing? I know they hand optimize their asm code but if they
> compare them against other designs shouldn't they hand optimize those too?
Welcome to the wonderful world of sales. There's hidden assumptions and
different processors hand code differently too. RISC systems will take more
clock cycles than some CISC systems because they don't have fancy addressing
ability, other times CISC systems are slower because it takes more clocks to
do the same task. Get their code and count cycles to see where they come
from - maybe you've got a mistake, maybe they do.
> Also on some smart cards I have to wonder. Rijndael is claimed to encrypt
> at 4500 cycles per block on an 8051. That seems quite far fetched IMHO
> since the 8051 is not the best for indexing tables etc (you can use MOVC and
> MOVX but they take the acc and an extra 16-bit register DPTR). Most of the
> time afaik in the designs i have done is taken addressing tables and
> fetching/storing bytes.
>
> Do people "optimisticazize" their results or are they just better coders
> than myself and my friends? (The latter of which is possible but I doubt it
> consider one of my friends has tons of experience in embedded software
> development).
Estimates can be based on small chunks of code to see the basic operations,
then you just multiply up by numbers of rounds. If they forgot about saving
data inbetween basic operations, and that adds 10% more per round, then things
could be off a bit. 10% off isn't bad, but a factor of 4 would be. I would
think the code is available someplace, you should be able to compare your
efforts with some academic somewhere in the world. If not, then you've got
something to publish :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Censorship Threat at Information Hiding Workshop
Date: 24 Apr 2001 17:54:21 GMT
In <[EMAIL PROTECTED]> "Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
>David A Molnar wrote:
>> Can we agree that Felten et. al. are not pirates?
>Sure, they weren't the one I was replying to.
>The real crime is not cracking the copy protection scheme.
>My point was that it is *also* not in using a copy protection scheme.
>Rather, the real problem here is the theft of content that started
>the chain of developments.
It is not theft. Theft is depriving someone of some good. Copying is
leaving that person with that good, and making another one. The use of
emmotive and totally inappropriate terms like theft usually indicates a
attempt to circumvent thought by emotion.
Copyright is an agreement that the gov;t will grant a monopoly in return
for publication on the theory that this will encourage publication. That
theory requires examination, and in particular in most cases the
copyright laws protect not the producer but some third party who had
nothing to do with the production of the goods. Copyright protection
should be only as strong as is necessary to encourage production, no
stronger. It is now far far stronger. To use another emotive argument,
the Soviet Union's economy was based on the granting of monopoly powers
to companies on a theory that this would create a far more efficient
distribution of goods than the anarchy of capitalism, and would make the
individuals life far richer. Great theory. To bad reality did not live
up to it. I think copyright theory is in the same situation.
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: OTP WAS BROKEN!!!
Date: Tue, 24 Apr 2001 13:49:19 -0300
I'm just trying to present ideas.
Do not forget that I'm newbie.
I'm just to exploit extra-information and other tricks to try to reduce
the number of possibilities.
I tried selecting by degree of randomness.
I tried by introducing the "context" factor to select.
I tried by simulating re-susing the key.
All did not work.
Only guessing what the sender wrote, using extra-information, could
work.
This option has no sense.
My objective is to find a way to give to some messages more weight than
others.
I'm still thinking even if I KNOW THAT ALL MESSAGES ARE VALID.
C= P Xor k = P' Xor k' = P" Xor k" etc.....
I know that.
I'm trying to find some trick to isolate a defined group of P's or K's
to solve the problem.
I'm looking if some specific properties of k or P could help me.
I have a text and random sequence.
How to distinguish between the two.
That is the core of the problem.
Volker Hetzer wrote:
>
> newbie wrote:
> > THE NUMBER OF MESSAGES WHICH HAVE A SENSE IS INFINITESIMAL COMPARING TO
> > THOSE WHICH DOES NOT HAVE A SENSE!!!!!!!!!!!!!!!!!!!
> One can be more specific. The number of messages that makes sense, given
> a certain context and OTP encrypted message is *exactly* the number of messages
> that make sense given a certain context and the size of the OTP encrypted
> message.
> There's no way to narrow it down further.
> Might I remind you that you've been given three simple chaellenges and
> have not taken up even one? Not even stated what's wrong with the challenges?
>
> Greetings!
> Volker
> --
> They laughed at Galileo. They laughed at Copernicus. They laughed at
> Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: bogus speed claims (just wondering)
Date: Tue, 24 Apr 2001 17:55:34 GMT
"Mike Rosing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> >
> > I am just wondering who verifies the speed claims done by authors in
> > algorithm designs? I know a few algorithms (read anything by the
counterpane
> > team) are a bit off. I wrote a simple cipher that employs a four 8x32's
as
> > a round function and I get about 20 cycles per byte as compared to the
18.
> > Also the Twofish speed is far off afaik. Also they claim RC5 is slower
then
> > Blowfish which is not true since my version of RC5 can encrypt at 14
cycles
> > per byte (RC5 with 16 rounds) as compared to the 24 they list.
> >
> > What am I missing? I know they hand optimize their asm code but if they
> > compare them against other designs shouldn't they hand optimize those
too?
>
> Welcome to the wonderful world of sales. There's hidden assumptions and
> different processors hand code differently too. RISC systems will take
more
> clock cycles than some CISC systems because they don't have fancy
addressing
> ability, other times CISC systems are slower because it takes more clocks
to
> do the same task. Get their code and count cycles to see where they come
> from - maybe you've got a mistake, maybe they do.
>
> > Also on some smart cards I have to wonder. Rijndael is claimed to
encrypt
> > at 4500 cycles per block on an 8051. That seems quite far fetched IMHO
> > since the 8051 is not the best for indexing tables etc (you can use MOVC
and
> > MOVX but they take the acc and an extra 16-bit register DPTR). Most of
the
> > time afaik in the designs i have done is taken addressing tables and
> > fetching/storing bytes.
> >
> > Do people "optimisticazize" their results or are they just better coders
> > than myself and my friends? (The latter of which is possible but I
doubt it
> > consider one of my friends has tons of experience in embedded software
> > development).
>
> Estimates can be based on small chunks of code to see the basic
operations,
> then you just multiply up by numbers of rounds. If they forgot about
saving
> data inbetween basic operations, and that adds 10% more per round, then
things
> could be off a bit. 10% off isn't bad, but a factor of 4 would be. I
would
> think the code is available someplace, you should be able to compare your
> efforts with some academic somewhere in the world. If not, then you've
got
> something to publish :-)
I don't want to attacker their reputation directly since well I have no
standing to say so. I am just pointing out that all too often claims seem a
bit far fetched. For example you look at CS-Cipher and he claims you can
implement it in 500 bytes at 20kbits/sec, but there is a 256 byte table and
you need separate code for the mixing function (CS-Cipher is like SAFER). I
seriously doubt he implemented that in 500 bytes unless he did tricks like
"fixed keys" and "no decrypt routine"...
....
Tom
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: 1024bit RSA keys. how safe are they?
Date: 24 Apr 2001 17:56:19 GMT
In <9c0956$ph0$[EMAIL PROTECTED]> "George T." <[EMAIL PROTECTED]> writes:
]Does anyone has idea how safe RSA 1024 bit keys are? Are they safe enough to
]be used for encrypting credit card information, travelling over the internet
]and or residing on servers (email) for more than 24 hours.
]If no, what encrypting method would be sufficient?
Who is your enemy? Waht resources can they bring to bear? Are there
other means of attack which would be far simpler than cracking the
encryption? Are your keys properly protected? etc.
------------------------------
From: Lassi =?iso-8859-1?Q?Hippel=E4inen?= <[EMAIL PROTECTED]>
Subject: Re: Triple-DES vs. RC4
Date: Tue, 24 Apr 2001 17:52:00 GMT
Mark Wooding wrote:
>
> Michael Schmidt <[EMAIL PROTECTED]> wrote:
<...>
> > Furthermore, how is the licensing situation for RC4, when used
> > commercially outside the US? Schneier writes in Applied Cryptography
> > that RSA would give you a hard time if you try to use it unlicensed,
> > although there's no legal ground to that.
>
> I've not seen this happen to anyone yet. Consider that RC4 is used,
> unlicensed, in just about every web server running Apache with SSL
> support. A fuss would have been kicked up if RSA had tried to do
> anything.
IIRC, the problem is in the name. RC4 belongs to RSA. But if you call it
ARCFOUR, for example, there's no trouble.
-- Lassi
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: 1024bit RSA keys. how safe are they?
Date: Tue, 24 Apr 2001 17:58:06 GMT
"Bill Unruh" <[EMAIL PROTECTED]> wrote in message
news:9c4eo3$7n8$[EMAIL PROTECTED]...
> In <9c0956$ph0$[EMAIL PROTECTED]> "George T."
<[EMAIL PROTECTED]> writes:
>
> ]Does anyone has idea how safe RSA 1024 bit keys are? Are they safe enough
to
> ]be used for encrypting credit card information, travelling over the
internet
> ]and or residing on servers (email) for more than 24 hours.
>
> ]If no, what encrypting method would be sufficient?
>
>
> Who is your enemy? Waht resources can they bring to bear? Are there
> other means of attack which would be far simpler than cracking the
> encryption? Are your keys properly protected? etc.
These are the questions I asked him two days ago.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Triple-DES vs. RC4
Date: Tue, 24 Apr 2001 17:58:35 GMT
"Lassi Hippeläinen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Mark Wooding wrote:
> >
> > Michael Schmidt <[EMAIL PROTECTED]> wrote:
> <...>
> > > Furthermore, how is the licensing situation for RC4, when used
> > > commercially outside the US? Schneier writes in Applied Cryptography
> > > that RSA would give you a hard time if you try to use it unlicensed,
> > > although there's no legal ground to that.
> >
> > I've not seen this happen to anyone yet. Consider that RC4 is used,
> > unlicensed, in just about every web server running Apache with SSL
> > support. A fuss would have been kicked up if RSA had tried to do
> > anything.
>
> IIRC, the problem is in the name. RC4 belongs to RSA. But if you call it
> ARCFOUR, for example, there's no trouble.
Or if you ain't a yankee you can use RC4 all you want (and RC5 and RC6....).
Tom
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Security proof for Steak
Date: Tue, 24 Apr 2001 19:59:14 +0200
"Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
news:oFiF6.45874$[EMAIL PROTECTED]...
> Wow. But your security still depends on your D box which you have yet to
> mention any important chars about. Like is it a bijection, what is the
> highest differential, linear approximation, etc..
It's actually well documented at our homepage.Yes, as I've said before in
this thread, the D box is a bijection. Unless there is some flaw to the
security proof, or if you happen to choose to use it in a conventional block
cipher (you shouldn't because it's not designed for that), the linear
approximation could not be exploited anyway.
What does matter are the differentials. The security proof is more or less
based on the assumption that the D boxes are such that four iterations of
the round function brings you down to an absolute zero advantage for any
two-query distinguisher. A major reason for this is that the s-boxes for any
practical purpose might be modelled as random single cycle permutations. (In
fact, they really are random single cycle permutations if you use Steak with
a sufficiently large key.)
If you want to know more about the the D boxes, you could actually make some
testing yourself in O(2**32) time, e.g. by calculating the code book for the
MT-matrix. Any differential will obviously be reflected in the code book.
I'm sorry to say that we don't have 16 GB of memory at the web site, so we
couldn't make all of the test results available for download. ;-) You will
however find the matrix as an 32x32-bit matrix, as an 32-dword vector, and
as an 4x256-dword matrix at the homepage. I even appended the inverse of the
matrix a couple of months back.
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Security proof for Steak
Date: Tue, 24 Apr 2001 18:06:58 GMT
"Henrick Hellström" <[EMAIL PROTECTED]> wrote in message
news:9c4evm$ose$[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
> news:oFiF6.45874$[EMAIL PROTECTED]...
> > Wow. But your security still depends on your D box which you have yet
to
> > mention any important chars about. Like is it a bijection, what is the
> > highest differential, linear approximation, etc..
>
>
> It's actually well documented at our homepage.Yes, as I've said before in
> this thread, the D box is a bijection. Unless there is some flaw to the
> security proof, or if you happen to choose to use it in a conventional
block
> cipher (you shouldn't because it's not designed for that), the linear
> approximation could not be exploited anyway.
>
> What does matter are the differentials. The security proof is more or less
> based on the assumption that the D boxes are such that four iterations of
> the round function brings you down to an absolute zero advantage for any
> two-query distinguisher. A major reason for this is that the s-boxes for
any
> practical purpose might be modelled as random single cycle permutations.
(In
> fact, they really are random single cycle permutations if you use Steak
with
> a sufficiently large key.)
>
> If you want to know more about the the D boxes, you could actually make
some
> testing yourself in O(2**32) time, e.g. by calculating the code book for
the
> MT-matrix. Any differential will obviously be reflected in the code book.
> I'm sorry to say that we don't have 16 GB of memory at the web site, so we
> couldn't make all of the test results available for download. ;-) You will
> however find the matrix as an 32x32-bit matrix, as an 32-dword vector, and
> as an 4x256-dword matrix at the homepage. I even appended the inverse of
the
> matrix a couple of months back.
Ah so you do four 8x8 sboxes then a 32x32 linear transform? What about any
truncated differentials. Is your transform MDS?
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
******************************
