Cryptography-Digest Digest #139, Volume #14 Sat, 14 Apr 01 07:13:01 EDT
Contents:
Re: NSA-Endorsed Schools have a Mediocre Internet Presence ("Douglas A. Gwyn")
Re: MD5 flaws (miathan)
Re: Graphical representation of a public key (or fingerprint)? ("Matt Timmermans")
Prime generation ("Benjamin Johnston")
Re: RSA CRT key? (massimo piccinetti)
Re: NSA-Endorsed Schools have a Mediocre Internet Presence (Mok-Kong Shen)
Re: Graphical representation of a public key (or fingerprint)? (Mok-Kong Shen)
Re: Prime generation (Mok-Kong Shen)
Re:_finally do "something" good. (kctang)
Re: XOR TextBox Freeware: Very Smooth. (Anthony Stephen Szopa)
Re: XOR TextBox Freeware: Very Lousy. (Anthony Stephen Szopa)
Re: Prime generation ("Peter L. Montgomery")
Re: Prime generation ("Henrick Hellstr�m")
Re: Prime generation ("Henrick Hellstr�m")
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA-Endorsed Schools have a Mediocre Internet Presence
Date: Sat, 14 Apr 2001 05:37:39 GMT
Mok-Kong Shen wrote:
> I think that the significance of that gap is also rapidly
> decreasing with time, since the common people can, if
> they want, now encrypt with such security that it is
> almost certain that the agencies couldn't crack.
Hm. Why are they still in business (with satisfied customers,
apparently).
------------------------------
From: miathan <[EMAIL PROTECTED]>
Subject: Re: MD5 flaws
Date: Sat, 14 Apr 2001 06:18:47 GMT
> It's a little old, so there may be more recent results, but
> see
>
> Hans Dobbertin "The Status of MD5 After a Recent
> Attack", Cryptobytes vol 2 number 2, Summer 1996.
Thanks... that seems to be what I was looking for.
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Graphical representation of a public key (or fingerprint)?
Date: Sat, 14 Apr 2001 06:46:15 GMT
True. I think 33 bits is pretty good for a recognition (as opposed to a
comparison). The decorative features are a good idea, too, and so are
family portraits. You wan't to cram as much in there as you can without it
getting too confusing, to maximize the amount of information that someone
might remember about the fingerprint. After all, you don't have to remember
everything -- only enough to make it difficult to create a key that will
fool you.
Where practical, it would also be good if everybody's fingerprint-producing
software hashed the key with a different secret salt value. This would make
effective forgery pretty much impossible, because a forger would have no way
to check his work.
I think there is a big problem with this whole scheme, though -- people
won't want ugly keys.
"John Myre" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I like this, but I'm not sure one face is enough. It only takes 33
> bits or so to count every human face there is, and clearly some faces
> look pretty much alike. (Granted, the humans that exist don't span the
> potential faces. But the order-of-magnitude problem still exists.)
>
> We can allow more variability: cartoon faces or aliens can work as well.
> Other bits can be used to generate decorative features, like scars,
> hats,
> earrings, and the like. But we have to watch out for human inattention:
> "oh, I didn't realize the lipstick was missing!", or "gee - all those
> Klingon faces look alike to me, anyway". I would predict that a "family
> portrait" would work better; it allows the information to be partitioned
> so each individual face is more easily distinguished when changed.
>
> JM
------------------------------
From: "Benjamin Johnston" <[EMAIL PROTECTED]>
Subject: Prime generation
Date: Sat, 14 Apr 2001 17:09:35 +1000
Hi,
I was thinking,
Schneier's book suggests one approach to generating a prime, where you start
with a random number and begin searching from that point until a prime is
found.
I assume that because there might be a long run of composites in some
ranges, that some primes would be more likely than others with this
approach, and others (eg. the second prime in a pair) might be highly
unlikely.
I'm sure it has to be a very minor issue, but would anybody be able to offer
pointers to documents that discuss this kind of thing?
-Benjamin Johnston
[EMAIL PROTECTED]
------------------------------
From: massimo piccinetti <[EMAIL PROTECTED]>
Subject: Re: RSA CRT key?
Date: Sat, 14 Apr 2001 07:30:38 GMT
Thanks to all.
now i'm going to programm my JavaRing.
massimo piccinetti wrote:
> Hello,
> can you tell me where i can find
> the documentation of the algorithm ([Mil76])
> to convert a RSAPrivateKey (modulus + private exponent only)
> to a RSAPrivateCRTKey (modulus, exponent, p, q etc..)
>
> thanks
>
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NSA-Endorsed Schools have a Mediocre Internet Presence
Date: Sat, 14 Apr 2001 10:26:41 +0200
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > I think that the significance of that gap is also rapidly
> > decreasing with time, since the common people can, if
> > they want, now encrypt with such security that it is
> > almost certain that the agencies couldn't crack.
>
> Hm. Why are they still in business (with satisfied customers,
> apparently).
Business is a social phenomenon, which depends on many
(non-natural-science) factors and is generally hardly
'guided' by reasons (logics). Look at the recent spectacular
rise and fall of stocks. The art of a successful
businessman lies in creating more customer satisfaction
than his competitors, using psychology and what not. Does
anyone in the public know for sure the 'marketing' strategies
of the agencies?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Graphical representation of a public key (or fingerprint)?
Date: Sat, 14 Apr 2001 10:26:49 +0200
Matt Timmermans wrote:
>
> True. I think 33 bits is pretty good for a recognition (as opposed to a
> comparison). The decorative features are a good idea, too, and so are
> family portraits. You wan't to cram as much in there as you can without it
> getting too confusing, to maximize the amount of information that someone
> might remember about the fingerprint. After all, you don't have to remember
> everything -- only enough to make it difficult to create a key that will
> fool you.
You might be able to say that a picture belongs to a
certain not too small class but I doubt that it suffices
for 'identification', i.e. recognition for sure. Maybe
the best would be of the quality of 'phantom' pictures
of the police.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Prime generation
Date: Sat, 14 Apr 2001 10:26:55 +0200
Benjamin Johnston wrote:
>
> I assume that because there might be a long run of composites in some
> ranges, that some primes would be more likely than others with this
> approach, and others (eg. the second prime in a pair) might be highly
> unlikely.
The long runs are not 'predictable', if I don't err.
Hence one could not develop a strategy exploiting
such things.
M. K. Shen
------------------------------
From: kctang <[EMAIL PROTECTED]>
Subject: Re:_finally do "something" good.
Date: Sat, 14 Apr 2001 16:27:28 +0800
"AY" <[EMAIL PROTECTED]> wrote in
<9b4smh$dte$[EMAIL PROTECTED]>:
> I happen to know crypto is not bad at HKU.
How did it happen?
>Any views on Chinese University in Hong Kong, Mr Tang?
[ .. .. .. ]
>For others this is a good place to start:
> http://www.counterpane.com/courses.html
See also
http://avirubin.com/courses.html
http://theory.lcs.mit.edu/~rivest/crypto-security.html#Universities
The academic circle is not as "simple" as once I thought of.
Take care of yourself, TOM.
Best Regards, kctang
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: XOR TextBox Freeware: Very Smooth.
Date: Sat, 14 Apr 2001 02:28:53 -0700
Sam Simpson wrote:
>
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > XOR TextBox is similar to its predecessor, XOR Utility Version 1.1,
> > that simply performs the universally available logical XOR process
> > on two files chosen by the user and outputs the resulting file.
> >
> > The difference is that XOR TextBox provides a textbox control for
> > input and output. This textbox control can be used in two ways.
> >
> > First, a user can type text directly into the textbox and run the XOR
> > process on this text and another file, outputting the resulting file.
> >
> > Or secondly, a file that has previously been through the XOR process
> > using XOR TextBox can be reprocessed again with XOR TextBox and the
> > result displayed directly into the textbox for viewing.
> >
> > Either way, at no time is the original text ever written to disk. In
> > both cases the original text is merely stored in RAM.
> >
> > http://www.ciphile.com
> >
> > Downloads Currently Available web page
> > VB6 Downloads web page
>
> I downloaded your software, encrypted some text with the random passphrase
> "Q8XUYZ�3P_R". Booted into DOS an searched the swap file and this same
> passphrase appears in its entirety.
>
> Explain? ;)
>
> (Machine: An aging P166 w/16Mb RAM running (just ;) Win95)
>
> --
> Regards,
>
> Sam
> http://www.scramdisk.clara.net/
I'll byte.
What do you mean: "...encrypted some text with the random passphrase
"Q8XUYZ�3P_R..."? Do you want me to guess?
And what is that funny symbol in your "passphrase" after the "z?"
What are the implications when you use such a symbol?
Try typing, "The American crew has returned." and search for this
using your method.
If you can't find it then give us a suggestion why.
Let us know if you found it.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: XOR TextBox Freeware: Very Lousy.
Date: Sat, 14 Apr 2001 02:44:50 -0700
"Ryan M. McConahy" wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > Either way, at no time is the original text ever written to disk.
> > In both cases the original text is merely stored in RAM.
>
> That doesn't matter. XOR is wimpy.
>
> *Pulls out his electronic copy of Applied Cryptography*
>
> - From Bruce Schneier's Applied Cryptography, Chapter 1, Section 1.4:
>
> "The simple-XOR algorithm is really an embarrassment; it's nothing
> more than a Vigen�re polyalphabetic cipher. It's here only because
> of its prevalence in commercial software packages, at least those
> in the MS-DOS and Macintosh worlds [1502,1387]. Unfortunately, if a
> software security program proclaims that it has a "proprietary"
> encryption algorithm-significantly faster than DES-the odds are
> that it is some variant of this.
>
> /* Usage: crypto key input_file output_file */
>
> void main (int argc, char *argv[])
>
> {
> FILE *fi, *fo;
> char *cp;
> int c;
>
> if ((cp = argv[1]) && *cp!='\0') {
> if ((fi = fopen(argv[2], "rb")) != NULL) {
> if ((fo = fopen(argv[3], "wb")) != NULL) {
> while ((c = getc(fi)) != EOF) {
> if (!*cp) cp = argv[1];
> c ^= *(cp++);
> putc(c,fo);
> }
> fclose(fo);
> }
> fclose(fi);
> }
> }
> }"
>
> And a little further down the ePage:
>
> "There's no real security here. This kind of encryption is trivial
> to break, even without computers [587,1475]. It will only take a
> few seconds with a computer.
>
> Assume the plaintext is English. Furthermore, assume the key length
> is any small number of bytes. Here's how to break it:
>
> 1. Discover the length of the key by a procedure known as counting
> coincidences [577]. XOR the ciphertext against itself shifted
> various numbers of bytes, and count those bytes that are equal. If
> the displacement is a multiple of the key length, then something
> over 6 percent of the bytes will be equal. If it is not, then less
> than 0.4 percent will be equal (assuming a random key encrypting
> normal ASCII text; other plaintext will have different numbers).
> This is called the index of coincidence. The smallest displacement
> that indicates a multiple of the key length is the length of the
> key.
> 2. Shift the ciphertext by that length and XOR it with itself.
> This removes the key and leaves you with plaintext XORed with the
> plaintext shifted the length of the key. Since English has 1.3 bits
> of real information per byte (see Section 11.1), there is plenty of
> redundancy for determining a unique decryption.
> Despite this, the list of software vendors that tout this toy
> algorithm as being "almost as secure as DES" is staggering [1387].
> It is the algorithm (with a 160-bit repeated "key") that the NSA
> finally allowed the U.S. digital cellular phone industry to use for
> voice privacy. An XOR might keep your kid sister from reading your
> files, but it won't stop a cryptanalyst for more than a few
> minutes."
>
> The only thing (in crypto) XOR is good for is for one time pads, in
> which it is more secure
> than anything ever invented.
>
> Ryan M. McConahy
>
> -----BEGIN PGP SIGNATURE-----
> Version: 6.5.8ckt http://www.ipgpp.com/
>
> iQA/AwUBOtc0QaFn8yalvjU2EQIOHQCgxlwNASr0LQsb1wqIKr94rlyvtkEAoJvO
> DTg+vQ7p+EMKFCQPFQqCRK/u
> =sUUG
> -----END PGP SIGNATURE-----
Who are you trying to convince, the dead? And what are you trying to
convince them of, that they're still dead?
If the file you use to XOR your original file is random or appears
random to any cracker then the cracker cannot reverse the XORed file.
You cannot get any better security than this. With XOR_TextBox I
leave it to you to generate or obtain a "random" file for this
purpose.
"Here, everybody. I've got it in a book. It says it right here:
"Turn off your minds." This claptrap sounds so convincing, doesn't
it?"
You offer this source code tripe that has no bearing on the
randomness of the file one uses in the XOR process.
I tell you what: if you are so confident, offer people in these
news groups a $1000 each if you fail to crack their XORed files
using XOR_TextBox.
Hey, you got it in a book. Now put your money behind it.
------------------------------
From: "Peter L. Montgomery" <[EMAIL PROTECTED]>
Subject: Re: Prime generation
Date: Sat, 14 Apr 2001 09:42:25 GMT
In article <9b8sve$vge$[EMAIL PROTECTED]>
"Benjamin Johnston" <[EMAIL PROTECTED]> writes:
>
>Hi,
>
>I was thinking,
>
>Schneier's book suggests one approach to generating a prime, where you start
>with a random number and begin searching from that point until a prime is
>found.
>I assume that because there might be a long run of composites in some
>ranges, that some primes would be more likely than others with this
>approach, and others (eg. the second prime in a pair) might be highly
>unlikely.
>I'm sure it has to be a very minor issue, but would anybody be able to offer
>pointers to documents that discuss this kind of thing?
If you are concerned about this, choose an arithmetic
progression other than consecutive integers. For example, start with
a = 2*3*5*7*11*13* ... *197*199
This product of primes is about exp(200) ~= 10^88 ~= 2^290
(actually closer to 10^82).
Choose b coprime to a (about 10% of all potential b will work).
If you look at the arithmetic progression a*x + b,
and want a 512-bit prime, you have over 2^200 potential choices for x.
You can include some primes > 200 in the product defining a so even
the constant difference in the arithmetic progression is unpredictable.
Randomly choose some x of the proper size until you get a probable prime.
The density of primes will be about 10/ln(2^512) ~= 0.03
since you have pre-eliminated multiples of primes < 200.
--
The 21st century is starting after 20 centuries complete,
but we say someone is age 21 after 21 years (plus fetus-hood) complete.
[EMAIL PROTECTED] Home: San Rafael, California
Microsoft Research and CWI
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Prime generation
Date: Sat, 14 Apr 2001 12:18:27 +0200
"Mok-Kong Shen" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
>
>
> Benjamin Johnston wrote:
> >
>
> > I assume that because there might be a long run of composites in some
> > ranges, that some primes would be more likely than others with this
> > approach, and others (eg. the second prime in a pair) might be highly
> > unlikely.
>
> The long runs are not 'predictable', if I don't err.
> Hence one could not develop a strategy exploiting
> such things.
Yes and no. You could e.g. use a counter and generate a new random number
when the counter exceeds a pre defined threshold value. As far as I have
tested this approach, it is on average slower than the standard Miller-Rabin
approach, but it is better at its worst.
DSA prime generation is based on the generation of new pseudo random values
each cycle of the process.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Prime generation
Date: Sat, 14 Apr 2001 12:30:31 +0200
"Peter L. Montgomery" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> In article <9b8sve$vge$[EMAIL PROTECTED]>
> "Benjamin Johnston" <[EMAIL PROTECTED]> writes:
> >
> >Hi,
> >
> >I was thinking,
> >
> >Schneier's book suggests one approach to generating a prime, where you
start
> >with a random number and begin searching from that point until a prime is
> >found.
>
> >I assume that because there might be a long run of composites in some
> >ranges, that some primes would be more likely than others with this
> >approach, and others (eg. the second prime in a pair) might be highly
> >unlikely.
>
> >I'm sure it has to be a very minor issue, but would anybody be able to
offer
> >pointers to documents that discuss this kind of thing?
>
> If you are concerned about this, choose an arithmetic
> progression other than consecutive integers. For example, start with
>
> a = 2*3*5*7*11*13* ... *197*199
>
> This product of primes is about exp(200) ~= 10^88 ~= 2^290
> (actually closer to 10^82).
> Choose b coprime to a (about 10% of all potential b will work).
> If you look at the arithmetic progression a*x + b,
> and want a 512-bit prime, you have over 2^200 potential choices for x.
> You can include some primes > 200 in the product defining a so even
> the constant difference in the arithmetic progression is unpredictable.
>
> Randomly choose some x of the proper size until you get a probable
prime.
> The density of primes will be about 10/ln(2^512) ~= 0.03
> since you have pre-eliminated multiples of primes < 200.
I guess that the point is that p = a*x + b will not be divisible by any
small prime, since a is product of small primes and GCD(a,b) = 1. By trial
division by small primes is rarely what slows prime generation down. It is
the modular exponentiations that take time, and even multi precision GCD
calculation is in most cases slower than trial division. Do you have any
test results?
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
** 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
******************************
