Cryptography-Digest Digest #121, Volume #10 Fri, 27 Aug 99 14:13:02 EDT
Contents:
Re: NEW THREAD on compression
Re: (fwd)Factorization of RSA-155 (DJohn37050)
Re: 512 bit number factored (DJohn37050)
Re: 2 person data exchange - best method? (Anton Stiglic)
Re: 512 bit number factored (Anton Stiglic)
Re: 512 bit number factored (Jean-Jacques Quisquater)
Re: CryptoAPI (Greg)
Re: NEW THREAD on compression (SCOTT19U.ZIP_GUY)
Re: 512 bit number factored (Boudewijn W. Ch. Visser)
Re: Can americans export crypto when in another country? (SCOTT19U.ZIP_GUY)
Re: receiving a piece of message (SCOTT19U.ZIP_GUY)
RE: receiving a piece of message (SCOTT19U.ZIP_GUY)
How to apply for security clearance? ([EMAIL PROTECTED])
Re: 512 bit number factored (Paul Koning)
Re: passphrases (Justin Scribner)
Re: Where to find (SCOTT19U.ZIP_GUY)
Re: Can americans export crypto when in another country? (John)
Re: Can americans export crypto when in another country? (Medical Electronics Lab)
Re: 512 bit number factored (David A Molnar)
Re: Can americans export crypto when in another country? (John)
Re: Can americans export crypto when in another country? (John)
Re: Can americans export crypto when in another country? (wtshaw)
Re: 512 bit number factored (Boudewijn W. Ch. Visser)
Re: Key to Ciphertext Ratio's (wtshaw)
Re: How to apply for security clearance? (Jean-Jacques Quisquater)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: NEW THREAD on compression
Date: 27 Aug 99 14:20:00 GMT
Mok-Kong Shen ([EMAIL PROTECTED]) wrote:
: You are considering using compression as sort of encryption. But
: I am adopting the (I suppose) more common view that compression and
: encryption are orthogonal. Compression helps the encryption but
: I assume that, once the analyst correctly decrypts by using the
: correct key, properly doing decompression is no problem for him.
Granting that last assumption, which _is_ a proper assumption, it still
makes it easier to find that correct key if there are _any_ biases in the
compressed text.
Compression is _not_ a secure form of encryption, but it can be tailored
to provide the maximum possible assistance to encryption by providing the
fewest possible identifiable plaintext characteristics for a
ciphertext-only attack to operate on.
: Yes, this works if the sole purpose is compression/decompression.
: But if this stuff is encrypted and decrypted back with a wrong key,
: you wouldn't have the proper length information. This, according
: to Mr. Scott's reasoning, is bad, because it immediately tells him
: that the key he has employed is wrong.
At least one has to go through the whole message, from start to finish, to
find that the wrongly deciphered message has ended in the middle of a
symbol.
But I'll think about it and see if I can do better.
John Savard
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: (fwd)Factorization of RSA-155
Date: 27 Aug 1999 15:20:26 GMT
There are also comments on factoring RSA 155 on www.certicom.com
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: 512 bit number factored
Date: 27 Aug 1999 15:22:53 GMT
Also look at
http://www.certicom.com/press/rsa-155.htm for more analysis of the results.
Don Johnson
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: 2 person data exchange - best method?
Date: Fri, 27 Aug 1999 11:26:36 -0400
A pseudo random function generator PRFG. Alice and Bob pick a
function f() from a PRFG, when they are seperated and want to
authenticate
themselves, say Alice picks a random value x, gives it to Bob and Bob
computes f(x) and gives this back to Alice. Alice and Bob do this
several
times, to the point of view of Oscar, f(x) seems random. And even if he
collects x1,f(x1), x2,f(x2), ... xn, f(xn), this doesn't help him to
compute
f(x) from x (if x is different from x1, x2, .., xn), and doesn't help
him to
authenticat himself to Alice beacause Alice picks her x at random (doing
it a couple of times, you can get great probability that she doesn't
stumble
on an x that was already sent to Bob).
You could think of a man in the middle attack, where Oscar, wanting to
authenticat himself as Bob to Alice, gets the x from Alice and asks Bob
to compute the answer, but Bob should only answer questions if _he_ is
the initiator of the scheme. You should be carefull here. Anyways, it's
not
trivial, but I hope I have gave you some ideas for you to further
research
on....
as
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: 512 bit number factored
Date: Fri, 27 Aug 1999 11:42:23 -0400
DJohn37050 wrote:
> Also look at
> http://www.certicom.com/press/rsa-155.htm for more analysis of the results.
> Don Johnson
I guess you ment:
http://www.certicom.com/press/RSA-155.htm
------------------------------
From: Jean-Jacques Quisquater <[EMAIL PROTECTED]>
Subject: Re: 512 bit number factored
Date: Fri, 27 Aug 1999 17:47:59 +0200
correct link is http://www.certicom.com/press/RSA-155.htm
:-)
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: CryptoAPI
Date: Fri, 27 Aug 1999 16:01:09 GMT
> Want my opinion? Don't use MS crypto libs...
And for another reason- the crypto API provider DLLs require a
signature that comes from Redmond. If you look at the signature
request forms from Microsoft, and the forms for the CryptAPI SDK, you
will see that they look like gun registration forms. So I think this
has had a serious impact on the acceptance of using the CryptAPI in
general. I have my opinion as to why this was done, but the fact is it
was done and it looks discouraging to developers.
--
Red Dawn- "What makes us better than them?" "We live here!"
Wallace on Brave Heart- "While you stand around and bicker,
I am going to take the fight to the [king's back yard]."
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NEW THREAD on compression
Date: Fri, 27 Aug 1999 17:22:03 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>SCOTT19U.ZIP_GUY wrote:
>
>> Yes if you use the "random added feature" yes you can do I think
>> what you are saying. But to me we pretend the enemy knows all but
>> the key and the message That means the enemy knows what you did for random
>> numbers. Or you have to consider the means of adding in a random
>> feature as part of the encryption. But these are my views if you want to
>> call the random feature part of compression fine.
>
>Thanks for your comment. But let me say that this random feature
>for compression has been introduced in order to properly deal with
>the (very) special case under discussion. If one considers that the
>probability of occurence of this is very small, one can in my
>humble opinion fairly safely omit to invoke that random feature, i.e.
>always choosing to have no trailing zero bytes when querried by the
>program about this.
>
>M. K. Shen
This may be true but I assume it would be better to not have to deal with
the random issue at all and just use a "one to one" compression routine
in the first place.
I may not post for a few days. Like I said I find an error in my "one to one"
compression for some very specail cases. So I have changed the
code and will be testing it for a few days when it is done I will post it.
But at least I have the basic rules for this method and have found what
I think is a family of such compatable rules.
The rules for the current method are as follows ( looking at decompression
since like describing inverse of a nonsingular marix it might be better to
look at matrix multiply)
Fact one: My huffman tree such that the all zero token is at least 8 bits
long.
Fact two My huffman tree such that the shortest path form any internal node
to a leaf never contains a string of more than 8 ones next to each other.
Fact three A one byte huffman file has no hidden bits and decompresses
to at most one byte since the start tree has 256 leaves all at a lenght of
8 bits.
Rule one: To decompress if the tokens end such that file being decompressed
end on a full byte your are done no problem.
Example ...1 11110000 positions labeled 0 to 7 and in position 3 the
token S = 10000 is last decoded you have ended decompression last symbol
out is a "S".
Rule two: If the last huffman token does not start in the last 7 bits of last
byte of compressed file and yet when at end of byte your at an internal
node of the huffman tree you supply the missing ones since there are at most
8 ones that where chopped off during the compression of that compressed file.
Example ...1 11110000 the token E = 111100001111 was last token used
in compressed file and start on bit 0 of the last token so the
last symbol out of the decompression is "E".
Rule Three: If the last huffman token does start in the last 7 bits of the
last byte and ends at an internal node of the tree but the portion of the
token on the last byte of compressed file has at least one or more bits
that are the one bit. Then as in rule two you supply the hidden ones that
where chopped off the missing file.
Example ...1 11110000 postion 3 the start of last token and in this
case X = 100001 so in this case the symbol used in the
rule 1 example could not have existed in the current
hufman tree so token did not end at file end and the
hidden ones would be supplied and last
symbol out is "X"
Rule Four: ( hardest rule of all) If the last byte has the last token start in
the last 7 bits of the last byte. Yous assume that there are hidden ones
that where chopped off during compression. Only if the the file that is
one token shorter than this one would have had hidden bits cutoff.
This rule means that the all zero start of a last token in the last 7 bits
could depend on what would have happened to a the next shorter file
and that file status could be a function even farther back in the file.
It was the lack of focus on my part that made me miss this
recursive rule for a while. And I kept getting more and more complicated
specail cases. I hope this solves this.
Example ...1 11110000 M =000011 starts in position 4 but previous token
was F = 11111 so since if file shorter by one token cut off would
have occurred there fore the M the last appearant token is
used and is the last charater out..
Rule Five: The only case left is the case where a token starts some
where in the last 7 postions of the last byte and contains all zero
bits in its positions of that last byte. And that the previous file had
it ended on the previous token would not have ones cut off during
compression. In this case and only this case the 1 to 7 trailing
zeros which are not a complete symbol mark the end of file and
are not used to form a new character for the output file.
Example ...1 11110000 M=0011and starts in position 6 but the
existance of this M not important since F = 1100 is previous token
and no cutoff would have occured so the 0000 at end
tells us that the F was the actual last character
in the uncompressed file.
Compression is just the opposite. Thanks for making me
take a longer look. I will post new code shortly. But if you
see an error in my logic let me now since it is I hope complete.
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] (Boudewijn W. Ch. Visser)
Subject: Re: 512 bit number factored
Date: 27 Aug 1999 15:58:18 GMT
On 27 Aug 1999 15:22:53 GMT, DJohn37050 <[EMAIL PROTECTED]> wrote:
>Also look at
>http://www.certicom.com/press/rsa-155.htm for more analysis of the results.
>Don Johnson
This URL is case sensitive, use
http://www.certicom.com/press/RSA-155.htm
Boudewijn
--
+--------------------------------------------------------------+
|Boudewijn Visser | E-mail:[EMAIL PROTECTED] |
| -finger for PGP-keys.- | http://www.ph.tn.tudelft.nl/~visser |
+-- my own opinions etc ---------------------------------------+
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: talk.politics.crypto
Subject: Re: Can americans export crypto when in another country?
Date: Fri, 27 Aug 1999 17:27:10 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>John Savard wrote:
>
>> [EMAIL PROTECTED] (Michael D. Crawford) wrote, in part:
>>
>> >can I export the crypto
>> >back to Switzerland without violating US laws?
>>
>> No, the U.S. law covers the actions of its citizens abroad.
>>
>> John Savard ( teneerf<- )
>> http://www.ecn.ab.ca/~jsavard/crypto.htm
>
>Apparently, you are correct.
>
>The regs seem to have it locked up tighter than a drum.
>
>If the software "encrypts" beyond the designated maximum security
>level, US citizens are prohibited from in any way exporting it or
>causing it to be proliferated outside the US and Canada.
>
If this is true how does the AES stuff get exported so openly
are they below that :designated maximum secutiy level"
And as far as legal mumble jumble goes. I think anyone can
see that these are quite unconstitutional. Besides lawyers write
the fucking rules so that they can be made to seem what ever
the current political climates want them to be.
>Excerpts / quotes from these regs coming in the next few days under
>the subject heading: "Current BXA Encryption Regs."
>
>http://www.ciphile.com
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: receiving a piece of message
Date: Fri, 27 Aug 1999 17:34:38 GMT
In article <7q5qct$o7b$[EMAIL PROTECTED]>, "Alessandro Guarino"
<[EMAIL PROTECTED]> wrote:
>Hello to everybody, this is my first mail in this newsgroup and then nice to
>meet everybody.
>My question is : if I want to decrypt a message encrypt with a private key
>algorithm do I have to receive the message from the beginning?
>I mean, if I start to receive the encrypted message by the middle, am I
>able to decrypt the remaining message?
>
>thanks to everybody
>
>Alex
>
IF you use the standard crap with the standard 3 letter chaining methods you
only need a frament of the file to read a frament of the text. Most methods
use this from of encryption so that the governmetn has an easyer time reading
your mail. If you want something better get scott19u
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: receiving a piece of message
Date: Fri, 27 Aug 1999 17:36:51 GMT
In article <[EMAIL PROTECTED]>, Gary <[EMAIL PROTECTED]> wrote:
>Depends on the encryption algorithm (usually the mode its run in) and
>whether
>the data was compressed before encryption.
Actaully you can recover the data even if it was compressed by
many weak methods. It depends a lot on the compression used.
but you may need to write aspecail program to recover this.
>
>Only if each of the seperate blocks of a plain text message were
>independently
>enciphered then you could decipher the complete blocks within the partial
>message.
>
>>===== Original Message From "Alessandro Guarino" <[EMAIL PROTECTED]> =====
>>Hello to everybody, this is my first mail in this newsgroup and then nice to
>>meet everybody.
>>My question is : if I want to decrypt a message encrypt with a private key
>>algorithm do I have to receive the message from the beginning?
>>I mean, if I start to receive the encrypted message by the middle, am I
>>able to decrypt the remaining message?
>>
>>thanks to everybody
>>
>>Alex
>>
>
>------------------------------------------------------------
> 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.
>------------------------------------------------------------
>
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]
Subject: How to apply for security clearance?
Date: Fri, 27 Aug 1999 16:25:53 GMT
and how much it cost for the clearance?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: 512 bit number factored
Date: Fri, 27 Aug 1999 12:19:25 -0400
"Boudewijn W. Ch. Visser" wrote:
>
> See http://www.cwi.nl/cwi/Latest_News.html :
>
> quick translation:
> - Scientists at CWI (Center for Mathematics and Computer Science) led
> by Herman te Riele have on Sunday August 22 factored a 512 bit number,
> which models 95% of the keys used to secure electronic commerce on the
> Internet.
Congratulations!
But I'm curious about the assertion that 95% of the keys used
are 512 bit keys. Admittedly the sample is small, but my PGP keyring
I find 4 keys of 512 bits, one of 510, vs. 61 of 1024 and 20 of 2048
bits. There are also a few off the wall lengths (801, 768, 709, 2047).
Maybe the PGP community has better keying habits?
paul
------------------------------
From: Justin Scribner <[EMAIL PROTECTED]>
Subject: Re: passphrases
Date: Fri, 27 Aug 1999 11:59:16 -0500
One thought that came to my mind is that the more often you have to
change
your passphrase, the more often it is transmitted. Often the
transmission is unencrypted; thus, susceptible to eavesdropping. Please
feel free to argue this point as I am always eager to learn.
Sincerely,
Justin G. Scribner
Si hoc legere scis nimium gruditionis habes.
On Thu, 26 Aug 1999, Anton Stiglic wrote:
> Keith A Monahan comment is right. Just the fact that someone could
> see you typing your password (or get partial info), or just someone
> listening on the back bone of your network, scanning for passwords
> if you connect to the internet without ssh or somethig (this has happend
> at a university in Montreal), is good enough a reason to change your
> password every so often.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Where to find
Date: Fri, 27 Aug 1999 17:43:08 GMT
In article <7q4v5a$3fts$[EMAIL PROTECTED]>, "Richard A. DeCamp"
<[EMAIL PROTECTED]> wrote:
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote in message
>news:7q4p8r$lji$[EMAIL PROTECTED]...
>> My spelling not the greatest but it was for a "derotation plate" I doubt
>if
>> I have the paper work I don't save anything. I have never even seen my
>porgram
>> scott19u in print. Only on the crt screen.
>
>Thank you kind sir. According to the IBM patent server, US Patent 4,258,976
>(issued 3/31/81) shows David A. Scott of Ridgecrest, CA as co-inventor. The
>applicant is the US of A as represented by Secretary of the Navy. You can
>look it up: www.patents.ibm.com.
>
>Rich
>
Tha was for work done I am sure was in 1970 shows how dam slow the system
is. I never bothered to go through the paper work to file for one again at
work. Also the Navy sucks in that I only found out about it around 1985 since
the system is to dam lazy to track you down and tell you that you got one.
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: John <[EMAIL PROTECTED]>
Subject: Re: Can americans export crypto when in another country?
Date: Fri, 27 Aug 1999 10:14:49 -0700
Except, you are forgetting treaties. The US wouldn't by
itself do this. But most countries in Europe and elsewhere
have signed treaties. It is probably an international
thing.
http://www.aasp.net/~speechfb
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Can americans export crypto when in another country?
Date: Fri, 27 Aug 1999 12:32:33 -0500
Michael D. Crawford wrote:
>
> What I would like to do is specifically port some crypto software
> (that's already written; I'd just be doing a port) and then give it back
> to its originator. I'd be bringing the crypto in from Switzerland to
> Canada, modifying it, and sending it back to Switzerland. The code is
> public domain (open source, not GPL'ed or anything - truly public
> domain) but I know for sure if I did the work in the US I couldn't send
> it back.
I don't think you'll have any real problems. As long as you don't
brag about being an American, who's going to know? Also, don't
advertise the software as being useful for thwarting the US
government. That raises more flags than asking questions does.
> If I can't do that kind of work, I'd be willing to press a court case to
> get the right to do so, like that guy with the Snuffle algorithm. I
> wouldn't just export it - I'd demand a license to do so and sue if I
> didn't get it.
That's pretty expensive. Since the US has signed Wassner, they will
eventually have to align their rules to the agreement. Public domain
isn't a problem, and chances are good the US government will consider
you too small to waste time on (if they know about you at all!).
The only people that get picked on are the ones who blatently hit
the US Feds over the head and ask for attention. If you get the
code from Switzerland while sitting in Canada, the ECHELON system
will notice. Are you a target of investigation for any reason?
If so, then you have other things to worry about!! If not, how are
the computers going to know that the guy sitting behind the computer
moving the code is a US citizen?
The reality is that the regs are arbitrary. The best way to proceed
is to just do it. It's always easier to ask forgiveness than permission,
and the chances that anyone is going to care are pretty remote. It's
nice to be able to fight if you have to, but let the fight come to you.
Don't go looking for one.
Patience, persistence, truth,
Dr. mike
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: 512 bit number factored
Date: 27 Aug 1999 17:19:47 GMT
Paul Koning <[EMAIL PROTECTED]> wrote:
> But I'm curious about the assertion that 95% of the keys used
> are 512 bit keys. Admittedly the sample is small, but my PGP keyring
> I find 4 keys of 512 bits, one of 510, vs. 61 of 1024 and 20 of 2048
> bits. There are also a few off the wall lengths (801, 768, 709, 2047).
> Maybe the PGP community has better keying habits?
Check the MIT keyserver ? Older keys will tend to be shorter; remember
that 384 bits was once one of the default keylengths.
-David
------------------------------
From: John <[EMAIL PROTECTED]>
Subject: Re: Can americans export crypto when in another country?
Date: Fri, 27 Aug 1999 10:12:56 -0700
That may not be so. A U.S. citizen, say, living in France
can write a book there, and still apply for a copyright
as a U.S. citizen. Copyrights are covered by the Bearne
conventions and UCC, kind of an "international" copyright.
Of course, you'd probably need a lawyer to comb out the
fine points. Even if you don't file for a copyright, the
publication of the work is an implied copyright.
So, you say patents. Well, the only possible legal
protection is to copyright and/or patent the work legally
in a country outside the U.S. It might be better to give
up your citizenship, so you don't have to worry about
extradition. Most countries will send people back, if you
are a BIG TIME CROOK.
http://www.aasp.net/~speechfb
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: John <[EMAIL PROTECTED]>
Subject: Re: Can americans export crypto when in another country?
Crossposted-To: talk.politics.misc,talk.politics.crypto
Date: Fri, 27 Aug 1999 10:21:50 -0700
Yeah, send me a hunk of prime rib. :) I think the whole
cause of this is a cold-war leftover. With the internet and
so on, it would be hard to enforce the hill of beans,
unless someone got a "bright" idea and turned you in.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.misc,talk.politics.crypto
Subject: Re: Can americans export crypto when in another country?
Date: Fri, 27 Aug 1999 11:24:48 -0600
In article <[EMAIL PROTECTED]>, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
> Then the bureaucrats ignore the letter and spirit of the law and create the
> regs.
>
> Then the enforcment officers ignore the regs and do what they think best.
>
I find it strange if not amusing that cryptographers from the US, civilian
and government, travel frequently to foreign locations where they share
their thoughts and ideas with other foreigners. Indeed, even the
government had one meeting of the AES in Rome last Spring, and I might
add, adjacent to a Fast Encryption Workshop.
If the regs as existing amounted to a hill of beans, all of those folks
would be in trouble, the government does have a hard list of who was
there, but, as you say, it is easy for bureaucrats to waive the regs
whenever they damn well want to, and to threaten anyone else with severe
penalities for making similiar logical choices about their own conduct
whenever they want to amuse themselves about the concept of having freedom
of expression.
In short, the government presents a poor example in yet another case, but
I understand the turf wars involved as well. It is inconceivable that a
court would not weigh the government's nonchalance in these areas when the
same government attempts to selectively turn the screws to punish someone
it does not like.
--
I'd rather have prime rib than prime numbers.
Moore's Law always yields to Les's Rule.
------------------------------
From: [EMAIL PROTECTED] (Boudewijn W. Ch. Visser)
Subject: Re: 512 bit number factored
Date: 27 Aug 1999 17:40:43 GMT
Paul Koning <[EMAIL PROTECTED]> writes:
[..]
>> - Scientists at CWI (Center for Mathematics and Computer Science) led
>> by Herman te Riele have on Sunday August 22 factored a 512 bit number,
>> which models 95% of the keys used to secure electronic commerce on the
>> Internet.
>Congratulations!
>But I'm curious about the assertion that 95% of the keys used
>are 512 bit keys. Admittedly the sample is small, but my PGP keyring
>I find 4 keys of 512 bits, one of 510, vs. 61 of 1024 and 20 of 2048
>bits. There are also a few off the wall lengths (801, 768, 709, 2047).
>Maybe the PGP community has better keying habits?
The 95 % figure probably refers to SSL keys used by Webbrowsers;
512 bit is the maximum size that can be choosen on the 'international'
versions of netscape,explorer and other browsers made in the US.
Although versions of these browsers (or patches) that allow
longer keys can be found easily outside the US, I think that
very few people bother to search for them.
Boudewijn
--
+--------------------------------------------------------------+
|Boudewijn Visser | E-mail:[EMAIL PROTECTED] |
| -finger for PGP-keys.- | http://www.ph.tn.tudelft.nl/~visser |
+-- my own opinions etc ---------------------------------------+
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Key to Ciphertext Ratio's
Date: Fri, 27 Aug 1999 12:06:18 -0600
In article <7q5sib$civ$[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
> In article <7q4kqj$h1f$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> >
> > 1. Could it be possible that two different key's for a given
> ciphertext
> > produce two legitimate plaintexts? This does not necessarily assume
> > alpha-numeric text.
>
> Well yes, cause each key defines one permutation of 2^64 to 2^64.
> There are in fact 2^64! possible keys which is what I think you are
> looking for. It is possible that some keys decrypt one ciphertext to
> ascii plaintext (anything with the 8th bit zeroed), because there are
> in fact 2^56 different ascii blocks out (i.e you have a 1 in 256 chance
> of getting ascii as the output). So try 128 random keys and you should
> find one ascii block, try another 128 random keys and you should find
> another (128 is avg over 2^(8-1))
For some algorithms, you may find multiple keys for one block, but it will
probably not work on the next one, or any others. The keyspace has to be
hugh enough that chance allows the transient result.
One essential rule in determining strength is consideration of how much
ciphertext need be decrypted to show that you really have the correct
key. One block is simply not enough, and many is a good idea.
But, if it is, you have weak encryption by one definition.
--
I'd rather have prime rib than prime numbers.
Moore's Law always yields to Les's Rule.
------------------------------
From: Jean-Jacques Quisquater <[EMAIL PROTECTED]>
Subject: Re: How to apply for security clearance?
Date: Fri, 27 Aug 1999 19:15:59 +0200
Country? Internet is not only USA ...
------------------------------
** 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
******************************
