Cryptography-Digest Digest #475, Volume #11 Mon, 3 Apr 00 09:13:01 EDT
Contents:
Massey-Omura protocol & ECC ([EMAIL PROTECTED])
Re: Implementation of Blowfish (Bryan Olson)
Hysteresis? ("G. R. Bricker")
Re: I will make ANY software for ANYBODY (Jerry Coffin)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: NSA ("Stou Sandalski")
Re: Newbie Question: What is a Hash Method? ("Stou Sandalski")
Re: Key exchange using Secret Key Encryption ([EMAIL PROTECTED])
Re: PGP Strength (Niklas Frykholm)
summing hashes is not safe? ([EMAIL PROTECTED])
Re: Key exchange using Secret Key Encryption ([EMAIL PROTECTED])
Re: summing hashes is not safe? ([EMAIL PROTECTED])
Re: summing hashes is not safe? (Tom St Denis)
Re: summing hashes is not safe? ([EMAIL PROTECTED])
Re: Hysteresis? ("Scotty")
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Andrew Carol)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Massey-Omura protocol & ECC
Date: Mon, 03 Apr 2000 03:54:05 GMT
Hi all,
I've been searching on http://www.patents.ibm.com/ for any patents on
massey-Omura Key exchange protocol used with ECC and I have not been
able to find a patent for it.
Is this protocol in the Public Domain or is it just not patented in US ?
Thank you for your time.
Petang
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Implementation of Blowfish
Date: Mon, 03 Apr 2000 05:06:54 GMT
Tom St Denis wrote:
> I heard CB is a cool Crypto API, it includes Blowfish among it's other
> symmetric ciphers.
Hmmm, I suggest waiting until it's better tested.
In ciphers.c we find:
extern
void blowfish_ENCRYPT(const unsigned char *plaintext,
unsigned char *ciphertext);
That declaration is contradicted by the implementation
in BLOWFISH.C, which has the type:
void blowfish_ENCRYPT(unsigned long *block,
unsigned long *out)
{ ...
It looks like it will behave differently on big-endian
than on little endian machines, and differently on C/C++
implementations where unsigned long is 32 bits than on
those in which it is longer than 32 bits.
You might pull my old Blowfish code out of the Python
Cryptography Toolkit. (I don't know of any surviving
Usenet archive that goes back far enough to have my
originally posted version, and that only included the
block functions, so it doesn't handle variable length
strings as requested.)
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "G. R. Bricker" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security.pgp
Subject: Hysteresis?
Date: Mon, 03 Apr 2000 05:32:29 GMT
I surmise that hysteresis effects would leave traces of the previous
condition of the "bit" on magnetic media. A bit which has been overwritten
once in its lifetime would probably have a measurable trace of residual
magnetism from its previous condition. However, how you would measure this
I don't know. The level would be pretty low. As for bits which have been
overwritten many times, I have absolutely no idea how each separate "write"
could be determined.
G.R. Bricker
Thor Arne Johansen <[EMAIL PROTECTED]> wrote in article
<[EMAIL PROTECTED]>...
> Hello all,
>
> "Thomas J. Boschloo" wrote:
> >
> > EE Support wrote:
> > >
> > > We contend it does not. Overwriting all zeros practically trashes
> > > files on the disk.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: I will make ANY software for ANYBODY
Date: Sun, 2 Apr 2000 23:57:57 -0600
In article <8c8hvc$pnm$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Thanks. I'd like the Windows-2000 operating system ported to the
> ENIAC. I'd like it to be finished the day after tomorrow, and this
> project should cost no more than $2. I request it to be delivered on
> ENIAC-readable paper tape. No bugs will be tolerated.
I'll be happy to take this on. Of course, you have to supply the
working ENIAC, its staff of full-time technicians to keep it running,
and (of course) getting my house wired to power it... <G> Just to
make sure the staff is up to speed, we'll need an EDSAC, an EDVAC and
a Mark I for a month ahead of time as well...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Sun, 02 Apr 2000 23:40:03 -0700
Taneli Huuskonen wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In <[EMAIL PROTECTED]> Anthony Stephen Szopa
> <[EMAIL PROTECTED]> writes:
>
> [...]
> >It is interesting to hear that you have written an algorithm that
> >you claim shows a weakness in the random digit generator.
>
> I even posted the source code. However, as I added a few comments while
> posting it, I forgot to close two of them near the beginning:
>
> #define BLOCKLEN 1000 /* can be
> #define NBLOCKS 100 /* 100 is enough
>
> This should read:
>
> #define BLOCKLEN 1000 /* can be anything > 10 */
> #define NBLOCKS 100 /* 100 is enough in practice */
>
> [...]
>
> >Please let us know the answer to these very few and very simple
> >questions?
>
> I'm not going to jump through your hoops. My source code contains the
> answers to all the relevant questions. You can either test it yourself
> or bury your head in the sand. The choice is yours.
>
> In my own testing, my programme correctly predicted tens of thousands of
> unknown digits, using the posted values for NBLOCKS and BLOCKLEN. With
> both BLOCKLEN and NBLOCKS equal to 100, the number of predicted digits
> was consistently above 2000. Every predicted value was checked; there
> were no incorrect predictions whatsoever.
>
> The programme takes as input BLOCKLEN * NBLOCKS known digits, which are
> among the first 10! * NBLOCKS output values of the PRNG.
>
> Taneli Huuskonen
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 5.0i for non-commercial use
> Charset: noconv
>
> iQA/AwUBOOcuJF+t0CYLfLaVEQJlfACeM2fUzonOdxhtaYI1uPm9QQUOig4AoOyo
> XZHD+/vyfcsD3orZmTVd79BA
> =K7oI
> -----END PGP SIGNATURE-----
> --
> I don't | All messages will be PGP signed, | Fight for your right to
> speak for | encrypted mail preferred. Keys: | use sealed envelopes.
> the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
The only way you can claim to have proved anything is to accept
from me a raw random digit stream from the random digit generator
(generated from an unknown key) from me, and using only this
random digit stream you must predict all subsequent digits. (A
reasonable number will suffice.)
This is why I asked you how many raw random digits you will need.
I asked you whether or not you had either OAP-L3 or OAR-L3 so we
can be assured that you may at least have checked your findings
against the actual software and not merely what you think the
software does.
I'll ask you again: how many raw random digits from the random
digit generator will you need? I will supply them. You can
then give us what you have determined to be the subsequent
raw random digits from the random digit generator.
Then I will provide the key for the software where we all can see
that the random digits I gave you were in fact the ones generated
from the software using this key.
If your predictions are correct then we will all see this.
I think this is perfectly legitimate. It is a verifiable test.
It is direct and to the point. No way to BS. The facts will
speak for themselves.
After all, you are the one who said you had something to prove
regarding a flaw in the OAP-L3 software. You must prove it and
this is the most direct way to do it unless you do not think you
can do it.
You don't like this?
It is time to put up or shut up.
Nothing could be easier and quicker than to do this for all of us.
Now, for any of those interested, Version 4.3 will be available
very soon. Here are the additions to OAP-L3 in Version 4.3:
1) you will get two more random number generators: they are
exactly the same as the current one where only MixFile1 is
rotated except that PRNG2 will only rotate MixFile2, and PRNG3
will only rotate MixFile3.
2) you will get several other processes:
you will be able to scramble every subsequent set of 14 arrays in a
MixFile to any one of 14! sequences
you will be able to reverse the order of each element in each array
in a MixFile
you will be able to reverse the byte sequence of an entire MixFile.
(Keep in mind that each MixFile is compressed using BCD so each
byte contains information for two digits.)
you will be able to reverse the array sequence of an entire MixFile
you will be able to add 1 - 9 to each element in all arrays in a
MixFile
you will be able to shift all elements in each array in an entire
MixFile
These additional processes will greatly increase the possibilities
of ordering the MixFiles thus making the MixFiles that much more
difficult to determine
The additional PRNGs will provide more random numbers from which
to create the OTPs, again making predicting the OTPs that more
improbable.
(I like to say that much more impossible.)
------------------------------
From: "Stou Sandalski" <tangui [EMAIL PROTECTED]>
Subject: Re: NSA
Date: Mon, 3 Apr 2000 00:00:15 -0700
"Gary Watson" <[EMAIL PROTECTED]> wrote in message
news:sFIF4.5222$[EMAIL PROTECTED]...
<snip>
> Oddly, the mousepad is 10" in diameter, which is huge. Do you suppose
they
> have special mice at NSA?
>
well I supposed they do have special mice... probably gigantic mice to fit
into the big hands of the NSA employees... hehe you know what they say about
guys with big hands don't you?... they wear big gloves... but maybe the
extreaterrestrials working for the nsa are creatures with big hands so they
proly had to design big mice for them ; )
Stou
------------------------------
From: "Stou Sandalski" <tangui [EMAIL PROTECTED]>
Subject: Re: Newbie Question: What is a Hash Method?
Date: Mon, 3 Apr 2000 00:11:20 -0700
If its the same md5sum program I have it can take data from either a file or
stdin.. try typing something like md5sum /? or md5sum -? or /help or
whatever and see what happens also you can try giving it a file as an
argument or a garbage string and it should output a bunch of crap... like I
get this
C:\SourceCode C++\MD5\Debug>mddriver mddriver.exe
MD5 (mddriver.exe) = ea935f296510f6ecc17d864b37b62376
I doubt you can learn much from just using the program... but it is useful.
Stou
"K. O. Marinely" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Vinchenzo" <[EMAIL PROTECTED]> wrote:
>
> >I would like to know what is a hash method? Is it like a subkey
generation?
>
> One of the version 2.6.3 releases of PGP includes a program called
> MD5SUM.EXE, which is apparently a program to generate MD5 hashes, however
I
> can't figure out how it works and I couldn't find any documentation for it
> in the Zip file. It could be useful for learning about hashes if someone
> here can tell us where to get it and how to use it.
> --
> "K. O. Marinely" is actually 2507 639814 <[EMAIL PROTECTED]>.
> 0 1 23456789 <- Use this key to decode my email address and name.
> Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Key exchange using Secret Key Encryption
Date: Mon, 03 Apr 2000 08:02:14 GMT
In article <8c3psb$alm$[EMAIL PROTECTED]>,
zapzing <[EMAIL PROTECTED]> wrote:
> Why in the world would two complete strangers
> want to exchange encrypted information ???
> What could they possibly have to say to
> each other? Surely you are not thinking
> of starting a secret cabal with a
> complete stranger. that is not recommended.
>
> And why can't public key
> encryption be used? It seems to
> be the *only* solution to this
> (rather strange) problem.
Ever heard of e-commerce? Two complete strangers (customer and vendor)
will definately want to exchange encrypted information such as billing
info, addresses etc. There are plenty of other examples.
Public key encryption is too slow to be used for encrypting messages or
streams. Instead, you use it to encrypt the symmetric keys used for the
actual session encryption, and for creating signatures.
Public key encryption does not solve the problem here though, since you
still need a secure way of transfering the public key. (If someone
claims to be Alice and gives me a public key, how do I know it really is
Alice's and not Mallot's?)
-Erik Runeson
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Niklas Frykholm)
Subject: Re: PGP Strength
Date: 3 Apr 2000 09:13:15 GMT
> In the documentation for PGP, I read that it uses ZIP Compression to
>generate smaller files and thus less predicatble contents, but does this not
>mean tht the files will contain a standard Header(Not Nesscerily "PK" but
>some sort of Table that that LZW Compression needs), or does it do this
>outside the Encrypted Area, either way I cannot see the ZIP Compression
>Improving the strength because using both you are able to predict the
>contents even better in my mind.
I think it is best to see compression as a way of speeding up
encryption/decryption and message transfer and not as a way of increasing
security. If you want to do that, it is better to use stronger encryption,
because compression algorithms are not designed with cryptographic concerns in
mind.
As you say, the compressed file should not contain headers or other easily
identifiable structures (I'm not sure how PGP handles this), but even if it does
this is perhaps not such a big deal, since modern cryptosystems are designed to
be secure against known-plaintext attacks.
If we look at key search attacks, the claim that compression increases security
is doubtful (even if we ignore the problem with headers). The important question
here is how quickly we can distinguish valid messages from garbage. Compression
does not necessarily make this much harder, because we can create a lookup table
for the first few bytes of valid compressed messages, just as easy as for valid
uncompressed messages. Also, decompression is usually a quick procedure.
Prepending some random bytes might improve the situation, but still I think it
is better to address security concerns in the encryption algorithm.
// Niklas
------------------------------
From: [EMAIL PROTECTED]
Subject: summing hashes is not safe?
Date: Mon, 03 Apr 2000 09:44:49 GMT
Just came across some code in which multiple (100's) 20 byte message-
digests are summed into one 24 byte sum as a hash for the complete
batch.
Something tells me this is not the way to handle (SHA-1) hashes. Can
anyone confirm my feeling that it's fairly easy to add fake messages?
Mike
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Key exchange using Secret Key Encryption
Date: Mon, 03 Apr 2000 11:06:47 GMT
In article <8c9j60$9oh$[EMAIL PROTECTED]>,
> Public key encryption does not solve the problem here though, since
> you still need a secure way of transfering the public key. (If
> someone claims to be Alice and gives me a public key, how do I know
> it really is Alice's and not Mallot's?)
>
> -Erik Runeson
This is a problem, but not necessarily as big a problem as with a
secret key exchange. Anyone who intercepts a secret key may both
intercept and forge any further message encrypted using that key. But
you can be pretty certain that only the person who initially set
up "Alice's" (be that the real life Alice, Mallot or anyone else)
public key will have the corresponding private key.
Hence if (the person under the internet pseudonyme) "Alice" fills in an
order form and provides both payment and a shipping address and signs
the order with an assymmetric DSS scheme, you can be certain that the
person who payed (whoever that is in real life) wanted the goods to be
delivered to the shipping address. You cannot even be sure of that if
the form was encrypted with a secret key that was initially transferred
over the internet.
/Henrick Hellstr�m
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: summing hashes is not safe?
Date: Mon, 03 Apr 2000 11:20:18 GMT
In article <8c9p6f$g08$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
>
> Just came across some code in which multiple (100's) 20 byte message-
> digests are summed into one 24 byte sum as a hash for the complete
> batch.
> Something tells me this is not the way to handle (SHA-1) hashes. Can
> anyone confirm my feeling that it's fairly easy to add fake messages?
> Mike
I might be unaware of some of the weaknesses of SHA-1, but it does not
seem to be "fairly easy" to add fake messages. The only _easy_ attack I
can think of is one that changes the order of the messages. Such an
attack will work since a + b = b + a.
In order to add a fake message m', you will have to exchange at least
one of the original messages for one with a desired hash value (that
makes the sum unchanged), and that is, as far as I know, thought of
being exactly as impossible as it is true SHA-1 is a one way function.
/Henrick Hellstr�m
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: summing hashes is not safe?
Date: Mon, 03 Apr 2000 11:41:27 GMT
[EMAIL PROTECTED] wrote:
>
> Just came across some code in which multiple (100's) 20 byte message-
> digests are summed into one 24 byte sum as a hash for the complete
> batch.
> Something tells me this is not the way to handle (SHA-1) hashes. Can
> anyone confirm my feeling that it's fairly easy to add fake messages?
> Mike
If you had two hashes such that a = -b, then they cancel each other out
when you simply sum them. That means they have no effect, and I can
change those two hashes.
Pratically finding a H(M) = a and H(M') = -b is tough work though.
Personally I would just hash the collection of hashes to get another 20
byte SHA-1 hash.
Tom
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: summing hashes is not safe?
Date: Mon, 03 Apr 2000 12:03:57 GMT
In article <8c9up8$lkp$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <8c9p6f$g08$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> >
> >
> > Just came across some code in which multiple (100's) 20 byte
message-
> > digests are summed into one 24 byte sum as a hash for the complete
> > batch.
> > Something tells me this is not the way to handle (SHA-1) hashes. Can
> > anyone confirm my feeling that it's fairly easy to add fake
messages?
> > Mike
>
> I might be unaware of some of the weaknesses of SHA-1, but it does not
> seem to be "fairly easy" to add fake messages. The only _easy_ attack
I
> can think of is one that changes the order of the messages. Such an
> attack will work since a + b = b + a.
>
> In order to add a fake message m', you will have to exchange at least
> one of the original messages for one with a desired hash value (that
> makes the sum unchanged), and that is, as far as I know, thought of
> being exactly as impossible as it is true SHA-1 is a one way function.
>
> /Henrick Hellstr�m
>
In this case there is a limitation of 24 bytes to the sum. So if a+b >
24 bytes (very likely) information of the hashes is lost.
In this case a few 100 message-hashes are added.
How hard is it to construct (multiple) messages which are added to
match the same sum of the orignal hashes?
The summed hash is checked first, then the messages are decoded; bogus
messages are discarded.
Mike
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Scotty" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security.pgp
Subject: Re: Hysteresis?
Date: Mon, 3 Apr 2000 13:25:08 +0100
G. R. Bricker wrote in message <01bf9d2d$df081040$4b06ebd0@default>...
>I surmise that hysteresis effects would leave traces of the previous
>condition of the "bit" on magnetic media. A bit which has been overwritten
>once in its lifetime would probably have a measurable trace of residual
>magnetism from its previous condition. However, how you would measure this
>I don't know. The level would be pretty low. As for bits which have been
>overwritten many times, I have absolutely no idea how each separate "write"
>could be determined.
> G.R. Bricker
When a 1 overwrites a 1 you get about 1.05 and 0.95 when it overwrites a 0.
The drive circuitry digitises that to give 1. That 10% difference is easy to
measure if you sample it with an oscilloscope before the signal is processed
by the drive circuitry. This is not rocket science.
>
>Thor Arne Johansen <[EMAIL PROTECTED]> wrote in article
><[EMAIL PROTECTED]>...
>> Hello all,
>>
>> "Thomas J. Boschloo" wrote:
>> >
>> > EE Support wrote:
>> > >
>> > > We contend it does not. Overwriting all zeros practically trashes
>> > > files on the disk.
>
------------------------------
From: Andrew Carol <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Mon, 03 Apr 2000 05:54:34 -0700
In article <[EMAIL PROTECTED]>, Anthony Stephen Szopa
<[EMAIL PROTECTED]> wrote:
> The only way you can claim to have proved anything is to accept
> from me a raw random digit stream from the random digit generator
> (generated from an unknown key) from me, and using only this
> random digit stream you must predict all subsequent digits. (A
> reasonable number will suffice.)
I don't think he promises to find ALL subsequent digits. I think he
says he can predict with 100% accuracy some percentage of the following
digits. That is, on a digit-by-digit digit basis, he either does not
know the next digit, or he knows it with 100% certainty and will
predict it in advance.
If true that is effectivly FATAL to your system becuase that means that
some percentage of a file will "leak" and I'm sure no customer would
want people to figure out what their secret files are because a few
hundred characters of their file became known through a simple system.
> (I like to say that much more impossible.)
So, because he may have cracked this "impossible" system you've come up
with a MORE impossible system? That's choice.
Oh well.....
------------------------------
** 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
******************************
