Cryptography-Digest Digest #98, Volume #10 Mon, 23 Aug 99 14:13:03 EDT
Contents:
Re: CBC problems... (Tom St Denis)
RE: MUM (Gary)
Re: CBC problems... (SCOTT19U.ZIP_GUY)
Re: CRYPTO DESIGN MY VIEW (SCOTT19U.ZIP_GUY)
Re: Cipher-Feedback Mode (Anton Stiglic)
Re: CBC problems... (Anton Stiglic)
Re: Where to find (SCOTT19U.ZIP_GUY)
Re: Attacks on RC4 ? (Paul Crowley)
Re: question regarding number of keys possible. . . (John Savard)
Re: How does RC4 work ? (Paul Crowley)
Re: DES key parity! (Anton Stiglic)
Re: Key exchange options? (Medical Electronics Lab)
Re: How does RC4 work ? (Tom St Denis)
Re: truly anonymous membership proof (Anton Stiglic)
Re: CBC problems... (Tom St Denis)
Re: How does RC4 work ? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: CBC problems...
Date: Mon, 23 Aug 1999 16:10:01 GMT
In article <7prmu5$790$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Ian Goldberg) wrote:
> In article <7prjcl$1s4$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> >And for some reason (it works to encrypt/decrypt) when I change a bit
> >in the message (before doing the text to binary trans) the errors
> >appear local (within the block I changed) in the decrypted message,
the
> >rest of the message (after the error) is ok. This example above is
the
> >Twofish encryption part which is suppose todo CBC...
> >
> >Am I missing something?
>
> Just the fact that that's how it's *supposed* to work.
>
> If C[n] is mistransmitted as C'[n] = C[n]+X (+ == XOR), and all other
> ciphertext blocks are correct, then certainly P'[i] = D(C[i]) + C[i-
1] = P[i]
> for each i < n, and P'[n] = D(C'[n]) + C[n-1] is random, and
> P'[n+1] = D(C[n+1]) + C'[n] = D(C[n+1]) + C[n] + X = P[n+1] + X has an
> error of exactly X, and P'[i] = D(C[i]) + C[i-1] = P[i] for i>n+1 as
well.
>
> Summary:
>
> When you make an error in the ciphertext of a CBC-mode transmission:
>
> o The block containing the error will end up random
> o The next block will be wrong by exactly the error made in the
ciphertext
> o All previous and subsequent blocks will be correct
Thanks for the feedback (I realized I made the mistake that's why I
replied to my own message). I was thinking of PCBC not CBC when I
thought it was wrong.
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Gary <[EMAIL PROTECTED]>
Subject: RE: MUM
Date: Mon, 23 Aug 1999 12:32:45 -0400
Analysis of small 2x2 matrices (mod 2 to the power of 2) show that the size
of
the range of an univertible matrix multiplied by an invertible is small
(less
than 1/16 of the domain, considerable less with some particular
uninvertables).
The solution is obviously to increase the number of bits in the elements.
Gary :)
>===== Original Message From [EMAIL PROTECTED] (John
Savard) =====
>Gary <[EMAIL PROTECTED]> wrote, in part:
>
>>Public key sender broadcasts the pair [C][Sb] and [C].
>
>OK: this is sort of like Diffie-Hellman.
>
>Two people wish to communicate; each one thinks of an invertible
>matrix.
>
>A non-invertible matrix is disclosed.
>
>The non-invertible matrix, C, is public, and so are [Sa][C] and
>[C][Sb]. An eavesdropper could calculate [Sa][C][C][Sb], but only the
>participants could calculate [Sa][C][Sb].
>
>Is this a way of doing Diffie-Hellman without exponentiation?
>
>I think the problem will be something like this: C will commute with
>both [Sa][C] and [C][Sb], so a "kind of" inverse of C - one that will
>remove every change that C makes *except* for the blurring of its
>inputs that makes it noninvertible - can be calculated, and that
>inverse, even though it isn't the true inverse, will be "good enough"
>to allow an attacker to calculate [Sa][C][Sb].
>
>Those with more math expertise can, doubtless, make this more
>definite.
>
>John Savard ( teneerf<- )
>http://www.ecn.ab.ca/~jsavard/crypto.htm
============================================================
Get your FREE web-based e-mail and newsgroup access at:
http://MailAndNews.com and http://MailAndNews.co.uk
Create a new mailbox, or access your existing IMAP4 or
POP3 mailbox from anywhere with just a web browser.
============================================================
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: CBC problems...
Date: Mon, 23 Aug 1999 16:52:42 GMT
In article <7prmu5$790$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Ian
Goldberg) wrote:
>In article <7prjcl$1s4$[EMAIL PROTECTED]>,
>Tom St Denis <[EMAIL PROTECTED]> wrote:
>>And for some reason (it works to encrypt/decrypt) when I change a bit
>>in the message (before doing the text to binary trans) the errors
>>appear local (within the block I changed) in the decrypted message, the
>>rest of the message (after the error) is ok. This example above is the
>>Twofish encryption part which is suppose todo CBC...
>>
>>Am I missing something?
>
>Just the fact that that's how it's *supposed* to work.
>
>If C[n] is mistransmitted as C'[n] = C[n]+X (+ == XOR), and all other
>ciphertext blocks are correct, then certainly P'[i] = D(C[i]) + C[i-1] = P[i]
>for each i < n, and P'[n] = D(C'[n]) + C[n-1] is random, and
>P'[n+1] = D(C[n+1]) + C'[n] = D(C[n+1]) + C[n] + X = P[n+1] + X has an
>error of exactly X, and P'[i] = D(C[i]) + C[i-1] = P[i] for i>n+1 as well.
>
>Summary:
>
>When you make an error in the ciphertext of a CBC-mode transmission:
>
>o The block containing the error will end up random
>o The next block will be wrong by exactly the error made in the ciphertext
>o All previous and subsequent blocks will be correct
>
> - Ian
Tommy just does oit get it. He can spout all kinds of BS but now we find
he does not even have a clue as to how CBC works. Yet he acts like he
understands what "wrapped-PCBC" is and how it relates to other cipher chaining
methods. Tommy grow up.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Mon, 23 Aug 1999 16:48:03 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>>
>> >
>> >To be exact, you can't say how many input symbols are obtained from
>> >the x's. For instance, it could be that there are Huffman codes
>> >that occupies only 3 x positions. All one knows (by our assumption)
>> >is that the last 9 bits of the original output file constitute one
>> >single Huffman code and therefore these 9 bits will be decompressed
>> >to one input character (which, if it is 8 bit ASCII, occupies a byte).
>> >But this fact is unimportant for the present discussion.
>> What are you thinking I thought the x's where a single token.
>> Look it is obvious you are lost and don't know what I mean. PLEASE
>> ASK SOMEONE ELSE FOR HELP.
>
>Eh?? What was wrong?? There were 7 x's, each being a bit position,
>so it could well be that 3 of the bits consitute one Huffman code.
>That each x represent a bit in the output file (compressed file)
>should have been entirely clear to you in all the discussions up
>till now!!!!!
Get real the 7 x's where only one token. Your are the one who just
said maybe 3 of the x's are part of a token and the 7'x could be more than
one token. You don't have a clue.
>
>> My method takes "ANY BINARY FILE" call that file "A" and decompresses to a
>> file call that FILE "B". If you compress file "B" you get exactly "A" back
>> PERIOD.
>> Also you can take FILE "A" compress it to a FILE "C" take FILE "C" when
>> you decompress it you get FILE "A" back exactly.
>> This is "one to one" compression decompression. There is no wrong
>> file except in your mind. The method used is "adaptive huffman compression"
>> it is exactly like the huffman bit stream except that sometimes it is left
>> alone. Sometimes it is zero filled and sometimes the last partial byte is
>> chopped off altogether. I am done talking to you.
>
>This is COWARD in scientific discussions!!! When shown by others that
>you are wrong, you simply discontinue the argumentation. You snipped
>and did not refer at all to the ESSENTIAL paragraph of mine in the
>previous post which explained in detail (based on assertions of your
>own) that your program, when encountering the 0 bit of my example
>which it can't deal with, simply ignores the error (abnormal)
Your a fucking idot the encountering of the last 0 in the case we
where talking about is not an ERROR. IF you don't have the mental
abiltity to get beyond this point. What is there left to discuss. You
can rant and rave and call it an error just because you have a closed
mind. But if it is an error construct a file to show this. You can't because
you are are messed up.
>condition. This shows that your program violates the very elementary
>requirements of program correctness and consequently all you
>hard-necked claims (without proof) of the 'one to one' property are
>only an illusion, if not downright cheating!!!
I'm sorry but I think your FULL of SHIT. OR suffering from a brain
piron infection. If you think there is an error find one example of a finite
(not over several megabtyes that does not compress and recover after
decompression. Or the opposite decompress the file and than compress it. If it
does not do this then my code has an error. But your insane ramblings do not
show an error. Like I said you have the code but unfortunately even after
I have tried many times to help you understand for some reason you seem
incabable of following a simple thought. Nothing personnel but you may need
imediate medical attension.
>
>I want to explicitly call the attention of all participants of this
>group to your present behaviour in this discussion thread so that
>they will well use it as a hint to help them judging the quality of
>your programs and the scientific trustworthiness of your often
>made claims (without accompanying proofs) in the field of cryptology.
>
And I would like someone to follow this thread and see who is lost.
This is impossible to get anything through his head. Have any others
been successful discussing anything basic with this individual. IF you have
please try to explain what is going on in my dynamic huffman compression
program becasue he is clueless.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Cipher-Feedback Mode
Date: Mon, 23 Aug 1999 11:47:06 -0400
Even more so, CFB can be viewed in the abstract case where a block
cipher E is used. If E takes an n-bit block as input and uses a k-bit
key, then error propagation of a certain block will affect that block,
+ the next floor(n/k) blocks (floor(n/k) = 2 for DES, as Denis said).
Also, as was said, the CFB that has been explained is the simple
one, there is one in wich, instead of processing n-bit blocks, you
cut the message in r-bit blocks (0 < r <= n), this one is more
complicated.
Menezes, Oorschot and Vanstone explain it well in "Handbook fo
Applied Cryptography".
Interestingly, I found that the NIST report FIBS PUB 81 (DES modes
of operation)sucks at explaining the modes, refered figures where never
even included (I could not found a more recent version with it either?).
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> : take the top n bits of the IV, xor it against the plaintext text, shift
> : the IV n bits to the left, place the ciphertext bits in the lsbs, and
> : encrypt the IV.
>
> I should have noted, though, that you're right that CFB can be performed
> with different numbers of bits per encipherment; I only mentioned the
> simplest variant, 64-bit (or full-width, for block ciphers with different
> block sizes than DES) CFB.
>
> John Savard
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: CBC problems...
Date: Mon, 23 Aug 1999 11:56:06 -0400
Your not the only one to have asked stupid questions here! :)
Anton
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Where to find
Date: Mon, 23 Aug 1999 17:00:05 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(David Hamilton) wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>
>(snip)
>
>> I design as I code. Which is the way I have coded the last 30 years
>>and airplanes and missles count on my ability to do this.
>
>This is silliness, arrogance and UNprofessionalism of the highest order. If
>you design as you code, you do not design at all. If you really have done
>this for the last 30 years, it speaks volumes for your inability to learn.
>That you believe an employer (any employer) would rely on you and your stated
>approach in the realms of 'airplanes and missles' shows that you have no
>grasp of reality.
>
It may be arrogance but I am sure many Navy Pilots owe me unknownly
for fixing many potentail dangerous errors introduced by the kind of
programers that some one of your limited back ground would respect.
>This is, though, to good an opportunity to miss. For years to come, I expect
>to use the above as a blood-curdling reason as to why people should not trust
>you or your software.
IF this is how you judge software I hope you get in a postion to hire
programers for the company you work in. Let me know so I can by stock
in your compeditors.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Attacks on RC4 ?
Date: 23 Aug 1999 09:24:44 +0100
I'm sure others here will supply details of the two weak key attacks
found by Andrew Roos and David Wagner, but here's the one other result
I know about: a very tiny bias in the CPRNG, experimentally verified.
http://www.hedonism.demon.co.uk/paul/rc4/
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: question regarding number of keys possible. . .
Date: Mon, 23 Aug 1999 16:11:37 GMT
[EMAIL PROTECTED] () wrote, in part:
>Wesley Horton ([EMAIL PROTECTED]) wrote:
>: Did anyone ever come up with an effective method of generating such
>: wirings (interval wiring) of rotors on a computer?
>A table of output from these programs, combined with the odd-order numbers
>from another source, is on my web page. A link to it is present at
>http://www.freenet.edmonton.ab.ca/~jsavard/roto02.htm
The exact link is:
http://www.freenet.edmonton.ab.ca/~jsavard/ro020302.htm
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: How does RC4 work ?
Date: 23 Aug 1999 09:31:14 +0100
"Georg Zetzsche" <[EMAIL PROTECTED]> writes:
> Does anybody know, how the RC4 - encryption algorithm works ?
It's AFAIK the simplest strong cipher in the world. Ciphersaber
(an RC4-based cryptosystem) provides a good description:
http://ciphersaber.gurus.com
And here's a Perl implementation of Ciphersaber for your
entertainment:
#!/usr/bin/perl -0777i_MUNITION,see_http://ciphersaber.gurus.com
(pop)?read STDIN,$p,10:print$p= ~time;sub S{@s[$x,$y]=@s[$y,$x]}sub
Q{$s[($_[0]+=$_[1])%=@s]}@k=unpack'C*',(pop).$p;for$x(@t=@s=0..255){S
Q$y,$k[$x%@k]+Q$x}$x=$y=0;print map{chr($_^Q S Q$y,Q$x,1)}unpack'C*',<>
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: DES key parity!
Date: Mon, 23 Aug 1999 13:28:09 -0400
John Halliwell wrote:
> I know DES uses only 56 bits out of a 64 bit key and that the parity of
> the key should be odd, but is the parity check mandatory or just
> optional?
>
> What should happen if the key parity isn't odd?
>
> The standard seems to specify that the eigth (LSB) bit of each byte
> "may" be used for error checking, can a key expressed as 64 bits be
> valid if it contains even parity?
>
> Any answers would be greatly appreciated.
> --
> John
>
> Preston, Lancs, UK.
DES is b1b2.... b64
if b1...b7 has an odd number of bits, you put b8 = 1, else b8 = 0 (or the
other way around, anyways, one or the other). (b8 is the parity bit).
Same thing for the other blocks of 8 bits.
That's all, so when you get a key, your program should check the number
of bits in each block and comare the founding of the check to the parity
bits.
So if you want a program you write to be compatible with others that use
DES, make sure to use this technic on any key your program generates.
If your program uses keys, you do not have to absolutetly use this
technic,
but you are just asking for possible faults if you don't!
Anton
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Key exchange options?
Date: Mon, 23 Aug 1999 12:41:37 -0500
Kasper Pedersen wrote:
>
> I've been searching the web for a key exchange protocol, like
> Diffie-Hellman, and have
> been unable to find any source whatsoever.
> If I want a common-key-establishment-method (like DH), what are my options?
> Second, DH is relatively heavy to do, how is this solved in smaller
> appliances like GSM phones?
You can do DH over GF(2^n) on an 8 bit microcontroller using ECC
in "reasonable" time. Most phones have DSP's in them with 16 or 24
bit capability so that shouldn't be much problem. ECC sources
are available from several places. Check out
http://ds.dial.pipex.com/george.barwood/index.htm
http://www.certicom.com
for descriptions or
http://www.terracom.net/~eresrch
for code.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: How does RC4 work ?
Date: Mon, 23 Aug 1999 17:48:56 GMT
In article <7ps14k$cug$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Tom St Denis wrote:
>
> > to schedule a key (extend it to fill K (256 bytes))
> >
>
> 0) for i = 0 to 255 do
> S[i] = i
> 0.5) j = 0
>
> > 1) for i = 0 to 255 do
> > 2) i = (j + S[i] + K[i]) mod 256
> ^
> should be j, not i.
>
> > 3) Swap(S[i], S[j])
>
> 4) i = j = 0
oops yup (I am having a bad day.) The complete routine is
1) for i = 0 to 255 do
2) S[i] = i
3) j = 0
4) for i = 0 to 255 do
5) j = (j + S[i] + K[i mod key_length]) mod 256
6) swap(S[i], S[j])
7) i = 0
8) j = 0
That should be right.
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: truly anonymous membership proof
Date: Mon, 23 Aug 1999 13:42:23 -0400
>
>
> I don't think there can be a solution to this problem. If entity A
> can prove it belongs to the group, it can pass all its knowledge to
> unauthorized entity B, that now would be able to replay A's behavior
> in any protocol.
>
> It's like saying ``I want to truely ensure I talk to Jim without
> anyone being able to impersonate him without knowing Jim, even if Jim
> co-operates with the impostor.''
>
> > I think that I have a solution to this problem [...]
>
> Post it.
It's not exactly the same thing. If you are an element x, you just want
to
proove to Bob that you belong to a set S, letting Bob know that you are
an element of S without telling exactly wich one that is, and without
giving
out info that can be used by Oscar to do the same thing.
For example, in the interactive proof for graph collorability, the
allmighty proover
P can convince Alice that a certain graph is 3-colorable, without giving
the
coloring. Alice will beleive with a certain probability p (where 1 - p
is exponentially
small) that the graph is 3-colorable if it is. P can proove to Alice
that a certain
graph g belongs to 3-COLOR, and the info that is passed from P to Alice
can not
be used by any Oscar to proove the same thing to Alice. This is just a
simple
example that I can think of to convince you that it is possible.
The paper that David ref to is interesting also, you might get some
other refs form there.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: CBC problems...
Date: Mon, 23 Aug 1999 17:46:11 GMT
> Tommy just does oit get it. He can spout all kinds of BS but now we
find
> he does not even have a clue as to how CBC works. Yet he acts like he
> understands what "wrapped-PCBC" is and how it relates to other cipher
chaining
> methods. Tommy grow up.
At least I can spell. (btw: read my reply to my own post).
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How does RC4 work ?
Date: Mon, 23 Aug 1999 17:41:43 GMT
Tom St Denis wrote:
> to schedule a key (extend it to fill K (256 bytes))
>
0) for i = 0 to 255 do
S[i] = i
0.5) j = 0
> 1) for i = 0 to 255 do
> 2) i = (j + S[i] + K[i]) mod 256
^
should be j, not i.
> 3) Swap(S[i], S[j])
4) i = j = 0
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
