Cryptography-Digest Digest #838, Volume #13 Thu, 8 Mar 01 16:13:00 EST
Contents:
Q: Blakely-Shamir Secret Sharing -- problem with program ("G. Ralph Kuntz, MD")
Re: qrpff-New DVD decryption code (John Savard)
Re: One-time Pad really unbreakable? ("Mxsmanic")
Re: frequency "flattening" (Joe H. Acker)
Re: frequency "flattening" (Mok-Kong Shen)
Re: Really simple stream cipher ("Paul Pires")
Re: Q: Tempest Systems ("Douglas A. Gwyn")
arbitrary-precision arithmetic (Berton Allen Earnshaw)
Re: frequency "flattening" (Mok-Kong Shen)
Re: qrpff-New DVD decryption code ("Simon Johnson")
Re: frequency "flattening" (Joe H. Acker)
Re: One-time Pad really unbreakable? ("Trevor L. Jackson, III")
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: Really simple stream cipher ("Henrick Hellstr�m")
Re: Really simple stream cipher ("Henrick Hellstr�m")
----------------------------------------------------------------------------
From: "G. Ralph Kuntz, MD" <[EMAIL PROTECTED]>
Subject: Q: Blakely-Shamir Secret Sharing -- problem with program
Date: Thu, 08 Mar 2001 18:58:20 GMT
I was trying to play around with Blakely-Shamir Secret Sharing. I wrote
the following program in Java, but it gives different results each time
it is run (sometimes correct, sometimes not). I am probably doing
something wrong in my modulus calculations, but I can't figure out what.
Any ideas?
Thanks, Ralph
====================CUT HERE======================
import java.math.*;
import java.util.*;
public final class SecretSharing {
private static final int PRIME_SIZE = 128;
private static Random random = new Random();
private static BigInteger modulus;
private static BigInteger[] d = new BigInteger[6];
public static void encrypt() {
modulus = new BigInteger(PRIME_SIZE, 20, random);
//System.out.println("modulus: " + modulus);
final BigInteger secret = new BigInteger(PRIME_SIZE - 1, random);
final BigInteger a = new BigInteger(PRIME_SIZE - 1, random);
final BigInteger b = new BigInteger(PRIME_SIZE - 1, random);
System.out.println("secret: " + secret);
//System.out.println("a: " + a);
//System.out.println("b: " + b);
for (int i = 1; i < d.length; i++) {
final BigInteger i1 = a.multiply(BigInteger.valueOf(i));
final BigInteger i2 = b.multiply(BigInteger.valueOf(i * i));
d[i] = secret.add(i1).add(i2).mod(modulus);
//System.out.println("d[" + i + "]: " + d[i]);
}
}
public static void decrypt() {
int i1 = random.nextInt(d.length - 1) + 1;
i1 = 5;
//System.out.println("i1: " + i1);
int i2 = random.nextInt(d.length - 1) + 1;
while (i2 == i1)
i2 = random.nextInt(d.length - 1) + 1;
i2 = 3;
//System.out.println("i2: " + i2);
int i3 = random.nextInt(d.length - 1) + 1;
while (i3 == i1 || i3 == i2)
i3 = random.nextInt(d.length - 1) + 1;
i3 = 1;
//System.out.println("i3: " + i3);
System.out.println("(i2 * i3 * (i3 - i2))): "
+ (i2 * i3 * (i3 - i2)));
System.out.println("(i1 * i3 * (i1 - i3))): "
+ (i1 * i3 * (i1 - i3)));
System.out.println("(i1 * i2 * (i2 - i1))): "
+ (i1 * i2 * (i2 - i1)));
final BigInteger n1 =
d[i1].multiply(BigInteger.valueOf(i2 * i3 * (i3 - i2)));
final BigInteger n2 =
d[i2].multiply(BigInteger.valueOf(i1 * i3 * (i1 - i3)));
final BigInteger n3 =
d[i3].multiply(BigInteger.valueOf(i1 * i2 * (i2 - i1)));
final BigInteger den =
BigInteger.valueOf((i3 - i1) * (i1 - i2) * (i2 - i3));
System.out.println("den: " + den);
final BigInteger sec = n1.add(n2).add(n3).divide(den).mod(modulus);
System.out.println("sec: " + sec);
}
public static void main(final String[] args) {
for (int i = 0; i < 5; i++) {
encrypt();
//System.out.println("-------------");
decrypt();
System.out.println();
}
}
}
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: alt.hackers.malicious
Subject: Re: qrpff-New DVD decryption code
Date: Thu, 08 Mar 2001 18:32:44 GMT
On 8 Mar 2001 14:01:47 -0000, Mach <[EMAIL PROTECTED]> wrote, in
part:
>If DVD players already contain decryption code, why do we need
>decryption software?
>Does an encrypted DVD prevent people from copying it? At a
>hardware level, digital information is a series of ones and
>zeros, so, what keeps you from copying the ones and zeros of
>encrypted data?
It's true that the encryption doesn't prevent anyone from making an
exact copy of a DVD for playback on other DVD players.
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.
Thus, it does provide _partial_ assistance in controlling the
intellectual property on the DVD.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Thu, 08 Mar 2001 19:14:48 GMT
"Paul Crowley" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> We have many sources of random numbers that
> *seem* to be effective in *practical* terms, but
> none of them are *proven* effective the way
> the one-time-pad is *proven* effective.
My understanding is that the randomness of radioactive decay is
_proven_, not merely postulated, because it is an inevitable consequence
of quantum mechanics as that theory is now understood. Calling it
non-random would be like saying that repulsive gravity exists.
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: frequency "flattening"
Date: Thu, 8 Mar 2001 20:14:23 +0100
Neil Couture <[EMAIL PROTECTED]> wrote:
> mmm i think i see want you meant...
>
> CT == CypherText
> PT == PlainText.
>
> Normaly if the CypherText has been constructed well the frequency Distribution
>
> will be the same for all sign in CT. So Huffman code do not help you here...
> that is you won't be able to compress significaly your CT 'cos all the sign
> will
> have almost equals frequency distribution. ( that what Information Theory
> teach us )
>
> anyway you want to maps from PT so CT...
>
> I do not see an optimal way to do it and i think that by definition this (the
> mapping ) will not give you any information ( in case CT is a cypher text )
>
> but let's take a more general case. you could generate Huffman code for both
> sets and then just keep a simple map of them...
I'm afraid my naming convention was misleading. CT wasn't supposed to
mean ciphertext at all, it should just mean the result of the encoding
function C.
I'll describe informally what I'm looking for.
I'm looking for an algorithm that finds for a given input that consists
of signs of the alphabet A, an output such that the frequency of each
sign in the output is equal to each other sign of the output. The
frequency of the signs in the output should be equal for all signs. And
because there are infinitely many possible outputs that suffice this
condition, the algorithm should find the optimal (or at least a quite
optimal) encoding, meant in the way, that the result should be as short
as possible, but it's allowed that length(result)>length(input)
Here's a sample: Let alphabet A={a,b,c}. Let C be the desired encoding
function (of course, there must be an inverse decoding function as
well), let F_text(x) be a function that returns the frequency of sign x
(element of A) as it occurs in text, then the result result=C(text)
should have the following property:
F_result(a) = F_result(b) = F_result(c) = k
I just mentioned Huffman-Coding because I suspect that such an algorithm
can work similar to it, but its aim is not compression at all but to
"flatten" frequencies to a uniform distribution. In the sample, even if
the input would only contain a and b, the output should contain a,b,c
with equal frequency.
Will I have to work that out myself or is there such an algorithm?
Greetings,
Erich
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: frequency "flattening"
Date: Thu, 08 Mar 2001 20:16:22 +0100
"Joe H. Acker" wrote:
>
> We have n signs of alphabet A, e.g. let's suppose n=256. There's an
> arbitrary length plaintext PT composed of the alphabet. There's a
> function f_PT(x) that returns the frequency of x in PT.
>
> 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.
Your formulation isn't very clear and allows different
interpretations, I am afraid. What do you mean by mapping
a sign of PT to a sequence of signs in CT? Do you allow
homophones? What do you mean by optimality? Could you
illustrate with a tiny example, giving also the bit
representations? (The example need not be optimal,
of course.) Thanks.
M. K. Shen
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Thu, 8 Mar 2001 11:20:56 -0800
Henrick Hellstr�m <[EMAIL PROTECTED]> wrote in message
news:988e54$ak1$[EMAIL PROTECTED]...
> OK, here is an improvement. It requires an OTP, but it doesn't increase the
> bandwidth and is infinitely error propagating past a single cipher text
> error.
A freindly suggestion? Feel free to disagree. Being one of Pancho's recent
recipients of cryptanalytic wizzardry, I have set a personal rule. Don't post
a fix to a flaw for AT LEAST, 100 times longer than it takes you to figure out
the fix and re-write the code or two weeks, wichever is longer. Trust me, you
will profit from it. Scott is a good teacher and often leaves a part of the lesson
for the pupil to figure out.
Paul
>
> Consequently, the interesting question in this case is whether or not there
> is an attack against the error propagation. Is there a way to make it stop
> using multiple cipher text substitutions? Relevant assumptions are that the
> adversary is not the legitimate sender, that the adversary does not know
> V or OTP, and that V and OTP are not used more than once.
>
>
> "Henrick Hellstr�m" <[EMAIL PROTECTED]> skrev i meddelandet
> news:986t9e$7v4$[EMAIL PROTECTED]...
> >
> > Algo AEnc:
> >
> > Input qword V, K; dword P
> > Output qword V, dword C
> >
>
> 0. V[0] := V[0] rol 1; V[1] := V[1] rol 1
> > 1. V[1] := V[1] + V[0]
> > 2. V := V xor K
> > 3. C := P xor V[0]
> > 4. V[0] := V[1]; V[1] := C
> >
> >
> > Algo BEnc:
> >
> > Input qword V,K,P
> > Output qword V,C
> >
> > 1. AEnc(V,K,P[0],C[0])
> > 2. AEnc(V,K,P[1],C[1])
> >
> >
> > Algo CEnc:
> >
> > Input qword V,P; qword array OTP; integer Index
> > Output qword V,C
> >
>
> 0. K := OTP[Index]
> > 1. BEnc(V,K,P,C)
>
>
> Here is some Delphi test code for the cipher scaled down from qword size to
> byte size. TestErrorPropagation is (of course) a test of the error
> propagation past a single cipher text error. TestBruteForce performs a brute
> force known plain text attack and is always able to find values of K
> independently of the initial value of V and independently of the length of
> the message.
>
>
> function RolByte(Value: Byte): Byte;
> asm
> (* x86 assembler code. The two nibbles of Value are rotated separately. *)
> ROL AL,1
> MOV DL,AL
> AND AL,$EE
> AND DL,$11
> ROL DL,4
> OR AL,DL
> end;
>
> procedure KS8Enc(K: Byte; var V, T: Byte);
> type
> Nibble = 0..15;
> var
> V1, V0: Byte;
> C0, C1: Nibble;
> begin
> (* Encrypt first nibble: *)
> V0 := RolByte(V);
> V0 := (V0 and $F) +
> ((V0 + (V0 shr 4))) shl 4;
> V0 := V0 xor K;
> C0 := (T xor V0) and $F;
> V1 := RolByte((V0 shr 4) + (C0 shl 4));
>
> (* Encrypt second nibble: *)
> V1 := (V1 and $F) +
> ((V1 + (V1 shr 4))) shl 4;
> V1 := V1 xor K;
> C1 := ((T shr 4) xor V1) and $F;
> V := (V1 shr 4) + (C1 shl 4);
>
> T := C0 + (C1 shl 4);
> end;
>
> procedure KS8Dec(K: Byte; var V, T: Byte);
> type
> Nibble = 0..15;
> var
> V1, V0: Byte;
> P0, P1: Nibble;
>
> begin
> V0 := RolByte(V);
> V0 := (V0 and $F) +
> ((V0 + (V0 shr 4))) shl 4;
> V0 := V0 xor K;
> P0 := (T xor V0) and $F;
> V1 := RolByte((V0 shr 4) + ((T and $F) shl 4));
>
> V1 := (V1 and $F) +
> ((V1 + (V1 shr 4))) shl 4;
> V1 := V1 xor K;
> P1 := ((T shr 4) xor V1) and $F;
> V := (V1 shr 4) + (T and $F0);
> T := P0 + (P1 shl 4);
> end;
>
> procedure TestErrorPropagation;
> var
> K, V, V0, VE: Byte;
> B, C: Byte;
> I: Int64;
> begin
> Randomize;
> V0 := Random(256);
> V := V0;
> VE := V0;
>
> B := Random(256);
> C := B;
> KS8Enc(K,V,C);
> E := Random(15) + 1;
> Memo1.Lines.Add(Format('Error: %x',[E]));
> C := C xor E; KS8Dec(K,VE,C);
> I := 1;
> while I <= 512 do begin
> K := Random(256);
> B := Random(256);
> C := B;
> KS8Enc(K,V,C);
> KS8Dec(K,VE,C);
> if V = VE then begin
> Memo1.Lines.Add(Format('EP worn out at %d',[I]));
> Exit;
> end;
> Inc(I);
> end;
> Memo1.Lines.Add('Failure.');
> end;
>
> procedure TestBruteForce(Sender: TObject);
> const
> TextLen = $1000;
> var
> Po, I, J: Integer;
> OrgK, OrgV, K, V, pV, C, P: Byte;
> CT: string;
> OK: Boolean;
> begin
> Randomize;
> OrgV := Random(256);
> Memo1.Lines.Add(Format('---'#13#10'Actual V: %d'#13#10,[OrgV]));
>
> CT := '';
> V := OrgV;
> for Po := 1 to TextLen do begin
> K := Random(256);
> P := 0;
> C := P;
> KS8Enc(K,V,C);
> CT := CT + Char(C);
> end;
> for OrgV := 0 to 255 do begin
> pV := OrgV;
> for Po := 1 to TextLen do begin
> OK := False;
> for K := 0 to 255 do begin
> C := Byte(CT[Po]);
> V := pV;
> KS8Dec(K,V,C);
> if C = 0 then begin
> OK := True;
> Break;
> end;
> end;
> if not OK then Break;
> pV := V;
> end;
> if OK then
> Memo1.Lines.Add(Format('V: %d',[OrgV]));
> end;
> end;
>
>
>
> --
> Henrick Hellstr�m [EMAIL PROTECTED]
> StreamSec HB http://www.streamsec.com
>
>
>
>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Q: Tempest Systems
Date: Thu, 8 Mar 2001 18:06:59 GMT
Frank Gerlach wrote:
> ... NASA just uses a special (low-bit
> rate) encoding to communicate with that satellite.
It should be pointed out that in that application the
signal was engineered specifically for forward error
correction, unlike the vast majority of the signals
in common computers.
------------------------------
From: Berton Allen Earnshaw <[EMAIL PROTECTED]>
Subject: arbitrary-precision arithmetic
Date: 08 Mar 2001 12:23:58 -0700
Someone from comp.lang.c said that the following question might be better
answered here in sci.crypt:
What are the different arbitrary-precision arithmetic packages available?
Which seem to be the best?
--
Berton Earnshaw - [EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: frequency "flattening"
Date: Thu, 08 Mar 2001 20:44:24 +0100
"Joe H. Acker" wrote:
>
> I'm afraid my naming convention was misleading. CT wasn't supposed to
> mean ciphertext at all, it should just mean the result of the encoding
> function C.
>
> I'll describe informally what I'm looking for.
>
> I'm looking for an algorithm that finds for a given input that consists
> of signs of the alphabet A, an output such that the frequency of each
> sign in the output is equal to each other sign of the output. The
> frequency of the signs in the output should be equal for all signs. And
> because there are infinitely many possible outputs that suffice this
> condition, the algorithm should find the optimal (or at least a quite
> optimal) encoding, meant in the way, that the result should be as short
> as possible, but it's allowed that length(result)>length(input)
>
> Here's a sample: Let alphabet A={a,b,c}. Let C be the desired encoding
> function (of course, there must be an inverse decoding function as
> well), let F_text(x) be a function that returns the frequency of sign x
> (element of A) as it occurs in text, then the result result=C(text)
> should have the following property:
>
> F_result(a) = F_result(b) = F_result(c) = k
Suppose a, b and c have frequencies of 0.5, 0.25 and
0.25 respectively. If one maps a to r and s with equal
probability and maps b to t and c to u, then the output
signs r, s, t, u will have equal frequencies. Is that
what you want? But you have here a problem of precision.
If the values of the initial frequencies are not that
nice, the equality is only rough and you could get in
general better approximations to equality through mapping
each of a, b and c to a larger number of signs. The question
would be then at which stage you would be satisfied with a
certain approximation of equality of frequencies of output
signs. In the ideal case where one gets exact equality in
frequencies, the optimal code will be a block code for the
output signs, i.e. all signs have the same number of bits
(special case of Huffman codes). Does the above correspond
to what you mean by 'optimality' or do you want something
different?
M. K. Shen
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Crossposted-To: alt.hackers.malicious
Subject: Re: qrpff-New DVD decryption code
Date: Thu, 8 Mar 2001 20:01:37 -0800
Mach <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> > ramalane:
> >
> > CAMBRIDGE, Mass. -- Descrambling DVDs just got even easier, thanks to
a pair
> > of MIT programmers.
> >
> > Using only seven lines of Perl code, Keith Winstein and Marc Horowitz
have
> > created the shortest-yet method to remove the thin layer of encryption
that
> > is designed to prevent people -- including Linux users -- from
watching DVDs
> > without proper authorization.
> >
> >
> > http://www.wired.com/news/culture/0,1284,42259,00.html
> >
> > The Perl Code:
> > http://www.cs.cmu.edu/~dst/DeCSS/Gallery/qrpff-fast.pl
>
>
> You can also find anotated C source explaining the algorithm at
> http://www.cs.cmu.edu/~dst/DeCSS/Gallery
>
> If DVD players already contain decryption code, why do we need
> decryption software?
>
> Does an encrypted DVD prevent people from copying it? At a
> hardware level, digital information is a series of ones and
> zeros, so, what keeps you from copying the ones and zeros of
> encrypted data?
>
Guess what :)
There isn't anything stopping you.... :)
> _______________________________________________________________________
>
>
> Mach finger [EMAIL PROTECTED] for public key
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
>
> iQCVAwUBOqeNMidWgNvgbjuxAQFgBwP+Nej6/gpcsIBqOuBHdC9x0VFW+z9CdRG9
> NnPWQdSN+sQUiPGXePSyDUO1UQCXhsmCkXAFTiVUMiGJY7K8Tt44l58a2Dv162u3
> N4BXXmFWF7xGNDikMLtLBdeXtVRVkAebIkCwj9HMRZweW4RzA4YpZV11NVXA7VO4
> Pqih04wfO0w=
> =LQ64
> -----END PGP SIGNATURE-----
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: frequency "flattening"
Date: Thu, 8 Mar 2001 21:22:00 +0100
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > F_result(a) = F_result(b) = F_result(c) = k
>
> Suppose a, b and c have frequencies of 0.5, 0.25 and
> 0.25 respectively. If one maps a to r and s with equal
> probability and maps b to t and c to u, then the output
> signs r, s, t, u will have equal frequencies. Is that
> what you want?
That's exactly what I want. (Of course, I also want to be able to decode
the output to the original input.)
>But you have here a problem of precision.
> If the values of the initial frequencies are not that
> nice, the equality is only rough and you could get in
> general better approximations to equality through mapping
> each of a, b and c to a larger number of signs. The question
> would be then at which stage you would be satisfied with a
> certain approximation of equality of frequencies of output
> signs. In the ideal case where one gets exact equality in
> frequencies, the optimal code will be a block code for the
> output signs, i.e. all signs have the same number of bits
> (special case of Huffman codes). Does the above correspond
> to what you mean by 'optimality' or do you want something
> different?
I'm not sure if I understand you correctly. Does such a block code as a
special Huffman code ensure these two conditions:
1. all signs in the output have the same frequency
2. all signs of the alphabet A are in the output, regardless wether they
occur in the input or not
If yes, that's exactly what I'm looking for. Do you have any references
or links where I can look further for that?
The reason why I'm looking for that is because I believe that such an
encoding before encryption could strengthen the overall security of the
cipher. So instead of compressing, I'd like to "flatten out"
frequencies--I don't care wether the output is larger than the input,
but I want it to be as small as possible or at least rather small.
(Huffman coding isn't optimal as well, not in the general case.)
Regards,
Erich
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Thu, 08 Mar 2001 20:35:09 GMT
Mxsmanic wrote:
> "Paul Crowley" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > We have many sources of random numbers that
> > *seem* to be effective in *practical* terms, but
> > none of them are *proven* effective the way
> > the one-time-pad is *proven* effective.
>
> My understanding is that the randomness of radioactive decay is
> _proven_, not merely postulated, because it is an inevitable consequence
> of quantum mechanics as that theory is now understood. Calling it
> non-random would be like saying that repulsive gravity exists.
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.
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?
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Thu, 08 Mar 2001 12:36:26 -0800
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.
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Thu, 8 Mar 2001 21:38:47 +0100
"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.
(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?
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Thu, 8 Mar 2001 21:39:32 +0100
Oh, I fully agree. This wasn't just a flaw fix. Firstly, this was something
completely different. Secondly, this was actually closer to the original
idea - an idea I mentioned in the thread "One Time Authentication". I am
merely interested in exactly how little diffision is needed for PCFB
autentication to work.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
"Paul Pires" <[EMAIL PROTECTED]> skrev i meddelandet
news:v9Rp6.58742$[EMAIL PROTECTED]...
> A freindly suggestion? Feel free to disagree. Being one of Pancho's recent
> recipients of cryptanalytic wizzardry, I have set a personal rule. Don't
post
> a fix to a flaw for AT LEAST, 100 times longer than it takes you to figure
out
> the fix and re-write the code or two weeks, wichever is longer. Trust me,
you
> will profit from it. Scott is a good teacher and often leaves a part of
the lesson
> for the pupil to figure out.
------------------------------
** 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
******************************
