Cryptography-Digest Digest #151, Volume #12 Mon, 3 Jul 00 08:13:01 EDT
Contents:
Re: Decrypting MD5 (Boris Kazak)
Re: Hashing Function (not cryptographically secure) (Mack)
Re: Blowfish for signatures? (Runu Knips)
Q: Implementations for DH-key exchange for >2 (=?iso-8859-1?Q?Tom=E1s?= Perlines
Hormann)
Re: A simple all-or-nothing transform (Mok-Kong Shen)
Re: A simple all-or-nothing transform (Mok-Kong Shen)
RE: Elliptic Curves encryption (Greg)
Re: Observer 4/6/2000: "Your privacy ends here" (Simon Elliott)
Re: A simple all-or-nothing transform (Mark Wooding)
Re: Decrypting MD5 (Mark Wooding)
Re: Decrypting MD5 (Steve Rush)
Re: Q: Implementations for DH-key exchange for >2 (Mark Wooding)
Re: AES: It's been pretty quiet for some time... (Volker Hetzer)
Re: Use of EPR "paradox" in cryptography (John Savard)
Re: Tying Up Lost Ends (John Savard)
Re: Tying Up Lost Ends III (John Savard)
Re: Decrypting MD5 (Runu Knips)
----------------------------------------------------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Decrypting MD5
Date: Mon, 03 Jul 2000 06:16:44 GMT
Gail wrote:
>
> Anyone know the best approach to decrypting something encrypted using MD5?
> The key is unknown, unless of course you know where it could be stored on a
> linux system. or how to figure it out if you know how the line looks before
> encryption.
>
> Thanks
=========================
Sorry to disappoint you, but MD5 is not a cipher.
It is a one-way hash function, and as such it was designed
to be non-invertible.
Best wishes BNK
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Hashing Function (not cryptographically secure)
Date: 03 Jul 2000 07:22:35 GMT
Benjamin Goldberg [EMAIL PROTECTED] wrote:
>Scott Fluhrer wrote:
>>
>> Benjamin Goldberg <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]...
>> > Simon Johnson wrote:
>> > [snip]
>> > >
>> > > Padding: if (length of message) mod 64 != 0 then message =
>> > > message & length of document & trailing 0's (to make: len
>> > > (message) mod 64 = 0)
>> > >
>> > > Hashing: for the 0 to i blocks: Hash = block[0] XOR block[1]
>> > > XOR........ block[i]
>> > >
>> > > Any suggestion for this check digit system?
>> >
>> > It's bad ... don't use it; use a 64-bit CRC instead. With an N-bit
>> > crc, if two messages differ by N bits or fewer, they will *always*
>> > have different CRC values. With your method, suppose I have 60
>> > 64-bit blocks, and I use your hash function... If I change the last
>> > bit in all those blocks, the hash remains the same. If I uses
>> > CRC64, changing the last bit in all 60 blocks will result in a
>> > different result.
>> Actually, a N-bit CRC has the property that the CRC's of two messages
>> differ if the bit differences are confined to an area at most N bits
>> in length.
>> His hash has precisely that property, and in retrospect, it's not
>> surprising: the last step is essentially a 64-bit CRC with the
>> polynomial x**64 + 1 (!).
>
>I'm not so sure of the accuracy of your description of what an N-bit CRC
>does... I challenge you to find two messages that differ by 2 bits,
>with more than 16 bits between the differing bits, but which have the
>same CRC16 value.
>
Since the CRC-16 and CRC-CCITT (0x11005 & 0x11021) both detect all
2 bit changes that is impossible.
The code described is a CRC-64 with a bad polynomial. A simple
64 bit checksum would probably work a little better ie. use addition
mod 2^64 instead of mod 2. Speed for software would be the same.
The description of the function of CRC is accurate. A CRC will detect
all changes confined to one block that is shorter than the CRC. But
a good CRC will detect other errors better. ie 2 bit changes.
Some CRCs are better than others even among the 'good' ie. primitive
polynomials.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
Date: Mon, 03 Jul 2000 09:49:31 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Blowfish for signatures?
Eric Lee Green wrote:
> Implementation is left as an exercise for the reader :-).
I hate this statement.
> Obviously this is not a general-purpose mechanism, but may be
> appropriate for certain limited applications.
Yep.
------------------------------
From: =?iso-8859-1?Q?Tom=E1s?= Perlines Hormann <[EMAIL PROTECTED]>
Subject: Q: Implementations for DH-key exchange for >2
Date: Mon, 03 Jul 2000 09:55:40 +0200
Hi folks!
Has anyone implemented Diffie-Hellman's key exchange as specified in
PKCS#3 for 3 or more parties? I am very interested in some kind of an
implementation of that approach, as I need to exchange secret keys among
several clients, without having the chance to use a TTP either as a
server or as a CA.
So please help me out with this. Thanks in advance...
--
Quick answering: mailto:[EMAIL PROTECTED]
Check it out: http://www.weh.rwth-aachen.de/~tomas
Do it Now!
:o) Tom�s Perlines (o:
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A simple all-or-nothing transform
Date: Mon, 03 Jul 2000 10:14:23 +0200
Mok-Kong Shen wrote:
> [snip]
>
> Let n (n even) message blocks P_1, P_2, ..., P_n be given.
> We build their xor-sum S = Sum(P_j) j= 1, 2, ..., n.
> Let B_i = P_i + S. Then the ciphertext blocks are given by
> C_i = E(K, B_i).
>
> The receiver first decrypts to obtain B_i and computes
> Sum(B_j) = (n+1)*S = n*S + S = S (since n is even) and can
> subsequently recover the plaintext blocks P_i from B_i.
The different blocks are in the above in a sense linked
together with the same value S, hence the scheme is not very
good in case of known plaintext. Drawing from discussion
materialy in a recent thread about chaining where I mentioned
possibility of using block chaining with non-linear values,
the following is another all-or-nothing transform which is
more satisfactory in respect of security. One employs two
passes. In the first pass, use a secret IV and a secret key
K to encrypt plaintext blocks P_1, P_2, ...., P_n as follows:
S=IV
C_1 = E(K, P_1+S^2)
for i from 2 to n do
S = S + P_(i-1) + C_(i-1)
C_i = E(K, P_i+S^2)
od
In the second pass, one proceeds in the other direction, i.e.
processing from the n_th block to the first, using another
IV and another key. (Note that the present scheme keeps the
message length unaltered and n need not be even.)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A simple all-or-nothing transform
Date: Mon, 03 Jul 2000 10:22:37 +0200
David Hopwood wrote:
>
> Mok-Kong Shen wrote:
> > Let n (n even) message blocks P_1, P_2, ..., P_n be given.
> > We build their xor-sum S = Sum(P_j) j= 1, 2, ..., n.
> > Let B_i = P_i + S. Then the ciphertext blocks are given by
> > C_i = E(K, B_i).
> >
> > The receiver first decrypts to obtain B_i and computes
> > Sum(B_j) = (n+1)*S = n*S + S = S (since n is even) and can
> > subsequently recover the plaintext blocks P_i from B_i.
>
> AONTs are by definition unkeyed. If we assume therefore that K is
> known, this doesn't satisfy the security requirements for an
> all-or-nothing transform, because given one known plaintext and
> two ciphertext blocks, the unknown plaintext can be determined without
> having the rest of the ciphertext:
>
> Given K, P_i, C_i, C_j,
> S = D(K, C_i) XOR P_i
> P_j = D(K, C_j) XOR S
I don't understand why realizing an all-or-nothing transform necessitates
the use of an unkeyed scheme. We are doing encryption, aren't we?
Anyway, couldn't one drop the 'definition' of yours?
M. K. Shen
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: RE: Elliptic Curves encryption
Date: Mon, 03 Jul 2000 08:15:52 GMT
In article <[EMAIL PROTECTED]>,
TAY YUE WENG <[EMAIL PROTECTED]> wrote:
> Dear all,
> Does any body know how to make use of Elliptic Curves public key and
> private key to encrypt? I have learn how to generate the public and
> private key for EC but I don't know which algorithms to use and how to
> use for encryption and decryption purposes. Or does anybody aware of
> which website to go to? Please email me if you have some knowledge
> about it.
try www.ciphermax.com. It provides a power point tutorial and some
free EC math library software that you can use in building your
own ECC application.
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Elliott <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.security.scramdisk,uk.telecom
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: Mon, 3 Jul 2000 09:30:04 +0100
Reply-To: Simon Elliott <[EMAIL PROTECTED]>
U S-D <[EMAIL PROTECTED]> writes
[snip]
>Murrell's uncle was the guy who ordered the sinking of the Belgrano.
Who are you referring to? Commander Wreford-Brown, or some one higher up
the chain like Admiral Fieldhouse?
As I understand it, the sinking of the General Belgrano was ordered by
the UK cabinet at Chequers early on 2nd May.
>Murrell was quite prominent in the anti-Sizewell B lobby.
>
>West Mercia Constab reopened the murder investigation in late April
>when advancements in DNA technologies allowed them to analyse
>the tiny sample of semen apparently found near her body.
Interesting to see if they make any progress.
--
Simon Elliott phone : +44 (0)1444 413799
Software Consultant fax : +44 (0)870 0557822
Courtlands Technical Services email : <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: A simple all-or-nothing transform
Date: 3 Jul 2000 09:29:51 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> In the first pass, use a secret IV and a secret key K to encrypt
> plaintext blocks P_1, P_2, ...., P_n as follows:
[...]
> In the second pass, one proceeds in the other direction, i.e.
> processing from the n_th block to the first, using another
> IV and another key. (Note that the present scheme keeps the
> message length unaltered and n need not be even.)
Ah. Now you encrypt twice. This offers no advantage over Rivest's
package transform, does it?
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Decrypting MD5
Date: 3 Jul 2000 09:33:32 GMT
Boris Kazak <[EMAIL PROTECTED]> wrote:
> > Anyone know the best approach to decrypting something encrypted
> > using MD5? The key is unknown, unless of course you know where it
> > could be stored on a linux system. or how to figure it out if you
> > know how the line looks before encryption.
>
> Sorry to disappoint you, but MD5 is not a cipher.
> It is a one-way hash function, and as such it was designed
> to be non-invertible.
It's also unkeyed. There is no key to recover.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Steve Rush)
Subject: Re: Decrypting MD5
Date: 03 Jul 2000 09:55:01 GMT
>> Anyone know the best approach to decrypting something encrypted using MD5?
>> The key is unknown, unless of course you know where it could be stored on a
>> linux system. or how to figure it out if you know how the line looks before
>> encryption.
>>
>> Thanks
>-------------------------
>Sorry to disappoint you, but MD5 is not a cipher.
>It is a one-way hash function, and as such it was designed
>to be non-invertible.
Maybe he means MDC with MD5? It isn't hard to build a cypher around any
secure hash function. These cyphers can be as strong as the hash function, so
the only practical hope of breaking a given message is to find the key
somewhere. Maybe the author of the message did something stupid, like using
his birthdate for a key, or generating a good key and writing it on the bottom
of his desk drawer.
==========================================================================
==============
If it's spam, it's a scam. Don't do business with Net abusers.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Q: Implementations for DH-key exchange for >2
Date: 3 Jul 2000 10:08:52 GMT
Tom�s Perlines Hormann <[EMAIL PROTECTED]> wrote:
> Has anyone implemented Diffie-Hellman's key exchange as specified in
> PKCS#3 for 3 or more parties?
Diffie-Hellman doesn't extend easily to more than two parties. However,
there are systems, such as the Burmester-Desmedt conference keying
protocol. See, for example, protocol 12.78 in HAC (available for
download from http://www.cacr.math.uwaterloo.ca/hac/).
This isn't much more computationally expensive than Diffie-Hellman,
although it requires quite a lot of data movement. It helps if you have
a good multicast system. Also note that its two-pass nature makes it
difficult to cope with laggy players.
-- [mdw]
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: AES: It's been pretty quiet for some time...
Date: Mon, 03 Jul 2000 10:39:24 +0000
David Crick wrote:
> Just as you write this, here's latest annoucement:
>
> Preliminary information is now available for a Modes of Operation
> Workshop. [Link to] < http://csrc.nist.gov/encryption/aes/modes/ >.
Thanks a lot!
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.physics
Subject: Re: Use of EPR "paradox" in cryptography
Date: Mon, 03 Jul 2000 11:03:33 GMT
On Sun, 02 Jul 2000 18:18:14 -0400, DSM
<[EMAIL PROTECTED]> wrote, in part:
>Why haven't I heard of any use of the EPR "paradox"
>in cryptography? Is it only my poor research, or something
>else?
"Quantum Cryptography" does involve the situation which is at the
heart of the EPR paradox: recievers at two ends randomly test the
vertical or horizontal spins of particles belonging to a pair
simultaneously emitted having equal and opposite spins from a
radioactive source in the middle.
However, the fact that one measurement affects the other, yet at a
speed faster than light, is not critical for quantum cryptography (the
two recievers don't have to be precisely equidistant from the source
for crypographic purposes), and so the EPR paradox, as such, is not
always mentioned in descriptions of quantum cryptography. But it is
often referred to; for example, it is mentioned in Bruce Schneier's
"Applied Cryptography", considered the Bible of today's cryptography,
or, for that matter, on my web site.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Tying Up Lost Ends
Date: Mon, 03 Jul 2000 11:15:38 GMT
On 30 Jun 2000 16:25:17 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote, in part:
>This is based on John Savard's work
You are too generous. While the part about what I claim is the "right"
way to pack to an even number of bytes is what I believe is a standard
method that long predates my web site, the "pseudo-Morse" encoding, to
achieve a near-"one-to-one" encoding was the result of my
understanding of your posts which explained what you were doing. (And
I mention there's a special case which has to be tied up somehow.)
>However john can see that due to the nature of the files that the trailing
>1000... could ocurr anywhere in the file and that a last byte
>of 10000000 may occur about 8 out of 256 times
Actually, I'm claiming it's even worse, *32* out of 256 times.
>but what
>John failed to consider is that it is not a question of
>just freezing where the 100... string occurs but that for every
>time the last '1' occurs one more bit out there are twice as many possible
>files so in reality it does not occur 8 out of 256 times in the first
>position of a byte.
I did see others advocate this fallacy, and I replied to them. Yes,
there are twice as many 2157-bit files as there are 2156-bit files,
but this does not mean a 2157-bit message gets sent twice as often as
a 2156-bit message. If that were the case, the most common messages
would be too big to be stored on anyone's hard drive.
Think about that one a little.
You are correct that the better the compression, the better: I use
static Huffman in the example simply to keep things easier to
understand. Actually, the ideal is to use something which keeps
contact frequencies into account, but on the other hand, unlike both
the LZW method and some forms of Adaptive Huffman, both ends should
make use of an extensive starting frequency table for the messages
expected to be sent, not training on each message.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Tying Up Lost Ends III
Date: Mon, 03 Jul 2000 11:20:07 GMT
On 2 Jul 2000 13:18:58 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote, in part:
> In the previous posts two I cleaned up the lost Ends in John's work in
>the follow up I will show what he did was a waste of time and
>unfortunutly it is most likely a result of reading bad BS crypto books
>that have led him astray.
Oh, before I ever saw Bruce's book, I went to University for several
years. Although I don't recall taking information theory in class,
that certainly did help me develop the mathematical background to
understand stuff I read about it on my own time.
So I suppose you could say that I've been "led astray" more
intensively.
Of course, I was first exposed to the subject through a "crypto book",
but in this case, David Kahn's "The Codebreakers".
>So one should not directly fault him
>for his poor understanding of compression encryption and what the
>defination of random means
This is polite of you, but I'm not sure you've convinced too many
people that my understanding is lacking.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Date: Mon, 03 Jul 2000 13:30:37 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Decrypting MD5
Steve Rush wrote:
> Maybe he means MDC with MD5? It isn't hard to build a cypher around any
> secure hash function. These cyphers can be as strong as the hash function, so
> the only practical hope of breaking a given message is to find the key
> somewhere.
Eh ? Where did you get that idea from ?
A hard to predict key schedule is in no way a guarantee for a good
cipher,
just think of a cipher which uses only xor with the key, while it is
possible to form a good cipher which has no key schedule at all (for
example, one may use Twofish without doing any precomputations on the
key, computing everything in the encryption or decryption routines
itsef).
------------------------------
** 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
******************************
