Cryptography-Digest Digest #166
Cryptography-Digest Digest #166, Volume #10 Fri, 3 Sep 99 11:13:03 EDT
Contents:
Re: 512 bit number factored ([EMAIL PROTECTED])
Re: Home Invasion Bill Drives U.S. Computer Users across border (pbboy)
Re: 512 bit number factored (Bob Silverman)
Re: Odp: THINK PEOPLE (pbboy)
Re: 512 bit number factored (SCOTT19U.ZIP_GUY)
Encryptor 4.1 reviews please. (pbboy)
Re: 512 bit number factored (DJohn37050)
Re: THINK PEOPLE (Frank Gifford)
Initial authentication of a Network Control Center (was Using Diffie-Hellman to
encode keys) (Thierry Moreau)
Automated way to find the encryption algorithm ("Lukas Lord")
Re: Encryptor 4.1 reviews please. (SCOTT19U.ZIP_GUY)
Re: Can we have randomness in the physical world of "Cause and Effect" ? (Tim Tyler)
From: [EMAIL PROTECTED]
Subject: Re: 512 bit number factored
Date: Fri, 03 Sep 1999 11:51:16 GMT
In article 7qnj7i$[EMAIL PROTECTED],
[EMAIL PROTECTED] (Paul Rubin) wrote:
Wei Dai [EMAIL PROTECTED] wrote:
Now a question of my own: does anyone actually use 512-bit keys for
e-commerce, as CWI's press release claims?
Yes, I spend a fair amount of time looking at SSL certificates and
occasionally still see some 512 bit ones. It's nothing like the 95%
that CWI claimed, though. More like 10%, from the sample I've looked
at.
You can tell the size of an SSL key by connecting to the web site with
MS Internet Explorer and clicking on the lock icon, and viewing "key
exchange" in the SSL properties dialog. This is with MSIE 4.0; I
don't have an MSIE 5 browser handy and I think they've changed the
interface somewhat, but they still show the info. Netscape 4.5
unfortunately doesn't show the key length.
A large number of corporate-bank and even some inter-bank payment links
use 512 bit RSA (or even symmetric technologies). In value, and probably
in volume these links eclipse any Internet-based eCommerce. I believe
S.W.I.F.T.'s keys are longer, but then they move something like USD 9
trillion/day..
These links used to be called EFT or EDI, but have recently been renamed
eCommerce. :-)
-Terje
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
--
From: pbboy [EMAIL PROTECTED]
Crossposted-To: alt.privacy.anon-server
Subject: Re: Home Invasion Bill Drives U.S. Computer Users across border
Date: Fri, 03 Sep 1999 08:57:21 -0400
Anonymous wrote:
Privacy Concerns - http://www.angelfire.com/biz/privacyconcerns/index.html
Home Invasion Bill Drives U.S. Computer Users to Canadian Privacy Firm
Zero-Knowledge Systems
MONTREAL--(BUSINESS WIRE)--Aug. 24, 1999--Zero-Knowledge Bombarded
With Requests to Release Freedom(TM) Following Disclosure of 'Cyberspace
Electronic Security Act' A US Justice Department proposal to secretly
enter its citizens' homes and disable security features on their computers
At the risk of sounding completly oblivious to current events I must ask: Is
this real?
--
From: Bob Silverman [EMAIL PROTECTED]
Subject: Re: 512 bit number factored
Date: Fri, 03 Sep 1999 12:47:19 GMT
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Wei Dai) wrote:
In article [EMAIL PROTECTED], [EMAIL PROTECTED]
So, supposing you write a similar comment 9 years from now, how could
you fill in the blank:
It has been well known since 1999 that _ bit keys were breakable
and within computer capabilities.
snip
Today, 20
thousand computers (500 MIPS each at 1/4 the price of a 1990 computer)
for a year lets you factor a 700 bit number.
Yes and no.
A 700 bit number is about 730 times as difficult as 512-bits
in terns of *time* and 27 times as difficult in terms of space.
Each of these 20K computers will need 2 to 3 Gbytes of memory
(for the sieving phase)
In 1990 my Sparc-10 on my desk had 32M of RAM. Now, my
dual-proc P-450 has 256M. We *might* see workstations desktops
with 2-3Gbytes in 10 years, but I doubt that they will be common
enough to gather 20,000 of them for a year. I don't see most
applications needing that kind of memory. 512M??? Sure! But
not 3G.
It took a very large Cray (C90) 10 days and about 2.4 Gbytes
of memory to handle the matrix. I don't see Crays getting
significantly faster in the next 9 years. We might see a factor of
4 to 5, but I doubt more than that.
With C90 hardware, the matrix for 700 bits would take 7300 days
and require about 60 Gbytes of memory.
Everyone seems to always forget about scaling the space requirements
and solving the matrix.
I don't see 700 bits being done within 10 years without an
algorithmic improvement.
If we assume no further algorithmic improvements and that computing power
per dollar continues to increase at a factor of 1.5 per year, then 9
years from now an effort similar to RSA-155 (about 50 CPU-years) should
be able to break 600-650 bit numbers.
I agree
Cryptography-Digest Digest #167
Cryptography-Digest Digest #167, Volume #10 Fri, 3 Sep 99 14:13:06 EDT
Contents:
Re: RC4 or IBAA or ISAAC to generate large random numbers (Paul Crowley)
Re: IDEA- safe? (Paul Crowley)
Re: RC4 or IBAA or ISAAC to generate large random numbers (John Savard)
Re: Message Digest Algorithms (Tom St Denis)
Re: One to One Compression updated (Tom St Denis)
MD5 source code in VC++ or asm? ([EMAIL PROTECTED])
Re: http://www.tmechan.freeserve.co.uk/wincrypt.html ("Daniel Roethlisberger")
Re: How Easy Can Terrorists Get Strong Encrypt? (Lincoln Yeoh)
Re: Alleged NSA backdoor in Windows CryptoAPI (SCOTT19U.ZIP_GUY)
Re: One to One Compression updated (SCOTT19U.ZIP_GUY)
From: Paul Crowley [EMAIL PROTECTED]
Subject: Re: RC4 or IBAA or ISAAC to generate large random numbers
Date: 3 Sep 1999 09:05:43 +0100
Gaston Gloesener [EMAIL PROTECTED] writes:
What is the correct way to generate larger random numbers (64 bits):
Any CPRNG can be considered as a stream of random bits; the boundaries
between words are just an artifact of the way they're generated. If
the CPRNG is good then you can take as many bits at a time as you need
and use them as random. I know of no biases or flaws in IBAA or
ISAAC; there's an incredibly tiny bias in RC4 but I don't suppose
it'll affect your work (see http://www.hedonism.demon.co.uk/paul/rc4/ ).
You might also consider using Joan Daemen and Craig Clapp's PANAMA,
which I believe is faster than any of these: see
http://www.esat.kuleuven.ac.be/~rijmen/daemen.html
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
--
From: Paul Crowley [EMAIL PROTECTED]
Subject: Re: IDEA- safe?
Date: 3 Sep 1999 09:32:36 +0100
[EMAIL PROTECTED] writes:
Jim Butcher wrote:
has anyone heard of a successful cryptanalysis of the IDEA algorithm? 128
bit key, 64 bit block size
for that matter Blowfish 256 bit key?
No. The worst result against IDEA is that a very tiny proportion of
the keys (1 in 2^96) are easily detected, making cryptanalysis very
slightly faster.
As I have learned in the past few months on this newsgroup...as long as the
key size is of sufficiant length (lets say 64 bits+), the keysize is really
irrelivant. There are other types of attacks on algorithms than brute force.
There are no other attacks known on the *algorithms* than brute force,
though there can be other attacks on entire cryptosystems that use
them (such as rubber-hose cryptanalysis). And your figure 64 bits is
too short: I'm confident that the RC5 challenge will soon break a 64
bit key. I'd put the figure at, say, 112 bits (triple-DES) or
greater.
256-bit keys are only needed to defend against immensely advanced
aliens with quantum computeres.
As long as you stick with the tried and true algorithms, you should be
ok. Blowfish, IDEA, CAST-128, 3DES, RC4, RC5, or any of the AES candidates.
The AES candidates don't really count as "tried and true".
RC4 is a stream cipher and doesn't apply. IDEA and RC5 are
patent-encumbered; I can't remember whether CAST is or not. 3DES is
slow. Use Blowfish.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: RC4 or IBAA or ISAAC to generate large random numbers
Date: Fri, 03 Sep 1999 15:30:21 GMT
Gaston Gloesener [EMAIL PROTECTED] wrote, in part:
What is the correct way to generate larger random numbers (64 bits):
1. Handle large integers inside the algorithm,
2. Compute a set of results (r-array) and use consecutive 32-bit values
to fill-up the resulting random number.
(1) is better, in the sense that it will not make the algorithm any
worse, and so if one is using a poor generator, such as linear
congruential, it would be mandatory, but (2) can be used with any
random number method of sufficiently high quality.
In either case, the random number generator must have an internal
state at least as big as the large pseudorandom number you are trying
to generate.
John Savard ( teneerf- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: Message Digest Algorithms
Date: Fri, 03 Sep 1999 14:52:23 GMT
In article [EMAIL PROTECTED],
"Daniel Roethlisberger" [EMAIL PROTECTED] wrote:
I have previously used MD5 in all the code I wrote. Now I am looking
for a
replacement, and have found several algorithms. Now I am unsure which
one to
use. Hence my question: has anybody an idea where I might get info on
message digest algo's? Some of the algorithms that I have considered
lately
are RipeMD, Tiger and SHA1. Has anyone got some good piece of
information on
their advantages and on their strength?
Any suggestions? Pointers? Hints?
Tiger is
Cryptography-Digest Digest #168
Cryptography-Digest Digest #168, Volume #10 Fri, 3 Sep 99 16:13:03 EDT
Contents:
Description of SQ ("Kostadin Bajalcaliev")
Description of SQ ("Kostadin Bajalcaliev")
Re: 512 bit number factored (SCOTT19U.ZIP_GUY)
Re: 512 bit number factored (D. J. Bernstein)
Different Encryption Algorithms ("entropy")
Re: Alleged NSA backdoor in Windows CryptoAPI (Stephan Eisvogel)
Re: Alleged NSA backdoor in Windows CryptoAPI (Ian Goldberg)
Re: ECC, D.S., Fravia, Ian (Ian Goldberg)
Re: Implementing crypto algorithms in Fortran. (SCOTT19U.ZIP_GUY)
Re: Home Invasion Bill Drives U.S. Computer Users across border ([EMAIL PROTECTED])
Re: IDEA- safe? (jerome)
Re: Alleged NSA backdoor in Windows CryptoAPI (DJohn37050)
From: "Kostadin Bajalcaliev" [EMAIL PROTECTED]
Subject: Description of SQ
Date: Fri, 3 Sep 1999 20:06:18 +0200
Please send your comments about my Stream cipher. Here is only the
description. If you need more details visit
http://eon.pmf.ukim.edu.mk/~kbajalc or http://members.tripod.com/kbajalc.
The SQ1 Stream Cipher
Kostadin Bajalcaliev
April 26th Street num: 14,
91480 Gevgelija, Macedonia, Europe
[EMAIL PROTECTED]
Abstract: This document describes SQ1 stream cipher. SQ1 is
Cryptographically Secure Pseudo-Random bit generator. A novel feature of SQ1
is its hybrid design, using both permutation and variation. It is simple and
easy to implement, suitable for software and hardware implementation.
1. Data Structures
SQ1 is word-oriented algorithm; any word size is supported respecting the
available memory. In order to implement SQ1 data structures below are
required: (given in C notation)
P[w] permutation of numbers from 0 to w
V[w] variation, every element can have any value 0 to w
Sr - feedback register
* All data types are W-bit
The word size can be some conventional value 8,16
bits, but the formal
definition of the algorithm assume any value with respect to available
memory. In the real implementation other variables are used but they are
meter of optimization.
2. Notation and SQ Primitive Operations
SQ1 require only four primitive operations supported by major processor
families.
1. Addition of two words, denoted by +, addition is done modulo 2w
2. Bit-wise exclusive OR of words, denoted by XOR
3. A left-rotation of words: the rotation of word x left by y bits is
denoted xy
4. Modulo, x modulo y equal z denoted x mod y = z.
A left-rotation of fields: X[y]=X[y+z mod field_size], denoted by Xz is
basic operation in SQ1, it is not primitive but easily deliverable from the
primitive operations.
3. Algorithm Specification
According to definition of data structure and primitive operations here is
algorithm formal definition:
/* initialization */
for j=0 to 2w { P[j]=j; V[j]=0; }
/* generator iteration */
{1} A=P[Sr]; B=P[V[A]];
{2} V[A]=B; Swap P[A], P[B]; P1;
{3} Out=P[A+B mod 2w];
{4} Sr1; Sr=Sr+Out;
Return Out
SQ1 is very simple, you can encode it as a function SQ which produce values
according to its internal state. The state of the generator is defined with
P[], V[] and Sr.
The first step {1} is calculation of indexes A and B according to present
state of the generator. The second step {2} is the transformation of P[] and
V[] according to A and B, P1 is default transformation (the counter). The
third step {3} is calculation of the output value, and the forth {4} step is
changing the value into feedback register.
4. Keying SQ1
SQ as most of Stream Ciphers keying the generator is setting the initial
state. Very simple strategy is used. The key stream is feed into Variation
V[] and the key length is feed into Sr. First 22w outputs are discarded to
worm up the generator. Here is the formal definition of keying procedure.
K[0..L] is the keystream
L is length of the keystream
r=0;
For j=0 to 2w { V[j]=K[r]; r=(r+1) mod L; }
For j=0 to 22w SQ1();
SQ1() is the generator function described before. The keystream should be
the same word size as P[] and V[] but it is allowed to be smaller to. For
example if w=14, the keystream can be conventional 8-bit character field. If
the w8 (what is very bed idea) that the keystream should be cut in w-bit
peace in order to feed it into V. The maximal key length allowed using this
strategy is 22w bits, the length of V in bits.
5. Implementation Remarks
This is document is intended to help you implementing SQ1, if you are
interested about the design solutions read the thesis available on-line.
Because of security of the algorithm please follow these remarks:
1. SQ1 is not intending to be secure for any word size or key length. The
word size must be greater than 8bits.
2. Do not use all the bits produced by the generator, discard at least one.
If you need 8-bit values to encrypt files or communication channel use 9-bit
word. The values produced by the generator are going to be 0..511,
Cryptography-Digest Digest #169
Cryptography-Digest Digest #169, Volume #10 Fri, 3 Sep 99 18:13:04 EDT
Contents:
Re: Schneier/Publsied Algorithms (Anonymous)
Cracked ? ("B3avis")
Re: Implementing crypto algorithms in Fortran. ("Douglas A. Gwyn")
Re: THINK PEOPLE (David A Molnar)
Re: Home Invasion Bill Drives U.S. Computer Users across border (David A Molnar)
Re: IDEA- safe? (jerome)
Re: Alleged NSA backdoor in Windows CryptoAPI (Lee K. Gleason)
Does SSL use RSA Keys? ([EMAIL PROTECTED])
Re: SQ Announcement (David Wagner)
Re: Alleged NSA backdoor in Windows CryptoAPI (Frank Gifford)
Re: Schneier/Publsied Algorithms (Eric Lee Green)
Re: Alleged NSA backdoor in Windows CryptoAPI ("Steven Alexander")
Re: THINK PEOPLE (SCOTT19U.ZIP_GUY)
Re: Description of SQ (David Wagner)
Re: MD5 source code in VC++ or asm? (Paul Koning)
Date: Fri, 3 Sep 1999 22:01:11 +0200
From: Anonymous [EMAIL PROTECTED]
Subject: Re: Schneier/Publsied Algorithms
One of the posts in this thread refers to Bugs in Windows NT...yes there are bugs in
Windows NT..but its a v. large op. sys. Millions of lines of code2fish is a very
small apps..maybe 2-3k lines of code
OK...Now we see some Test Vectors appeaing on the counterpane.com web site...with no
documentaion...
Checking the source code when I last downloaded and nowthe header in twofish.c
still reads version 1. April '98 by the same guy...Hi/fn ...whoever that is...
So contrary to what people are saying here in this threadthat the bugs are listed
in the counterpane web site and the source code is constantly updatedthat is NOT
TRUE
What we have here is a piece of code written by a guy who is not even from Counterpane
systems.and the CODE has not Changed for 16 MONTHS.
Come onWHo are you kidding
Do you expect us to believe that this download is a professional product rteady for
commercial useI dont think so
So if we are a commercial organisation...is there another deal on offerI mean
here is a free Source code on our web site...take it or leave it...we cant really
tell you much about its roubstnessBut if you want a commercial deal...well you can
have THISoh yes..we have this for you...and this stuff on the web site is just a
load of crap smilling and looking over while the ink dries up on the cheque...
I mean...this stuff on the website cant be the real thingIs it Real Coke or
Classic Coke
I would not even consider using it in an Commercial AppsIts just badlz wriiten
piece of crap
Wolfman
--
From: "B3avis" [EMAIL PROTECTED]
Subject: Cracked ?
Date: Fri, 3 Sep 1999 22:18:42 +0200
Hey there,
I was wondering... Can someone give me a list or tell me where to find it of
all common encryption-algoritms that are cracked and the ones that aren't
cracked yet ?
Thanks in advance, B3avis
http://come.to/bchicken
--
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: Implementing crypto algorithms in Fortran.
Date: Fri, 3 Sep 1999 17:48:31 GMT
"SCOTT19U.ZIP_GUY" wrote:
... IF the machine your on uses 2's complimnet
arithmetic then you can use signed numbers as unsigned.
Only if overflow does not trigger an exception.
--
From: David A Molnar [EMAIL PROTECTED]
Subject: Re: THINK PEOPLE
Date: 3 Sep 1999 20:18:20 GMT
Frank Gifford [EMAIL PROTECTED] wrote:
If you don't have the final 100 bytes of the target encrypted message, how
do you know that they are identical to the last 100 bytes of some other
message?
David Scott's scenario was three messages for three people, with the only
differences being in the middle, and the plaintext for two of the messages
known.
-David
--
From: David A Molnar [EMAIL PROTECTED]
Crossposted-To: alt.privacy.anon-server
Subject: Re: Home Invasion Bill Drives U.S. Computer Users across border
Date: 3 Sep 1999 20:16:29 GMT
In sci.crypt [EMAIL PROTECTED] wrote:
Hasn't been 'real' so far.
I've been seeing stuff about this Zero-Knowledge Systems for a year.
I know people who are associated with them.
I've seen no product.
Beta test is running now.
--
From: [EMAIL PROTECTED] (jerome)
Subject: Re: IDEA- safe?
Date: 3 Sep 1999 20:34:58 GMT
Reply-To: [EMAIL PROTECTED]
typo, replace 4.5months by 4.5years
On 3 Sep 1999 19:03:28 GMT, jerome wrote:
and these attacks can use the key even if they are different than
brute force...
moreover if currently everybody says that 56bits is easy to reach, 64bits
is only 256 times more, so in 4.5months 64bits would be as easy as
^
4.5 years obviously
56bits now, according to the principle "the cpu power double every 18months"
--
From: [EMAIL PROTECTED] (Lee K. Gleason)
Subject: Re: Alleged
Cryptography-Digest Digest #170
Cryptography-Digest Digest #170, Volume #10 Fri, 3 Sep 99 20:13:03 EDT
Contents:
Re: Schneier/Publsied Algorithms (SCOTT19U.ZIP_GUY)
Re: Q: Cross-covariance of independent RN sequences in practice (The Asshole)
Re: What if RSA / factoring really breaks? ("Dr. Michael Albert")
new user (Dominic Doyle)
Re: Using Diffie-Hellman to encode keys ("Joseph Ashwood")
Please help a newbie... (Ragni Panjala)
NSA and MS windows (Michael Slass)
Re: Alleged NSA backdoor in Windows CryptoAPI (SCOTT19U.ZIP_GUY)
Re: Alleged NSA backdoor in Windows CryptoAPI (Stanley Chow)
Re: Schneier/published algorithms (Forrest Johnson)
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Schneier/Publsied Algorithms
Date: Fri, 03 Sep 1999 23:00:40 GMT
In article [EMAIL PROTECTED], Eric Lee Green [EMAIL PROTECTED] wrote:
Anonymous wrote:
One of the posts in this thread refers to Bugs in Windows NT...yes there are
bugs in Windows NT..but its a v. large op. sys. Millions of lines of
code2fish is a very small apps..maybe 2-3k lines of code
OK...Now we see some Test Vectors appeaing on the counterpane.com web
site...with no documentaion...
Checking the source code when I last downloaded and nowthe header in
twofish.c still reads version 1. April '98 by the same guy...Hi/fn
...whoever that is...
First of all, why should we take seriously some twit who can't even figure out
how to wrap his lines?
Secondly: TwoFish was submitted over 16 months ago as an AES candidate. It
isn't going to change unless some serious flaw is found, in which case it will
more likely be tossed out of the competition rather than changed. If you want
the "official" AES-candidate source code, go to the AES home page at
http://www.nist.gov/aes and order the CD-ROM, and get not only the latest
TwoFish but also the source code to all the other AES candidates. (Note: that
page now says that they are going to make a new CD-ROM with the finalists on
it, and it won't be available until October... but if you're interested in good
top-quality encryption algorithms in a number of different languages, it still
looks interesting). If TwoFish is the AES winner, it will be the "official"
encryption standard for all non-military US encryption. It's already one of the
By official does this mean if we use something that is secure which the
government doesn't want us to use that we can expect "military gas"
canisters to be thrown in our windows. I wonder just what the Hell does
this so called "official" means. Will it get the same high standard of testing
that MicroSoft is claiming there operating system encryption gets or is
this to low of a level for them?
top five finalists. Sounds like it's pretty solid to me, though some of the
other AES candidates also have good points that make them worth looking at.
Yeah I've been wondering just what those "good points" are. Will the NSA
ever tell us.?
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: The Asshole [EMAIL PROTECTED]
Subject: Re: Q: Cross-covariance of independent RN sequences in practice
Date: Fri, 03 Sep 1999 16:34:05 -0500
Douglas A. Gwyn wrote:
Mok-Kong Shen wrote:
... Exact zero of cross-covariance is required by independence.
No, it is not, no more than zero standard deviation is required
for the mean of a truly random variable. Statistical independence
differs from algebraic independence in just such ways.
Your statement makes no sense statistically.
1st: By definition, independent variables have covariance = 0.
2nd: If any "random" variable has standard deviation= zero, we call it
a constant. A truly random variable MUST have a standard deviation 0.
GMA
--
From: "Dr. Michael Albert" [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: What if RSA / factoring really breaks?
Date: Fri, 3 Sep 1999 17:36:13 -0400
But given that cyphers and
the like are considered munitions by the US Government, and other
governments presumably, wouldn't someone taking this course risk
being prosecuted for treason: "wilfully disseminating material
prejudicial to the security of the state". I'm sure "they" could
cook up some charge along those lines.
In the U.S., writings on cryptographic theory are covered
under the "freedom of speech" clause of the Constitution.
Actual computer programs in machine readable form, however,
are considered "munitions". So life is interesting in
the U.S. For example, there is a book out which, in printed
form, gives explicit code for encryption algorithms, and
the book is set up in such a way that the code could be
read by an optical-character-recognition system,
Cryptography-Digest Digest #171
Cryptography-Digest Digest #171, Volume #10 Fri, 3 Sep 99 22:13:03 EDT
Contents:
Re: Schneier/Publsied Algorithms (Eric Lee Green)
Re: 512 bit number factored (Wei Dai)
Re: SQ Announcement (SCOTT19U.ZIP_GUY)
Re: Schneier/Publsied Algorithms (SCOTT19U.ZIP_GUY)
Re: 512 bit number factored ([EMAIL PROTECTED])
Re: Schneier/Publsied Algorithms (David A Molnar)
Re: Re: 512 bit number factored (Wei Dai)
More information on TEA available? ("Greg Keogh")
Re: Alleged NSA backdoor in Windows CryptoAPI ([EMAIL PROTECTED])
Re: Schneier/published algorithms (SCOTT19U.ZIP_GUY)
From: Eric Lee Green [EMAIL PROTECTED]
Subject: Re: Schneier/Publsied Algorithms
Date: Fri, 03 Sep 1999 23:17:02 GMT
"SCOTT19U.ZIP_GUY" wrote:
top five finalists. Sounds like it's pretty solid to me, though some of the
other AES candidates also have good points that make them worth looking at.
Yeah I've been wondering just what those "good points" are. Will the NSA
ever tell us.?
Probably not, but Brian Gladman ( http://www.seven77.demon.co.uk/index.htm ) is
not shy about what he sees as strengths and weaknesses. I'm sure I can find
others with their own opinions if I looked.
The biggest unknown is RC6. It is simple and fast -- but is it secure? Given
RSA's long flirtation with the NSA, that's the billion-dollar question. It's
hard to believe that something so simple could be secure, but on the other hand
the principle designers of RC6 do have a lot of experience in the field and
maybe they're just smarter than the rest of the AES contributors.
I *WILL* point out that design of block ciphers is not exactly brain surgery in
this day and age. This is a field which is, to a certain extent, mature, unlike
the field of public key encryption, which is still in its infancy.
-E
--
From: [EMAIL PROTECTED] (Wei Dai)
Subject: Re: 512 bit number factored
Date: Fri, 3 Sep 1999 17:24:48 -0700
In article 7qog0k$aj4$[EMAIL PROTECTED], [EMAIL PROTECTED] says...
A 700 bit number is about 730 times as difficult as 512-bits
in terns of *time* and 27 times as difficult in terms of space.
Each of these 20K computers will need 2 to 3 Gbytes of memory
(for the sieving phase)
In 1990 my Sparc-10 on my desk had 32M of RAM. Now, my
dual-proc P-450 has 256M. We *might* see workstations desktops
with 2-3Gbytes in 10 years, but I doubt that they will be common
enough to gather 20,000 of them for a year. I don't see most
applications needing that kind of memory. 512M??? Sure! But
not 3G.
First, nine years from now, you won't need 2 computers with 2-3 GB of
memory, you'll only need 500. Second, do you really need 2 to 3 GB of RAM
or can some of that space be hard disk space? Perhaps it is also possible
to trade off between time and space so you use 512 MB of space but more
time. I'm sure you know better than I do what the exact tradeoff is.
Finnally, even if you really do need 3 GB of RAM, at today's prices it's
only a couple thousand dollars. In 9 years 2 GB of RAM will probably cost
around $100.
It took a very large Cray (C90) 10 days and about 2.4 Gbytes
of memory to handle the matrix. I don't see Crays getting
significantly faster in the next 9 years. We might see a factor of
4 to 5, but I doubt more than that.
With C90 hardware, the matrix for 700 bits would take 7300 days
and require about 60 Gbytes of memory.
If vector-processing supercomputers are not improving as fast as
workstation CPUs, an obvious question to ask is whether distributed
memory parallel processing supercomputers (Intel has built one with 1.8
TFLOPS compared to 12 GFLOPS of the C90) can be used to solve the matrix
problem. Is there any reason why they can't?
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: SQ Announcement
Date: Fri, 03 Sep 1999 23:18:59 GMT
In article 7qpc53$nmk$[EMAIL PROTECTED],
[EMAIL PROTECTED] (David Wagner) wrote:
In article 7qo4oi$[EMAIL PROTECTED],
Kostadin Bajalcaliev [EMAIL PROTECTED] wrote:
I have read Shannon theories, just compare my and your claim:
If we need more information than the output carry about them inner state of
the generator ...
when the output keystream length is longer than the key length, the
I do not see any logical conection.
My point is that, if the stream cipher uses a N-bit key, then we
need only N bits of information about the cipher to deduce the inner
state, total.
Thus, by looking at N bits of output, we are guaranteed to have enough
aggregate information to break the cipher (if there are no bounds on
our computing power).
I believe this means that the "Information Lose" theory does not apply
to any cipher which generates more than N bits of output: if more than
N bits of information about the output are available, then the output
carries enough information about the internal state to break
Cryptography-Digest Digest #172
Cryptography-Digest Digest #172, Volume #10 Sat, 4 Sep 99 02:13:03 EDT
Contents:
Re: NSA and MS windows (Bruce Schneier)
Re: 512 bit number factored (Bob Silverman)
Re: 512 bit number factored (Paul Rubin)
Re: Alleged NSA backdoor in Windows CryptoAPI (Bruce Schneier)
THE NSAKEY (SCOTT19U.ZIP_GUY)
Re: Schneier/Publsied Algorithms (Bruce Schneier)
Re: 512 bit number factored (Eric Young)
Re: Does SSL use RSA Keys? (Eric Young)
Re: 512 bit number factored (Paul Rubin)
Re: NSA and MS windows ("Thomas J. Boschloo")
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: NSA and MS windows
Date: Sat, 04 Sep 1999 02:04:58 GMT
On Fri, 03 Sep 1999 14:27:30 -0700, Michael Slass [EMAIL PROTECTED]
wrote:
According to
http://www.cnn.com/TECH/computing/9909/03/windows.nsa/
"(CNN) -- A cryptography expert says that Microsoft operating systems
include a back door that allows the
National Security Agency to enter systems using one of the operating
system versions.
A few months ago in my newsletter Crypto-Gram, I talked about
Microsoft's system for digitally signing cryptography suits that go
into its operating system. The point is that only approved crypto
suites can be used, which makes thing like export control easier.
Annoying as it is, this is the current marketplace.
Microsoft has two keys, a primary and a spare. The Crypto-Gram
article talked about attacks based on the fact that a crypto suite is
considered signed if it is signed by EITHER key, and that there is no
mechanism for transitioning from the primary key to the backup. It's
stupid cryptography, but the sort of thing you'd expect out of
Microsoft.
Suddenly there's a flurry of press activity because someone notices
that the second key is called "NSAKEY" in the code. Ah ha! The NSA
can sign crypto suites. They can use this ability to drop a Trojaned
crypto suite into your computers. Or so the conspiracy theory goes.
I don't buy it.
First, if the NSA wanted to compromise Microsoft's Crypto API, it
would be much easier to either 1) convince MS to tell them the secret
key for MS's signature key, 2) get MS to sign an NSA-compromised
module, 3) install a module other than Crypto API to break the
encryption (no other modules need signatures). It's always easier to
break good encryption.
Second, NSA doesn't need a key to compromise security in Windows.
Programs like Back Orifice can do it without any keys. Attacking the
Crypto API still requires that the victim run an executable (even a
Word macro) on his computer. If you can convince a victim to run an
untrusted macro, there are a zillion smarter ways to compromise
security.
Third, why in the world would anyone call a secret NSA key "NSAKEY."
Lots of people have access to source code within Microsoft; a
conspiracy like this would only be known by a few people. Anyone with
a debugger could have found this "NSAKEY." If this is a covert
mechanism, it's not very covert.
I see two possibilities. One, that the backup key is just as
Microsoft says, a backup key. It's called "NSAKEY" for some dumb
reason, and that's that.
Two, that it is actually an NSA key. If the NSA is going to use
Microsoft products for classified traffic, they're going to install
their own cryptography. They're not going to want to show it to
anyone, not even Microsoft. They are going to want to sign their own
modules. So the backup key could also be an NSA internal key, so that
they could install strong cryptography on Microsoft products for their
own internal use.
But it's not an NSA key so they can secretly install weak cryptography
on the unsuspecting masses. There are just too many smarter things
they can do to the unsuspecting masses.
My original article:
http://www.counterpane.com/crypto-gram-9904.html#certificates
Announcement:
http://www.cryptonym.com/hottopics/msft-nsa.html
Nice analysis:
http://ntbugtraq.ntadvice.com/default.asp?sid=1pid=47aid=52
Useful news article:
http://www.wired.com/news/news/technology/story/21577.html
**
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
--
From: Bob Silverman [EMAIL PROTECTED]
Subject: Re: 512 bit number factored
Date: Sat, 04 Sep 1999 02:32:56 GMT
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (DJohn37050) wrote:
OK, some here are some reworded questions on RSA key size for Bob, Wei and
anyone else to comment on:
1. My understanding is that the GNFS has 2 steps: (A) Gathering equations,
which can be done in parallel with little memory
As I said, 700 bits would require 2-3 Gbytes per machine to do the
sieving.
If you choose to call this 'little', might I ask your definition of
'big'?
We have
