Cryptography-Digest Digest #841, Volume #13 Thu, 8 Mar 01 23:13:01 EST
Contents:
Re: One-time Pad really unbreakable? ("Douglas A. Gwyn")
Re: OT: The Big Breach (book) available for download ("Sam Simpson")
Re: One-time Pad really unbreakable? ("Mxsmanic")
Re: PKI and Non-repudiation practicalities (Anne & Lynn Wheeler)
Re: One-time Pad really unbreakable? (John Joseph Trammell)
Re: The Foolish Dozen or so in This News Group (Benjamin Goldberg)
Re: qrpff-New DVD decryption code (Bill Unruh)
Re: Cipher idea (Benjamin Goldberg)
library or function for file encryption ("������")
Re: frequency "flattening" ("Brian McKeever")
Re: Super-strong crypto......................(As if). (Benjamin Goldberg)
Re: Problem with BBS implementation (Benjamin Goldberg)
Re: Question re Asymmetric Encr'n (Benjamin Goldberg)
Re: Encryption software (Benjamin Goldberg)
Re: frequency "flattening" (John Savard)
Re: Question re Asymmetric Encr'n (John Savard)
Re: Question re Asymmetric Encr'n (John Savard)
DES in software and hardware ("Lovecraftesque")
Re: Really simple stream cipher ("Scott Fluhrer")
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Thu, 8 Mar 2001 23:28:23 GMT
> > ... like saying that repulsive gravity exists.
"Trevor L. Jackson, III" wrote:
> Funny you should mention that. It seems we need _some_ explanation of why
> the expansion of the Universe might be accelerating. Note that we already
> have one fundamental force that changes sign based on distance. Perhaps
> gravity has a large scale structure we are barely able to detect today.
> Einstein's "worst mistake" may prove to be prophetic.
This is getting way off topic.. The so-called "expansion of the
universe"
is not directly observed but is inferred from a long chain of theory and
deduction involving many hypotheses and assumptions. Just over the
course
of my lifetime, the suggested rate of expansion (and perforce the
higher-
order derivatives) has fluctuated drastically, even changing sign.
As to Einstein's self-proclaimed biggest blunder", he meant the *reason*
he had used to introducing the cosmological term, not necessarily the
term
itself. That term (with non-zero constant) arises naturally in several
other derivations of the field equations, and leads to a deSitter space
for the cosmological background, which appeals to some particle
theorists.
Nobody should think that the current consensus in physics, especially
cosmology, is very close to the truth.
> As for the provability of quantum randomness, do you believe in the original
> proof of that the fine structure constant is 136? How do you feel about the
> experimental evidence that the value is 137 and the revised proof?
I assume you mean Eddington's theory (culminating in Fundamental
Theory).
The revision amounted to a renormalization, today a well accepted
notion.
Eddington's theory was certainly speculative well beyond what could be
supported by available evidence, verging on crackpot, and was never
widely
accepted by working physicists.
In contrast, the irreducible nature of quantum randomness has been well
established by experiment and theory. It's not due merely a lack of
more
detailed knowledge of the state of the system.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,alt.security.scramdisk,comp.security.pgp.discuss
Subject: Re: OT: The Big Breach (book) available for download
Date: Fri, 9 Mar 2001 00:04:25 -0000
I've just tried and it works fine (if a little slow).
--
Regards,
Sam
http://www.scramdisk.clara.net/
Patton Echols <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I have been trying to DL the pdf or pdf.zip file and had no luck. I get
> about 100k into the download and then it stalls. Has anyone had success
> with this? I'm sure it's not my connection, the 1.2m zip file should
> only take a few minutes over DSL.
>
>
> Sam Simpson wrote:
> >
> > The book Big Breach (by R.Tomlinson, ex-MI6) is available for download
at
> > the URLs below.....It's caused a lot of controversy in England, so is
> > probably worth a read ;)
> >
> > Just so happens to have been released a week after I ordered my copy :(
> >
> > --
> > Regards,
> >
> > Sam
> > http://www.scramdisk.clara.net/
> >
> > Acrobat PDF
> > Zipped - http://thebigbreach.com/download/bbpdf.zip
> > Unzipped - http://thebigbreach.com/download/bbpdf.pdf
> >
> > MS Word
> > Zipped - http://thebigbreach.com/download/bbword.zip
> > Unzipped - http://thebigbreach.com/download/bbword.doc
> >
> > Text
> > Zipped - http://thebigbreach.com/download/bbtxt.zip
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Fri, 09 Mar 2001 00:09:15 GMT
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> As for the provability of quantum randomness,
> do you believe in the original proof of that
> the fine structure constant is 136? How do
> you feel about the experimental evidence that
> the value is 137 and the revised proof?
I'm not familiar with either of them.
To what extent do you believe that quantum mechanics accurately reflects
reality? In particularly, do you believe that radioactive decay is
truly random or not, and why?
------------------------------
Subject: Re: PKI and Non-repudiation practicalities
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Fri, 09 Mar 2001 00:23:32 GMT
Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes:
> in the "shared-secret" scenerios ... the "shared-secret" are
> registered someplace and are subject to harvesting ... aka effectively
> credit card numbers are treated as "shared-secrets" (witness all the
> stuff written about protecting master credit-card databases at
> merchant servers). Harvesting of master database files of
> shared-secrets is significantly simpler than defeating tamper-evident
> and/or beating somebody with rubber hose.
note that CC# harvesting can also be an insider activity
Large Criminal Hacker Attack on Windows NT E-Banking and E-Commerce
Sites
3:00 PM EST, Thursday, March 8, 2001
In the largest criminal Internet attack to date, a group of Eastern European
hackers has spent a year systematically exploiting known Windows NT
vulnerabilities to steal customer data. More than a million credit cards have
been taken and more than 40 sites have been victimized.
The FBI and Secret Service are taking the unprecedented step of releasing
detailed forensic information from ongoing investigations because of the
importance of the attacks.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: [EMAIL PROTECTED] (John Joseph Trammell)
Subject: Re: One-time Pad really unbreakable?
Date: Fri, 09 Mar 2001 00:26:51 GMT
On Thu, 08 Mar 2001 20:35:09 GMT, Trevor L. Jackson, III wrote:
[snip]
> As for the provability of quantum randomness, do you believe in the original
> proof of that the fine structure constant is 136? How do you feel about the
> experimental evidence that the value is 137 and the revised proof?
The value of the fine structure constant is only approximately
1/137 -- note the inversion, and not exact by any means.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Fri, 09 Mar 2001 01:01:18 GMT
Anthony Stephen Szopa wrote:
>
> Troed wrote:
> >
> > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> >
> > >This is a personal use program for windows. I think it is fair to
> > >say this program is for and intended for a non multitasking
> > >environment.
> >
> > It's for Windows 3.x only? Windows 95 and up are pre-emptive
> > multitasking - or what are you talking about?
> >
> > >Take a look at my floppy disk test results I just posted. They
> > >seem to cramp everything pretty much all the detractors have been
> > >saying.
> >
> > Floppy != Harddrive
> >
> > ___/
> > _/ - Software Engineer working in the development of operating
> > systems
>
> You should not have other programs running at the same time as you
> are running the OverWrite program that will be making demands on the
> system such that the overwrites to the hard drive will be delayed by
> competition from these other programs for system resources. You
> don't want to be running multiple tasks or programs while the
> OverWrite program is running if at all possible.
If your algorithm is designed properly, that should not make a
difference.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: alt.hackers.malicious
Subject: Re: qrpff-New DVD decryption code
Date: 9 Mar 2001 01:17:31 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (John Savard)
writes:
]On 8 Mar 2001 14:01:47 -0000, Mach <[EMAIL PROTECTED]> wrote, in
]part:
]But it *does* prevent you from taking the material on the disc, and
]converting or distributing it in other formats. So, one can't compress
]it more and distribute it on the Internet, one can't edit the DVD to
]remove region coding, one can't convert it to a Video CD, one can't
]digitally capture images, and so on, without breaking the encryption.
WEll, of course one can actually do all those things, since in order to
play, the DVD has to be decrypted and a digital stream sent to whereever
it is being displayed. That is, with some work, capturable. Since there
exist decoders for Windows, one can hack those to capture the full
stream.
]Thus, it does provide _partial_ assistance in controlling the
]intellectual property on the DVD.
very partial.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Cipher idea
Date: Fri, 09 Mar 2001 02:02:34 GMT
Hmm. The key schedule in my proposed cipher:
when 0 <= i < 16: k(i) = userkey(i)
when 16 <= i < 512: k(i) = k(i-1)^k(i-4)^k(i-15)^k(i-16)
seems absurdly weak. The polynomial used isn't even dense!
Can't anyone suggest even a related key attack on my cipher?
Also... how would I go about calculating the maximum strength of the
algorithm, assuming that it's not broken in the 128 bit version?
IIRC, DES, with the normal number of rounds, but completely independent
round keys, can be broken in approximately 2^58 work, with the best
known attacks.
Somehow, I suspect that my cipher has less than 4096 bits of security if
the round keys are fully independent (call it a gut feeling:), but how
do I find how much security there is?
Is getting 192 or 256 bits of security as easy, as trivial, as changing
to an order 24 or 32 primitive polynomial in the key schedule, and using
a larger key? AES, when using a larger key, uses more rounds; should I?
As to attacks....
I know that with rounds reduced to one:
There are a number of attacks, one of which is, if you take two
plaintexts which differ in only one byte, encipher then both, and take
alternate bytes from each ciphertext, deciphering this composite will
yield a plaintext which is almost identical to the first two, differing
in only two bytes (the one that was changed between the original pair of
plaintexts, and one other besides that one).
I suspect that with rounds reduced two, there's a meet-in-the-middle
attack.
With rounds reduced to three, I can't find any attacks.
Also, with any number of rounds, in the last round, the last bytepair
mixes are trivially removed by the attacker. Does this introduce any
exploitable weaknesses?
I know that my inability to find an attack doesn't mean that one doesn't
exist.
Somebody help me!
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: "������" <[EMAIL PROTECTED]>
Subject: library or function for file encryption
Date: Fri, 9 Mar 2001 11:09:04 +0900
Hi all.
I want to encrypt text files and after saving to read these files with
decryption.
I use C language in linux.
I am trying to make the program with this functionality, but I don't know
which library or function to use.
If you have any emample file or artical to refer, recommend me.
Thank you.
------------------------------
From: "Brian McKeever" <[EMAIL PROTECTED]>
Subject: Re: frequency "flattening"
Date: Thu, 8 Mar 2001 18:26:54 -0800
"Joe H. Acker" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Oops, forgot about that. Yes, indeed I am looking for the minimal
> solution regarding the length of CT, the algorithm should find the
> shortest CT such that the above requirements are fullfilled, but still
> Length(CT)>Length(PT) is allowed.
>
> My (often bad) intuition tells me that Huffman-Coding isn't what I'm
> looking for. So does anyone know how the algorithm to find the optimal
> code as above is called?
Well, I can tell you that Huffman will not do what you want, for the simple
reason that it has no knowledge about what your symbols look like (in terms
of "bit patterns") and so cannot possibly optimize the output for properties
of chunks whose length coincides with that length. Do you know what I mean?
Think of a huffman compressor as a dictionary from, say, characters, to
variable-length bit strings. But the abstract algorithm doesn't "know" that
there are 8 bits in a character, so you can't expect the output to have any
particular property when examined as an array of characters.
On the other hand, it's clear that there are "flattening functions" that
accomplish nothing, when looked at the right way. Let's say I have a
sequence of the symbols 0..F, and my output symbols are {w,x,y,z} (unequal
sizes, I know... stick with me). Then, because 4!=24>=16, I can encode
each original symbol as a permutation of 4 output symbols (eg 0->wxyz,
1->wxzy, etc). When I am done, the output sequence will have exactly the
same number of w's x's y's and z's. But I've done nothing, because if you
look at the output symbols in bigger chunks, the output distribution is
identical to the input distribution!
To rule out something like I just described, I think you have to understand
what you want on a more fundamental level, and then decide why simple
compression is not good enough for you.
Brian
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Super-strong crypto......................(As if).
Date: Fri, 09 Mar 2001 02:30:56 GMT
Keill_Randor wrote:
>
> The only way to have a secure encryption system, (and uncrackable), is
> to make sure that the only way to crack an encrypted peice of data -
> (or any other peice of information - (I just concentrate on
> computing)), is to run through every peice of data known to a computer
> - (Even the NSA won't be able to deal with that).
>
> I.e. the only secure system, is one that allows you to encrypt any
> peice of data (or stream), using any other peice / peices or stream /
> streams of data.
This is called the One-Time-Pad. You have a key that is just as long as
your data, you add your key to the data, and then destroy the key.
The recipient has the only other copy of the key, he subtracts the key
from the enciphered data, getting the original, and then destroys the
key.
A string of ciphertext can correspond to any plaintext, whatsoever, if,
and only if, every key is possible, and every possible key is equally
likely.
> (Like what mine does, but I don't think it's a good idea to post it,
> somehow..:). (I'm trying to deal with GCHQ, but they don't seem to
> want to know...(Idiots))). The word random shouldn't really be
> needed...
True OTP is a simple idea, and if it's what you're using, there's no
harm in posting it. If you are using something other than true one time
pad, for example generating the key stream from a small key using some
algorithm, you lose the proof of security -- regardless of whether or
not you post the algorithm!
The word random really is needed with true one time pad, since every
possible key of a given length must be equally likely, and it should be
quite impossible for anyone to predict any part of the key, no matter
how much they know, no matter how much computational power they have;
this is what random means.
As for the GCHQ, they're not idiots for not wanting to use the TOTP --
it requires an enormous amount of key material, which must be
transmitted securely. Also, like most stream ciphers, it has no built
in authentification, and it is vulnerable to bit flipping attacks.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Problem with BBS implementation
Date: Fri, 09 Mar 2001 02:41:37 GMT
Dobs wrote:
>
> ok thanks for answer, maybe U can also tell me where can I find a
> source code of such a large prime numbers generator which can I use in
> this program ::)))))))))))))
You can find a large integer package by using one of those nifty things
called "search engines." Yahoo and google and altavista and lots of
other search engines are out there, and you might even have a "search"
button somewhere on your browser.
Once you find a search engine, you should look for "arbitrary precision
integer" or "big integer library" or "large integer library"
Some librarys, which you might choose to search for by name, are gnu mp,
gmp, miracl, freelip. Also, look at the file
http://www.csc.fi/math_topics/Mail/FAQ/msg00015.html, which is old, but
has a lot of things mentioned. You might also consider posting a
question to the sci.math newsgroup, asking for a [current] list of large
integer packages.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Question re Asymmetric Encr'n
Date: Fri, 09 Mar 2001 03:12:08 GMT
Arnold Shore wrote:
>
> Thanks, guys - the responses are appreciated. But, re " ... choosing
> a random symmetric key to be used for CAST, and encrypting that using
> the ECC public-key crypto."
>
> How then is this symmetric key reconstituted at decrypt time, since
> only the public key is used?
>
> as
I'm not sure if this is the method used, but one method of using ECC is
the following:
The private key is a curve, C, and a large integer a.
The public key is the curve, C, and two points, P = a random point, and
Q = a*P.
When encrypting a message m, one picks a random number r, and the
enciphered message is (r*P, r*Q+m).
When decrypting, you calculate ((r*Q+m)-(a*(r*P))), and this gives you
your original message, m.
The curve defines what happens when you multiply a point by an integer.
You don't have to worry about it, except that it's needed by both the
public and private key.
Diffie-Helman/Elgamal encryption is similar, except we exponentiate by a
and r, rather than multiply. Point multiplication is rather similar to
integer exponentiation.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Encryption software
Date: Fri, 09 Mar 2001 03:25:11 GMT
Paul Pires wrote:
>
> Ben Cantrick <[EMAIL PROTECTED]> wrote in message
>news:985tq0$[EMAIL PROTECTED]...
[snip]
> > This is a biggie. A lot of people, time and work have gone into
> > making PGP what it is now. Anyone who claims they're better than PGP
> > all around is naive/stupid, lying, or a flippin' genius. You can
> > probably guess the radio of stupids and shysters to geniuses...
>
> I didn't understand this one when the OP said it and I don't
> understand now. No demonstratable or quantifiable proof is availiable
> for PGP.
The thing is, everything about PGP is open for examination including
(ESPECIALLY including) its source. You can examine the algorithms, you
can examine the source, your can see that there are no backdoors into
it. Of course, you have to trust the ciphers it uses, but that's
another story.
> How can another reasource be compared to it. Seems like it is a
> sideways step around the trust issue. "I only trust industry
> recognized approaches that have stood some test of time"
It's more like, "I only trust products which have withstood careful
examination by the experts."
> If some one says they are better, the response is "prove it"
> If someone says they are not better, the response is "why bother"
> Seems like the author should justify his existence without falling
> into the double bind of camparisons to current mile markers.
Well, yeah. Noone is likely to do any better than the PGP system any
time soon. They might, however, do better in terms of ciphers. The PGP
system can, with little difficulty, be made to use whatever cipher you
want. That's why noone intelligent says, X is better than pgp. They
might say, Y is better than AES, and Z is better than RSA or ECC.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: frequency "flattening"
Date: Fri, 09 Mar 2001 03:19:36 GMT
On Thu, 8 Mar 2001 16:55:29 +0100, [EMAIL PROTECTED] (Joe H. Acker)
wrote, in part:
>Aim: Find an optimal code C that maps any sign of PT to a sign or
>sequence of signs in CT (and vice versa), such that f_CT(x) = k is a
>constant value k for any arbitrary sign x of CT.
>Does Huffman-Coding does this? I'm not sure, so if not, how is this
>algorithm called and where can I find information about it?
Huffman coding does attempt to *approximate* this.
For example, if the signs in PT are the 26 letters, with their
frequencies as they are in English, a Huffman code will map, as
efficiently as possible for a simple substitution of letters into
strings of symbols in CT - the signs in CT will always be 0 and 1 -
the letters, so that f_CT(0) and f_CT(1) will be close to 50%. The
frequencies of longer strings built from 0 and 1 will also be made as
equal as possible for a code of this simple type.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Question re Asymmetric Encr'n
Date: Fri, 09 Mar 2001 03:23:17 GMT
On Wed, 7 Mar 2001 10:04:55 -0500, "Arnold Shore" <[EMAIL PROTECTED]>
wrote, in part:
>I'm using a product that's based on CAST-128 and Elliptic Curve
>implementation, and will appreciate information on how these work.
>Specifically, I see that given fixed values for a private key and cleartext,
>the encrypted output varies - but nonetheless decrypts correctly.
>How can this be? Apparently, there's some other input - how acquired?
>Will appreciate any reply, including a reference URL/text that might be
>suitable for the non-mathematician. Thanks, all.
Usually, products that combine a public key cryptosystem (Elliptic
Curve) and a block cipher (CAST-128) also attempt, using the time when
the program is run, and mouse clicks, and whatever, to generate some
"random" data.
This random data is used in conjunction with the public-key
cryptosystem to produce the "session key" which is used as the key of
the block cipher. In addition, the block cipher is usually used in a
mode, such as "cipher-block chaining" or CBC mode, which among other
things ensures that an identical plaintext with an identical key will
always be enciphered differently, that requires an additional random
quantity, called an "initialization vector".
My web site goes into further detail on this, and is designed to keep
the math at a minimum.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Question re Asymmetric Encr'n
Date: Fri, 09 Mar 2001 03:24:30 GMT
On Wed, 7 Mar 2001 17:54:43 -0500, "Arnold Shore" <[EMAIL PROTECTED]>
wrote, in part:
>How then is this symmetric key reconstituted at decrypt time, since only the
>public key is used?
Well, that's how public-key cryptography works. The encryptor only has
the public-key, and creates something that can't be read with just the
public key, but only the person with the private key can read it.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Lovecraftesque" <[EMAIL PROTECTED]>
Subject: DES in software and hardware
Date: Fri, 09 Mar 2001 03:35:42 GMT
I understand that hardware DES implementations are three orders of
magnitude faster than software ones (roughly speaking.) I wonder if
anybody can provide pointers to more precise data?
Also, what is usually the performance difference between C
implementations and hand-coded assembly language ones? I am aware that
there are many factors involved, like the type of platform and how good
each implementation is but, again, feedback on this would be welcome.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Thu, 8 Mar 2001 19:27:57 -0800
Henrick Hellstr�m <[EMAIL PROTECTED]> wrote in message
news:988qlv$m2b$[EMAIL PROTECTED]...
> "Scott Fluhrer" <[EMAIL PROTECTED]> skrev i meddelandet
> news:988e15$n78$[EMAIL PROTECTED]...
> > - Hence, by cycling through all 16 possibilities, the attacker can use
all
> > 16 settings to produce 16 possible "lsbits of message", and look at all
> 16,
> > and decide which looks the most likely. I claim that, for most
realistic
> > plaintexts, that such a determination should be simple.
>
> OK I went through the equations once more. The 16 possibilities does not
> produce 16 distinct plain text lsbit sequences. The combinations comes in
> pair, so there are only 8 distinct plain text lsbit sequences. More
> specifically, the lsbit of the high element in K doesn't influence the
> values of the plain text lsbits. It does however influence the values of
the
> second and higher bits.
>
> Unless I am mistaken this means that the value of the msbit of K doesn't
> have any impact on the plain text whatsoever.
It may have impact on the msbits of the plaintext.
>
> (Of course, these things might be even worse, because the attacker might
> learn a great deal about the plain text without even having to recover the
> key. I am just trying to prove a point. ;-))
>
>
> > - Once he has a good guess at the lsbits of V[0], V[1], K[0], K[1], he
can
> > start in on the 2 lsbits (and, given that he knows the lsbits, that's
only
> > 16 more possibilities), and continue in the obvious way.
> >
> >
> > This "you can attack key bits individually" property of the cipher
reduces
> > the effort from the obvious 2**(32*4) to 32 * 2**4 == 2**9. The random
> > updates of K really do not alter this property.
>
> Given what I stated above and Scott's assumption about the reliability of
> the plain text analysis, I guess the correct estimation of the effort
should
> be (2**4) + 30 * (4**4) + (2**4)*(2**3) = 7824. This presupposes that a
> definitive selection of the key bits at a given position always can be
done
> at the next position. I guess this is a reasonable assumption, provided
that
> the plain text is sufficiently long and diverse. Scott?
Well, that was my initial assumption. In addition, even if you couldn't
determine the exact bit setting for the first couple levels of lsbits, if
you could limit it to something reasonable (2-4 possibilities), the tree
should be small enough to search. Indeed, you could even start your search
with guessing the least significant byte for each possibility, and the
search should still be reasonably efficient...
>
> --
> Henrick Hellstr�m [EMAIL PROTECTED]
> StreamSec HB http://www.streamsec.com
>
>
------------------------------
** 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
******************************
