Cryptography-Digest Digest #341, Volume #14 Sat, 12 May 01 11:13:01 EDT
Contents:
Re: Best encrypting algoritme (Mok-Kong Shen)
Re: DES Crypto Myth?? ("Tom St Denis")
Re: Is Differential Cryptanalysis practical? ("Tom St Denis")
Re: Quasi Functions, a way to design Maximum Secure Cipher (Mark Wooding)
Re: Encrypt/Decrypt, Digital Signature, Certificate authority, .. . . ("AY")
Re: __Security Architect/Consultant wanted at HONG KONG ("AY")
Re: __Security Architect/Consultant wanted at HONG KONG ("Tom St Denis")
Weakness in Noekeon? ("Tom St Denis")
Re: Information hiding in digital TV some thoughts and experiments. (Jan Panteltje)
Re: Micali-Schnorr pseudorandom bit generator ("Dobs")
Re: Micali-Schnorr pseudorandom bit generator ("Tom St Denis")
Key escrow based on BBS ("Tom St Denis")
how to blind a linear transform ("Tom St Denis")
Re: Security proof for Steak ("Henrick Hellstr�m")
Re: Is Differential Cryptanalysis practical? ([EMAIL PROTECTED])
Re: Is Differential Cryptanalysis practical? ("Tom St Denis")
Viewable PIcture Encryption ( Doug Goncz)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best encrypting algoritme
Date: Sat, 12 May 2001 11:03:37 +0200
wtshaw wrote:
>
> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
> >
> > It is also possible to consider the entire message as
> > a single block. Thus a strict distinction of stream and
> > block processing is only a conceptual aid in my humble
> > view and is not a necessity.
>
> Again, there is another option to block handling, not just fixed blocks
> and sometimes padding to fill one out, nor a single block for a big
> message, but variable length blocks to adapt to natural text divisions.
> Space terminated blocks are what I like.
[snip]
I agree. Block length is an essential parameter that
could be profitably varied. I believe that most block
algorithms can be modified to work well with variable
block sizes without much difficulty. Of course, that's
merely a belief of mine, no proof. The issue is somewhat
analogous to that of employing fixed vs. random S-boxes,
I suppose.
M. K. Shen
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: DES Crypto Myth??
Date: Sat, 12 May 2001 09:37:27 GMT
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
>
> I've been reading through papers on differential cryptanalysis and s-box
> generation and I seem to have uncovered a myth regarding DES that I've
> run across several times (i.e. _Applied Cryptography_, posts on this
> newsgroup, etc.).
>
> The myth is that the DES team knew about differential cryptanalysis (I
> think
> Coppersmith makes this claim) esp. iterative characteristics, and
> specifically
> designed the S-boxes to be resistant ("robust") to differential
> cryptanalysis.
> I've also read in several different places that the changes that the NSA
> made
> to the S-boxes were intended to increase their resistance to
> differential
> cryptanalysis.
>
>
> The problem with this "common crypto knowledge" is that the DES S-boxes
> aren't
> very robust! According to Seberry, Zhang, and Zheng in "Systematic
> Generation
> of Cryptographically Robust S-boxes" (1994) the robustness of the DES
> S-boxes
> range from 0.316 and 0.469 which is much lower than the upper bound of
> 0.861
> for 6x4 S-boxes.
>
> It seems to me that either the claim that the DES team knew about
> differential
> cryptanalysis isn't true, or they didn't understand it well enough to
> design
> S-boxes with close to optimal robustness.
>
> Am I missing something?
Actually for DES the sboxes they picked were about as good as you can use.
In general it's true you can pick more nonlinear less differential sboxes...
such as
const unsigned sbox[1][64] = {
{ 3, 1, 2, 5, 7, 6, 4, 12, 15, 11, 8, 10, 13, 9, 0, 14,
15, 7, 11, 3, 2, 13, 14, 8, 12, 5, 4, 10, 9, 0, 6, 1,
4, 14, 15, 10, 13, 8, 0, 3, 5, 11, 6, 2, 9, 12, 7, 1,
3, 14, 0, 13, 1, 10, 11, 9, 5, 15, 12, 6, 2, 8, 7, 4 } };
(lpmax is 10/64, dpmax is 12/64)
But this sbox would probably suck in DES since it doesn't follow the
required design.
So I would believe that they knew about the attacks.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Is Differential Cryptanalysis practical?
Date: Sat, 12 May 2001 09:41:42 GMT
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
>
> I read through the Biham and Shamir 1990 paper on "Differential
> Cryptanalysis
> of DES-like Cryptosystems". The technique is fascinating.
>
> However, when the technique was applied to 16-round DES, 2^57 plaintext
> pairs were required
> (plus huge counter arrays).
>
> A later paper by Biham and Shimir (1994) detailed an improved technique
> which could be implemented with 2^49 chosen ASCII plaintexts (and
> counter
> arrays eliminated).
>
> I think it's realistic to assume that the algorithm is known by the
> cryptanalyst.
> I think it is realistic to assume that the analyst has SOME chosen
> plaintexts
> with their corresponding ciphertexts (ye old "send it to the embassy"
> trick).
> I think its CRAP to assume that even an embassy is going to encrypt
> 2^(large # here)
> carefully chosen plaintext pairs for the analyst and I think its CRAP to
> assume that
> Joe PC User is going to encrypt 2^(small # here) carefully chosen
> plaintext
> pairs for the analyst (feel free to do whatever differential analysis
> you can
> with the commonly encrypted file headers).
>
> I'm not even sure that 2^49 chosen ASCII plaintexts is realistic.
>
> "Certifiable weakness"? Yes. Practical cryptanalysis technique? Er, help
> me out 'cause I don't see it. I've only been through two papers so there
> are probably improved techniques. Give me URLs, pointers to other
> papers...
>
> Maybe a probability of getting 2^(whatever) carefully chosen plaintexts
> encrypted should be calculated and included as part of the round
> probabilities
> (kidding, kidding).
Is this a joke post?
Look up their analysis of say FEAL, Knufu and various others.
It's true that for some ciphers diff analysis can in theory break it and in
practice not but for some ciphers the attack is devastating. FEAL for
example can be determined from random with (FEAL-6) only 4 chosen texts. It
can be broken upto quite a bit of rounds with what could be considered only
a handful of texts.
If we didn't know about these attacks than say RC5 with four rounds would be
secure, etc...
Tom
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Quasi Functions, a way to design Maximum Secure Cipher
Date: 12 May 2001 09:10:22 GMT
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
> Not quite. The top 8 bits of B0 are used to select the operation, and
> changing (for example) a + to a * can affect all 32 bits of B3. Yes, other
> than that, there's no downwards diffusion, and that can be controlled (see
> my differential).
Indeed. I realised that this morning, but you'd got there first. I've
not read your other article yet, but I've decided that there a number of
high-probability differentials anyway. I don't feel too bad about
having got this a bit wrong. ;-)
-- [mdw]
------------------------------
From: "AY" <[EMAIL PROTECTED]>
Crossposted-To: hk.comp,hk.comp.software
Subject: Re: Encrypt/Decrypt, Digital Signature, Certificate authority, .. . .
Date: Sat, 12 May 2001 11:58:26 +0100
Tom St Denis wrote in message ...
>Please stop posting in HTML here.
Also please stop prefixing your (kctang's) subjects with underscores or
similar.
For many newsreaders it wouldn't work anyway. It will only make your posts
look like spam a priori.
AY
------------------------------
From: "AY" <[EMAIL PROTECTED]>
Subject: Re: __Security Architect/Consultant wanted at HONG KONG
Date: Sat, 12 May 2001 12:08:27 +0100
>What the hell is IT?
http://www.everything2.com/index.pl?node=information+technology
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: __Security Architect/Consultant wanted at HONG KONG
Date: Sat, 12 May 2001 11:12:06 GMT
"AY" <[EMAIL PROTECTED]> wrote in message
news:9dj572$17l$[EMAIL PROTECTED]...
>
>
> >What the hell is IT?
>
> http://www.everything2.com/index.pl?node=information+technology
>
>
Funny stuff... actually a bit tragic..
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Weakness in Noekeon?
Date: Sat, 12 May 2001 11:17:57 GMT
I was trying my LTA on Noekeon (doesn't work since my LTA is a serial
analyzer.... enough of that).
Anyways in their Theta function they have
temp = a[0]^a[2];
temp ^= temp<<<8 ^ temp>>>8
a[1] ^= temp;
a[3] ^= temp;
mix the key
temp = a[1]^a[3];
temp ^= temp<<<8 ^ temp>>>8
a[0] ^= temp;
a[2] ^= temp;
(a[0..3] is the state of the cipher)
Where the last step is in fact invertible however, the first is not.
I am thinking of having output differences of two bits, specifically in a[0]
and a[2]. They should cancel out forming a 1R attack...?
The only real thing preventing this attack is the PI2 function right after
Gamma. If PI1/PI2 were removed the cipher would become very easy to attack.
Also from what I can tell the avalanche is not nearly as fast as Serpent or
my TC15...
Any comments?
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: [EMAIL PROTECTED] (Jan Panteltje)
Subject: Re: Information hiding in digital TV some thoughts and experiments.
Date: Sat, 12 May 2001 11:34:34 GMT
On a sunny day (Fri, 11 May 2001 12:29:26 GMT) it happened "Tom St Denis"
<[EMAIL PROTECTED]> wrote in
<GWQK6.64933$[EMAIL PROTECTED]>:
>
>Interesting. Isn't that similar to TV and the VLO (whatever it's called)
>the info between frames that is sent to give things like program names and
>early WebCast TV (down only)?
>
>Tom
Yes, vertical blanking interval (VBI), here it is used for 'teletext
(videotext) data services.
But you can even see that data as white lines and dots at the top of the
screen in your TV set, very popular in Europe, almost every TV has the
capability, it is s free service and used for news and weather, stock prices
etc 800 pages 25 lines of 40 characters with simple graphics even, each page
can have maybe up to 100? sub pages, so plenty of data space.
So it could be used.
Not even all lines in the VBI are used, some services were planned for
companies, but I think Internet killed that initiative.
The possibilities to do something with the digital transport stream are much
better though.
Analog over the air TV will be dead soon here, the digital system is much
more efficient and in most cases better quality too.
However the 'teletext' signal is still inserted in the digital stream by some
stations, the decoder then reinserts it in the analog output that you can
stick in your TV, so a TV with the teletext option can still be used.
The gist is that indeed anything you were doing to that stream, will also be
present in the digital transmission.
Regards
Jan
------------------------------
From: "Dobs" <[EMAIL PROTECTED]>
Subject: Re: Micali-Schnorr pseudorandom bit generator
Date: Sat, 12 May 2001 14:36:28 +0200
>
> If your modulus is n bits long, then you should be outputing at most
> log2(n) of the least significant bits of Yi. For a 1024 bit modulus,
> you should not be outputing more than log2(1024) or 10 bits at a time.
>
> Where did you get the idea that you could use 341 bits?
I took this algorithm from the 'Handbook of Applied Cryptography' by Menezes
In this algorithm (5.37) it is written that the output will be concatenation
of Z1||z2||...||zl
and Zi is the k least significant bits of Yi and k is always rather big
depending ofcourse on bithlength of n
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Micali-Schnorr pseudorandom bit generator
Date: Sat, 12 May 2001 12:49:08 GMT
"Dobs" <[EMAIL PROTECTED]> wrote in message news:9djb5s$ohr$[EMAIL PROTECTED]...
> >
> > If your modulus is n bits long, then you should be outputing at most
> > log2(n) of the least significant bits of Yi. For a 1024 bit modulus,
> > you should not be outputing more than log2(1024) or 10 bits at a time.
> >
> > Where did you get the idea that you could use 341 bits?
>
> I took this algorithm from the 'Handbook of Applied Cryptography' by
Menezes
> In this algorithm (5.37) it is written that the output will be
concatenation
> of Z1||z2||...||zl
> and Zi is the k least significant bits of Yi and k is always rather
big
> depending ofcourse on bithlength of n
>
I read it too. It must be wrong because I can't see anyone giving out that
many bits of the internal state and not getting zapped. Also it requires
your base to be rather large so I can't see it being faster than say BBS.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Key escrow based on BBS
Date: Sat, 12 May 2001 12:58:07 GMT
I was wondering after all the Key Escrow debackle in the mid 90s has anyone
suggested this trivial solution?
1. Host makes a blum integer N and publishes it along with a large prime p,
and primitive element in Z*p called g.
2. Each user picks their own large integer x (which is secret) and
publishes y = g^x mod p
Now I want to send a message to a user I do
1. Make a random k and compute y' = g^k mod p. I send y' to the user
2. I use K = y^k mod p, as my BBS seed.
3. I encode the message using the lower lg lg N bits xor'ed against the
plaintext. i.e K = K^2 mod N and use the lower bits of K
4. I perform another squaring e.g. K = K^2 mod N and store K along with the
stream.
Presuming that both factoring and discrete logs are hard with only g^k mod p
an attacker will not know the seed and with only the last K value an
attacker cannot find the square root of K modulo N.
The legitimate reader knows 'x' and can compute K from y' as y'^x mod p.
Thus they can read the message. The host however knows the factors of N and
can easily work it backwards and obviously read the message too. Voila
instant key escrow.
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: how to blind a linear transform
Date: Sat, 12 May 2001 13:34:23 GMT
At my work I have the job of analyzing a blinded linear transform. The idea
(don't laugh!) is to perform a linear transform in software such that an
attacker can examine the software but not see the transform.
Our trick is to make an addbox such that it works like this (the linear
transforms are in F_2 and are square and full rank)
The input is <a,b>
1. Perform a "unblinding" substitution getting a' = S1[a], b' = S2[b],
previously a and b were "blinded" via S1^-1 and S2^-1
2. Do the linear transform on a' and b' (i.e matrix multiply)
3. Add the result in GF(2) i.e c = M1a' + M2b'
4. Blind c, i.e c' = S3[c]
The output is c'.
My original analysis considered the inputs a,b to be normal (no blinding).
My attack then works on finding where c is zero and trying to figure out
which pairs of M1/M2 were the original matrix. I then simplified the attack
to say solve for rows of M1/M2 at a time and worry about their order
later... etc.. pretty demolished.
My question is how to attack this when the blinding is performed. I can't
for the love of myself figure out how, but I have a hunch it's not at all
that hard. Plus it would be fun to set this company back some since their
notion of "whitebox" crypto is kinda silly.
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Security proof for Steak
Date: Sat, 12 May 2001 16:01:50 +0200
"Benjamin Goldberg" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> Henrick Hellstr�m wrote:
> >
> > Have a look at http://www.streamsec.com/sattacks.asp
> >
> > It might be considered to be a draft so far. I would appreciate any
> > comments.
>
> I didn't look at the security proof, but did glance at the source code.
>
> My comments:
> I think more people can read C/C++ than delphi code. This is
> relatively trivial, as I can wade my way through it (I learned some
> pascal way back in high school), but you get negative brownie points for
> not having psuedocode or C/C++ source code available.
There is some pseudo code on the page http://www.streamsec.com/salgo.asp. I
can live with some "negative brownie points" for using Delphi instead of C.
There is almost a one-to-one correspondance between close to literal
interpretations from Delphi to C++, but the converse is not true (because of
the abscence of post/pre in/decrement and of operative assignments like ^=,
+= etc in Pascal). And well written Standard Pascal code looks pretty much
like pseudo code to begin with.
> Having any asm code in the reference implementation is a nono.
> If you want an optimized version, fine, but have it separate from the
> reference implementation (i.e., two versions). Some people [even highly
> experienced programmers] can't read asm. I'll admit that I wouldn't
> call myself *highly* experienced, but it takes me quite some effort to
> wade through asm.
True. It's already on my to-do list.
> Wtf are those big huge tables?
They are described on the page http://www.streamsec.com/mt.asp. I probably
ought to insert a link from the reference source code to that page.
The table in the source code is the expansion of a 32x32 linear bit matrix,
so that only four lookups will be needed for each 32 bit input (one for each
byte of the input). The design rationale for choosing that particular matrix
is purely empirical, but it might be re-created in a few steps:
a) Start with the 4x4 MDS matrix of TwoFish.
b) Apply a quadruple of s-boxes so that the matrix degenerates into a 32x32
invertible bit matrix over GF(2).
c) Transpose the rows and then the columns of the 32x32 matrix according to
a pair of constant permutations.
> How the bleep do I know that they
> aren't some sort of back door?
You don't. It is impossible to prove that there is no backdoor. But a
partial justification would be the fact that Steak uses random single cycle
s-boxes, and as far as my imagination goes it is impossible that any back
door into the linear matrix would be there for any internal key data and any
vector size. Basically, what I am saying is that there might be (small) sets
of weak keys, but not really any back door.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is Differential Cryptanalysis practical?
Date: Sat, 12 May 2001 05:21:10 -0800
Tom St Denis wrote:
>
> <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> >
> > I read through the Biham and Shamir 1990 paper on "Differential
> > Cryptanalysis
> > of DES-like Cryptosystems". The technique is fascinating.
> >
> > However, when the technique was applied to 16-round DES, 2^57 plaintext
> > pairs were required
> > (plus huge counter arrays).
> >
> > A later paper by Biham and Shimir (1994) detailed an improved technique
> > which could be implemented with 2^49 chosen ASCII plaintexts (and
> > counter
> > arrays eliminated).
> >
> > I think it's realistic to assume that the algorithm is known by the
> > cryptanalyst.
> > I think it is realistic to assume that the analyst has SOME chosen
> > plaintexts
> > with their corresponding ciphertexts (ye old "send it to the embassy"
> > trick).
> > I think its CRAP to assume that even an embassy is going to encrypt
> > 2^(large # here)
> > carefully chosen plaintext pairs for the analyst and I think its CRAP to
> > assume that
> > Joe PC User is going to encrypt 2^(small # here) carefully chosen
> > plaintext
> > pairs for the analyst (feel free to do whatever differential analysis
> > you can
> > with the commonly encrypted file headers).
> >
> > I'm not even sure that 2^49 chosen ASCII plaintexts is realistic.
> >
> > "Certifiable weakness"? Yes. Practical cryptanalysis technique? Er, help
> > me out 'cause I don't see it. I've only been through two papers so there
> > are probably improved techniques. Give me URLs, pointers to other
> > papers...
> >
> > Maybe a probability of getting 2^(whatever) carefully chosen plaintexts
> > encrypted should be calculated and included as part of the round
> > probabilities
> > (kidding, kidding).
>
> Is this a joke post?
Not a joke post (except for the last line). As I said, I was reading
through
both of those diff. anal. papers thinking "man, this is great" until I
got to the part about how much chosen plaintext it took to actually
work.
> Look up their analysis of say FEAL, Knufu and various others.
I'll do that. Thanks.
>
> It's true that for some ciphers diff analysis can in theory break it and in
> practice not but for some ciphers the attack is devastating. FEAL for
> example can be determined from random with (FEAL-6) only 4 chosen texts. It
> can be broken upto quite a bit of rounds with what could be considered only
> a handful of texts.
Diff. anal. seems to be effective on reduced round DES as well, but
again, that
isn't really a practical break. Even in their second paper Bih.&Sha.
discussed
the challenge of extending just one round - from 15 to the full 16-round
DES.
>
> If we didn't know about these attacks than say RC5 with four rounds would be
> secure, etc...
Just to reiterate in case I wasn't clear in my OP, I'm not questioning
the significance of diff. anal. and I'm not questioning the breaks, i.e.
the certifiable weakness of
the cipher to a diff. anal. attack. I am questioning practicality based
on the
TWO papers I described. Let me reword
the OP:
Cipher X can be broken by diff. analysis with 2^40 carefully chosen
plaintexts.
From my outsider-looking-in perspective, I can't possibly imagine
anyone, embassy or otherwise, encrypting that many plaintexts unawares,
so it appears that while the cipher is undoubtably "broken", the break
isn't practical. In other words, start looking for a better Cipher Y
but don't lose sleep at night unless you're willing to encrypt LARGE
amounts of carefully chosen plaintext pairs for your attacker. Can
anyone
point me to papers that describe full-round crypto algos being broken
with reasonable amounts of carefully chosen plaintext pairs
using diff. cryptanalysis?
=====BEGIN PGP MESSAGE=====
Version: PGP 6.5.8
pCxibgtG9gGHw3oOaZIu0w6iUz27izdTRvp0EdNSrMJ8La93oiygo6+eQtU4Tw==
=IZJ2
=====END PGP MESSAGE=====
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Is Differential Cryptanalysis practical?
Date: Sat, 12 May 2001 14:27:44 GMT
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> >
> > <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > >
> > > I read through the Biham and Shamir 1990 paper on "Differential
> > > Cryptanalysis
> > > of DES-like Cryptosystems". The technique is fascinating.
> > >
> > > However, when the technique was applied to 16-round DES, 2^57
plaintext
> > > pairs were required
> > > (plus huge counter arrays).
> > >
> > > A later paper by Biham and Shimir (1994) detailed an improved
technique
> > > which could be implemented with 2^49 chosen ASCII plaintexts (and
> > > counter
> > > arrays eliminated).
> > >
> > > I think it's realistic to assume that the algorithm is known by the
> > > cryptanalyst.
> > > I think it is realistic to assume that the analyst has SOME chosen
> > > plaintexts
> > > with their corresponding ciphertexts (ye old "send it to the embassy"
> > > trick).
> > > I think its CRAP to assume that even an embassy is going to encrypt
> > > 2^(large # here)
> > > carefully chosen plaintext pairs for the analyst and I think its CRAP
to
> > > assume that
> > > Joe PC User is going to encrypt 2^(small # here) carefully chosen
> > > plaintext
> > > pairs for the analyst (feel free to do whatever differential analysis
> > > you can
> > > with the commonly encrypted file headers).
> > >
> > > I'm not even sure that 2^49 chosen ASCII plaintexts is realistic.
> > >
> > > "Certifiable weakness"? Yes. Practical cryptanalysis technique? Er,
help
> > > me out 'cause I don't see it. I've only been through two papers so
there
> > > are probably improved techniques. Give me URLs, pointers to other
> > > papers...
> > >
> > > Maybe a probability of getting 2^(whatever) carefully chosen
plaintexts
> > > encrypted should be calculated and included as part of the round
> > > probabilities
> > > (kidding, kidding).
> >
> > Is this a joke post?
>
> Not a joke post (except for the last line). As I said, I was reading
> through
> both of those diff. anal. papers thinking "man, this is great" until I
> got to the part about how much chosen plaintext it took to actually
> work.
>
> > Look up their analysis of say FEAL, Knufu and various others.
>
> I'll do that. Thanks.
>
> >
> > It's true that for some ciphers diff analysis can in theory break it and
in
> > practice not but for some ciphers the attack is devastating. FEAL for
> > example can be determined from random with (FEAL-6) only 4 chosen texts.
It
> > can be broken upto quite a bit of rounds with what could be considered
only
> > a handful of texts.
>
> Diff. anal. seems to be effective on reduced round DES as well, but
> again, that
> isn't really a practical break. Even in their second paper Bih.&Sha.
> discussed
> the challenge of extending just one round - from 15 to the full 16-round
> DES.
Well it shows that it is possible to find the key faster. Yeah it's wholly
impractical but DES is not a perfect "56-bit" level function.
> >
> > If we didn't know about these attacks than say RC5 with four rounds
would be
> > secure, etc...
>
> Just to reiterate in case I wasn't clear in my OP, I'm not questioning
> the significance of diff. anal. and I'm not questioning the breaks, i.e.
> the certifiable weakness of
> the cipher to a diff. anal. attack. I am questioning practicality based
> on the
> TWO papers I described. Let me reword
> the OP:
> Cipher X can be broken by diff. analysis with 2^40 carefully chosen
> plaintexts.
> From my outsider-looking-in perspective, I can't possibly imagine
> anyone, embassy or otherwise, encrypting that many plaintexts unawares,
> so it appears that while the cipher is undoubtably "broken", the break
> isn't practical. In other words, start looking for a better Cipher Y
> but don't lose sleep at night unless you're willing to encrypt LARGE
> amounts of carefully chosen plaintext pairs for your attacker. Can
> anyone
> point me to papers that describe full-round crypto algos being broken
> with reasonable amounts of carefully chosen plaintext pairs
> using diff. cryptanalysis?
Yes you're right in this case it is not plausiable. A cipher is described
as broken if
"It can be detistinguished from a random permutation faster than sieving the
entire codebook"
This entails differential/linear distiniguishers that can be used to solve
for keys or just tell it from random.
For example, you can tell Blowfish from random with alot of texts but not
what the key is. In this sense Blowfish is broken.
Designers of new ciphers try to make ciphers that resist known attacks and
are thus unbroken.
Tom
------------------------------
From: [EMAIL PROTECTED] ( Doug Goncz )
Date: 12 May 2001 14:28:21 GMT
Subject: Viewable PIcture Encryption
I have prepared a Mathcad worksheet using a key with range 0...n-1, where n is
the number of pixels in a picture, to encrypt that picture. The cyphertext
picture is a picture with the same size as the original.
The requirement is that the edges of the picture must be even, that is, the
pixel count along both edges must be even, and otherwise coprime.
Without any substantial knowledge of image perception, I can state naively that
with knowledge of the plaintext picture, some resemblance is visible in the
cyphertext picture. A key of 0 produces the unencrypted plaintext. Mathcad can
verify that with a matrix equality, A==B=1, where == is Mathcad's boolean
equals.
I'd like to write this up in C++ but classes at the community college are full.
It's not too difficult to strip or pad pixels to produce the edge count
requirements.
Yours,
Doug Goncz
I'm an American experimental machinist:
I tolerance everything and tolerate everyone.
An email copy of your post is welcome.
Please reply to the group.
------------------------------
** 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
******************************
