Cryptography-Digest Digest #845, Volume #13 Fri, 9 Mar 01 12:13:00 EST
Contents:
Re: => FBI easily cracks encryption ...? ("Mxsmanic")
Re: NTRU - any opinions ("Jakob Jonsson")
Re: Elgamal (David A Molnar)
Re: A few questions ("Joseph Ashwood")
Re: NTRU - any opinions (Dan Bailey)
Re: Meaninog of Kasumi (Arturo)
Re: => FBI easily cracks encryption ...? (Arturo)
Re: DES in software and hardware ("Henrick Hellstr�m")
Re: One-time Pad really unbreakable? (Ben Cantrick)
Re: One-time Pad really unbreakable? (Richard Herring)
Re: One-time Pad really unbreakable? ("Douglas A. Gwyn")
Re: Really simple stream cipher ("Scott Fluhrer")
Re: Help needed -- reverse-engineering stream-encoder�sequence generator ("Scott
Fluhrer")
Schneier's cryptanalysis self-study course (Kay Connelly)
Re: Really simple stream cipher ("Henrick Hellstr�m")
Re: Super strong crypto ("Douglas A. Gwyn")
Re: One-time Pad really unbreakable? ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Fri, 09 Mar 2001 15:04:35 GMT
"Damian Kneale" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Thus the only security you can rely on is the
> difficulty of breaking the encryption on the links.
It doesn't take much, unless you are very, very interesting to the
spooks.
> Probably doesn't cut it when you are designing
> a government grade encryption system.
Sure it does. Not everything is ultra top super secret.
"Government-grade" covers a lot of ground. DES is government-grade, for
example.
> Not even the US government has tried to enforce
> laws quite that futile.
The U.S. is among the more liberal of countries in this domain.
> Personally I know I have insufficient interest
> to attract a national defence agency to have interest
> in me ...
Probably, but then again, they wouldn't announce their interest to you
by letter, either.
> I'm far more worried about things like online credit
> card security, and refuse to use mine online.
Things like SSL are more than enough to secure your credit-card
transactions in transmission. Your credit card just isn't worth enough
to make it cost-effective to crack SSL. Of course, the server databases
that contain that information may still be insecure, depending on how
careless a merchant is.
Nevertheless, I am much more comfortable buying things online than I am
in person or by telephone. The former method requires no human
intervention, but the latter methods do, and the opportunity for errors
and fraud comes with human involvement, not with machine-processed
information.
> Even supposedly secure systems and SSL links don't
> convince me.
Perhaps you are making billion-dollar purchases that would justify
breaking encryption to get at your credit card, then.
------------------------------
From: "Jakob Jonsson" <[EMAIL PROTECTED]>
Subject: Re: NTRU - any opinions
Date: Fri, 9 Mar 2001 16:27:55 +0100
"DJohn37050" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> So, ECC has a space advantage and perhaps NTRU has a speed advantage on a
> Pentium, if you believe NTRU is strong. I notice that the NTRU sig method
> presented at Crypto is no where to be found (anymore) on the NTRU webstie,
> instead a new one from fall 2000 is being offered. What happened to the
old
> one, did someone break it? Do you think this inspires confidence?
> Don Johnson
See http://eprint.iacr.org/2001/005/:
Ilya Mironov. A Note on Cryptanalysis of the Preliminary Version of the NTRU
Signature Scheme. Preprint.
Mironov's attack is fatal. Apparently, the attack does not apply to the
adapted scheme. Yet, I wouldn't recommend NSS before it has received more
scrutiny. IMHO, it is way more complex and difficult to grasp than the neat
NTRU encryption scheme.
Jakob
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Elgamal
Date: 9 Mar 2001 15:28:57 GMT
Vipul Ved Prakash <[EMAIL PROTECTED]> wrote:
> Are there provably secure schemes for encrypting and signing with Elgamal
> (analogous to Optimal Asymmetric Encryption and Probablistic Signature
> Scheme for RSA) ?
It's not quite Elgamal, but you should look at DHAES, from Abdalla,
Bellare, and Rogaway.
http://citeseer.nj.nec.com/abdalla98dhae.html
The conversion schemes mentioned elsewhere in this thread would also work.
-David
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: A few questions
Date: Tue, 27 Feb 2001 17:01:09 -0800
"Koen Van Baelen" <[EMAIL PROTECTED]> wrote in message
news:yHXm6.33453$[EMAIL PROTECTED]...
> 1 :
> How can I generate real random numbers? And i don't mean the numbers
> generated by the 'random' functions you find in all programming languages.
I
> want something that produces totally unpredictable numbers. I know there's
> some mathematical theory for producing random numbers, so if anybody knows
> about it, pleasy let me know!
You've asked two different questions. There are at least 4 classes of random
number generators, in order of increasing requirements:
Common
Unpredictable
Cryptographically Strong
pure
Common RNGs are what you find in programming languages.
Unpredictable RNGs are things like Mersenne Twister, they are useful for
Monte Carlo simulations, but may be subject to cryptanalytic attacks
Cryptographically strong RNGs are rare. The most commonly recognised one
right now is ARCFOUR (or RC4), it can be found at any number of locations.
There are several available.
pure RNGs are true random number generators. They exploit the randomness
inherent in natural processes to produce random data. These are very
difficult to build, and are very often claimed but never realized.
Determining which category(s) an RNG falls into is anywhere from easy to
difficult.
If it outputs something it can be considered to be of at least "Common"
grade, we generally don't bother grading any finer at this level for the
same reason no one discusses 8086 versus 68000, it's really not worth it.
Unpredictable RNGS are more difficult to distinguish and can have a rather
heavy gradation internally. All unpredictable RNGs have the behavior that
examination of the output alone reveals very little about the continued
output.
Cryptographically strong RNGs are rare. They have the behavior that for
reasonable lengths L, given all but one bit it is difficult to determine
that single bit. These also have a heavy gradation, based on the size of L.
For example RC4 (ARCFOUR) has L at about 2^24 to 2^30. Anything with an L
below 2^20 is almost certainly unacceptable.
pure RNGs are an extreme case of the cryptographically strong RNGs in that L
is extended to infinite, and your odds of guessing any bit must be exactly
1/2 given all other bits. This level also requires a strong proof of some
kind. Currently at best we have theorized that certain behavior is
classified as this. We theorize that timing between radioactive degradation
qualifies, we theorize that quantum mechanics offers a few opportunites in
this realm, etc. We do not have any proofs.
I hope that helps. Anyway if you just want to go with a good solid RNG that
is fast enough for most purposes and very difficult to cryptanalyze, I'd
suggest RC4.
> 2 :
> Does anybody have an electronic version of "Applied cryptography"? I can't
> find it in any bookstore and it way to expensive at amazon.com.
Many have asked and I don't think anyone has gotten an affirmative response.
I doubt an electronic version has been leaked, and besides most of us here
have too much respect for Schneier to stab him in the back like that, the
others, well most of them disdain him enough that they wouldn't bother with
Applied Cryptography. However you can find the "Handbook of Applied
Cryptography" with a quick search, and it is also a fine book introducing
cryptography.
Joe
------------------------------
From: Dan Bailey <[EMAIL PROTECTED]>
Subject: Re: NTRU - any opinions
Date: Fri, 9 Mar 2001 10:45:49 -0500
Anyone (even those who work for Certicom!) who would like a document on
the extensive scrutiny NTRU has received in the literature can feel free
to email me. I'll be happy to oblige.
Here's the executive summary: "Better attacks or better lattice reduction
algorithms are required in order to break NTRU" (Nguyen and Stern, in
ANTS-2000).
Cheers
Dan
PS Yes, I work for NTRU.
On 9 Mar 2001, DJohn37050 wrote:
> So, ECC has a space advantage and perhaps NTRU has a speed advantage on a
> Pentium, if you believe NTRU is strong. I notice that the NTRU sig method
> presented at Crypto is no where to be found (anymore) on the NTRU webstie,
> instead a new one from fall 2000 is being offered. What happened to the old
> one, did someone break it? Do you think this inspires confidence?
> Don Johnson
>
>
------------------------------
From: Arturo <aquiranNO$[EMAIL PROTECTED]>
Subject: Re: Meaninog of Kasumi
Date: Fri, 09 Mar 2001 16:03:49 +0100
On 8 Mar 2001 13:30:01 -0800, [EMAIL PROTECTED] (Gregory G Rose) wrote:
>In article <[EMAIL PROTECTED]>,
>Mike Rosing <[EMAIL PROTECTED]> wrote:
>
>"Kasumi" means "fog", and the name is derived (as
>is the algorithm) from MISTY.
>
>Greg.
It is? I read Kasumi (I mean the algorithm) is a derivation from
Rijndael.
------------------------------
From: Arturo <aquiranNO$[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Fri, 09 Mar 2001 16:09:24 +0100
On 08 Mar 2001 10:51:36 -0800, Paul Rubin <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Damian Kneale) writes:
>> To wade into the whole "capabilities" debate, the choice seems fairly
>> simple. Have a government capable of breaking code and listening at
>> will, or have one that cannot. Being from Australia, a country
>> defended from Japan during WW2 largely due to successes in
>> codebreaking, I'm all for a government that has that capability.
>> Making sure your government is trusted with that capability is a
>> little tougher...
>
>You're a little confused though. That type of codebreaking against
>modern crypto is impossible as far as anyone can tell. Unlike in WW2,
>governments *can't* break today's codes
They can�t? In that case, I suggest you revise the story of, for
example, the GSM algorithms. They might not be able to crack everything, but
they are working hard to popularize weak encryption.
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: DES in software and hardware
Date: Fri, 9 Mar 2001 17:02:38 +0100
Depending on the quality of the compiler, optimized C code (or Pascal code
etc) is rarely less than half as fast as optimized assembler. The major
problems are (1) that in high level languagues you don't have any direct
control over whether variables are stored in CPU registers (fast) or on the
stack (slower), but might use various programming tricks to control it
indirectly, and (2) that some operations, like ROR and ROL, aren't available
as built in operators.
I guess you could implement DES on a single, quite long and close to
unreadable, line of C code that would be almost as fast as assembler code,
except that the single assembler line ROR/ROL operations would have to be
substituted for a MOV, SHL, SHR, OR sequence of operations in the compiled
code. If the compiler supports inline assembler macros with the Delphi
"register" calling convention, you could possibly get rid of this bottle
neck too, adding only a single line of assembler to the source code (ROL
EAX,CL on x86 processors).
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
"Lovecraftesque" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> 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: [EMAIL PROTECTED] (Ben Cantrick)
Subject: Re: One-time Pad really unbreakable?
Date: 9 Mar 2001 09:16:17 -0700
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
>Ben Cantrick <[EMAIL PROTECTED]> wrote:
>:>: I can send you a piece of OTP cipher and I'll guarantee
>:>: you won't break it in a million years.
>:>
>:>What will that prove? How can I place any trust in your guarantee?
>:>I don't know you from Adam.
>
>: The security of a one-time pad does not rest on trusting some random
>: person on USENET. Used properly, it is a (perhaps the only) provably
>: unbreakable cypher.
>
>: See http://web.ranum.com/pubs/otpfaq/
>
>Nope. The proof of perfect secrecy rests on the availability of a shared
>unguessable stream. No such thing has ever been demonstrated to exist.
>
>Consequently the proof of secrecy of the OTP cannot be transferred onto
>real-world systems used for actual communication without qualifications
>being made.
Don't bother me with practical details. Sheesh. ;]
Point is, given the preconditions, an OTP is provably unbreakable.
Are those conditions very hard, perhaps impossible to meet? Possibly.
But if you have that random stream, you have unbreakable encryption -
and provably so.
-Ben
--
Ben Cantrick ([EMAIL PROTECTED]) | Yes, the AnimEigo BGC dubs still suck.
BGC Nukem: http://www.dim.com/~mackys/bgcnukem.html
The Spamdogs: http://www.dim.com/~mackys/spamdogs
I refuse to star in your psychodrama. Buzz off.
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: One-time Pad really unbreakable?
Date: 9 Mar 2001 15:28:58 GMT
Reply-To: [EMAIL PROTECTED]
In article <ISQp6.79288$[EMAIL PROTECTED]>, Mxsmanic
([EMAIL PROTECTED]) 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.
*Nothing* in science is ever _proven_. Read Popper: science
necessarily proceeds by induction, not deduction. Mathematical
proof and scientific "proof" are very different animals.
> Calling it
> non-random would be like saying that repulsive gravity exists.
That's right. At present there is no evidence for either, but
that doesn't mean we can categorically rule out the possibility.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Fri, 9 Mar 2001 16:06:23 GMT
Tim Tyler wrote:
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> : 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.
> Yet there are deterministic theories of how the world operates, ...
> ...
> Yes, many-worlds is a deterministic theory [...]
> A deterministic theory has no place for randomness.
"Deterministic" has a technical meaning which is not an exact
antonym of "random".
The consequences of many-worlds theory are identical to those
from conventional quantum theory, and as such it doesn't help.
("Many" is a misnomer since it is a nondenumerable infinity.)
> Anyway, regardless of whether quantum events tap into fundamentally
> unpredictable phenomena or not the question of how to get an
> unguessable shared stream to both parties while ensuring that
> nobody else can predict the information remains.
> This problem is to do with macroscale devices, couriers, whether
> your component suppliers can be trusted, whether the state of your
> randomness detector is being remotely monitored, and so on.
Note that Rabin and I have recently proposed methods for doing
this without requiring a separate trusted channel.
> Quantum theory doesn't come into this discussion - it's a bit of a
> red herring, really.
It comes into the discussion to the extent that it provides a
fundamentally unpredictable source of randomness that can be
exploited in practical devices to generate random bits in a
manner that we are confident the enemy cannot cryptanalyze.
Actually, thermal noise is good enough for that, but the
argument is subtler than for quantum randomness.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Fri, 9 Mar 2001 08:17:24 -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.
>
> 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.
Attack against the error propagation: consider what would happen if an
attacker xored the error vector:
(40000000 80000000 00000000)
into some ciphertext. This would appear to (with probability 0.5) produce
the error vector
(40000000 80000000 00000001)
into the plaintext, and not have the error propogate beyond that.
I've never been a fan of error propagation, at least to detect delibrate
errors. I do not believe that it is good security practice to deliver
gibberish to the application, and hope it notices that it's invalid. IMHO,
It is far better to introduce an explicit cryptographic primitive (e.g. a
MAC or a signature) which is designed specifically to reject errors with
high probability, and not rely on the behavior of the application under
random inputs.
>
>
> "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: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Help needed -- reverse-engineering stream-encoder�sequence generator
Date: Fri, 9 Mar 2001 08:26:16 -0800
Vlad ROMASCANU <[EMAIL PROTECTED]> wrote in message
news:989rni$13hji$[EMAIL PROTECTED]...
> Hello,
>
> I am attempting to reverse-engineer a stream-encoder, which has an 8-bit
> wide input/output bus. I suspect it is not something very complicated
(the
> encoder was not designed for encrypting data, but more as some sort of
> identification mechanism of the form 'here is some input, is your output
> what I expect it to be?').
>
> I need some hints as to what to do in order to come up with a solution.
> Here is some sample input/output (all values in hexadecimal), I'm showing
it
> because it exhibits a regularity (see bottom of message) that might prove
> helpful:
>
> Constant input of 0x00:
> Output: 40 e5 4e a8 3e e3 4c a6 3c e1 4a a4 3a df 48 a2 38 dd 46 a0 ...
>
> Constant input of 0x01:
> Output: 41 e5 4d a8 3f e3 4b a6 3d e1 49 a4 3b df 47 a2 39 dd 45 a0 ...
>
> Constant input of 0x02:
> Output: 3e e5 50 a8 3c e3 4e a6 3a e1 4c a4 38 df 4a a2 36 dd 48 a0 ...
>
> ...
>
> Constant input of 0xff:
> Output: 13 6d 03 a8 11 6b 01 a6 0f 69 ff a4 0d 67 fd a2 0b 65 fb a0 ...
>
> input = {n | n = 0...inf}:
> Input: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 12 13 14 ...
> Output: 40 e4 4f a8 3a da 49 a6 44 f0 53 a4 3e e6 4d a2 28 dc 57 a0 ...
>
> input = {lower_bound(1.5*n) | n = 0...inf}:
> Input: 00 01 03 04 06 07 09 0a 0c 0d 0f 10 12 13 15 16 18 19 1b 1c ...
> Output: 40 e4 4f a8 3a da 49 a6 44 f0 53 a4 3e e6 4d a2 28 dc 57 a0 ...
>
> input = {n*2 | n = 0...inf}:
> Input: 00 02 04 06 08 0a 0c 0e 10 12 14 16 18 1a 1c 1e 20 22 24 26 ...
> Output: 40 e7 54 b0 4e fd 62 b6 3c f3 70 bc 4a 9 7e c2 78 ff 4c c8 ...
>
> input = {n*4 | n = 0...inf}:
> Output: 40 e1 42 98 1e cf 40 86 3c bd fe 74 1a ab fc 62 38 19 3a 50 ...
>
> In all the constant-input cases, as well as in the 0 1 2 3 4...
> input-sequence case, the output S[n+4] = S[n] - 2. Unfortunately, this
does
> not hold for more irregular input sequences (e.g. the last three cases).
>
> I first though I was dealing with a LFSR (linear feedback shift register)
> and tried to solve for the constant-0 input as a LFSR, but got no solution
> for 16-bit and less LFSRs (I expect the period of the sequence, for
constant
> input, based on S[n+4] = S[n] - 2, to be around (256/2)*4 = 512 = 2^9).
>
> So, what can I be dealing with? BTW, the encoder is built in hardware and
> has a very secondary role, therefore I don't expect any expensive
resources
> (such as multipliers/dividers, or even adders/subtractors) to be allocated
> to it, it's probably just a bunch of XORs, ANDs and ORs.
>
> What tools can I use to analyze this beast?
What might be especially useful is if you introduced sequences such as:
01 00 00 00 00 00 00 00 00
and compare that to the all-zero sequence. For one, you'll see how error
propogating it is.
In addition, if it is entirely linear, then if you have the outputs for the
nine sequences:
00 00 00 00 00 00 00 00 00
01 00 00 00 00 00 00 00 00
02 00 00 00 00 00 00 00 00
...
80 00 00 00 00 00 00 00 00
you should be able to reconstruct the output for any sequence -- it should
be relatively clear how to do so.
--
poncho
------------------------------
From: Kay Connelly <[EMAIL PROTECTED]>
Subject: Schneier's cryptanalysis self-study course
Date: Fri, 09 Mar 2001 11:41:52 -0500
I'm starting to work through Bruce Schneier's "A Self-Study Course
in Block-Cipher Cryptanalysis"
(http://www.counterpane.com/self-study.html).
I'm looking for a couple of people who would be interested in
working through it together... exchanging ideas and brain-storming
before we give in and look for a published solution. If you're
interested, let me know.
Kay Connelly
[EMAIL PROTECTED]
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Fri, 9 Mar 2001 17:58:08 +0100
"Scott Fluhrer" <[EMAIL PROTECTED]> skrev i meddelandet
news:98b067$on8$[EMAIL PROTECTED]...
> I've never been a fan of error propagation, at least to detect delibrate
> errors. I do not believe that it is good security practice to deliver
> gibberish to the application, and hope it notices that it's invalid.
Every application that utilizes any kind of security primitive has to be
designed in a particular way in order not to weaken that security primitive.
For instance, passwords, keys etc always have to be carefully handled. It is
not principally different to demand that an application that relies on error
propagation for authentication purposes must treat input with special care.
This just goes to prove that there are good security products, and there are
bad, depending on various implementation issues.
> IMHO,
> It is far better to introduce an explicit cryptographic primitive (e.g. a
> MAC or a signature) which is designed specifically to reject errors with
> high probability, and not rely on the behavior of the application under
> random inputs.
Well, I disagree. The user must always rely on the behavior of the
application under specific circumstances, regardless of the kind of security
primitives it implements. A MAC or a signature does not necessarily reject
errors with higher probability than a properly designed and implemented
error propagating cipher. The question is rather which one is most efficient
and which one is (from the user's epistemic point of view) most likely to
fail due to poor implementation.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Fri, 9 Mar 2001 16:26:51 GMT
Mok-Kong Shen wrote:
> If you are considering that kind of security requirement,
> then you should also be aware of the fact that the
> block cipher itself, on which your proposal is based,
> is inherently insecure, I suppose. In that sense, I
> don't yet see that you have solved the security problem.
I see you have missed the point of my proposal. There
is a world of difference between ideal security and
practical security. I am concerned with taking some
standard symmetric encryption algorithm, which is not
proven to be secure against all possible cryptanalysis,
and enhancing the way it is used to provide more security,
to the point that I can have *confidence* that not even
the best feasible cryptanalysis is going to be able to
break it (more likely than some acceptable threshold).
That might not solve your security problem but it sure
would solve mine!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Fri, 9 Mar 2001 16:12:50 GMT
Tim Tyler wrote:
> I believe you are mistaken here. As I understand it, the theory is
> consistent with sub-atomic physics being random - but it is also
> completely consistent with it being based on deterministic rules.
Determinism can still involve random processes. The key point
to realize is that the source of *quantum* randomness has
properties that are demonstrably different from conventional
sources of randomness; it cannot be attributed to lack of
sufficiently detailed knowledge of the state of the generator.
One clue to this (not fully appreciated by Schroedinger at the
time he first published his wave equation, so don't feel you've
missed something obvious) is that whatever is ultimately behind
the randomness has dimensionality 2, not 1. (I.e., Phase matters.)
------------------------------
** 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
******************************
