Cryptography-Digest Digest #178, Volume #10 Sun, 5 Sep 99 02:13:03 EDT
Contents:
point of a cipher (Tom St Denis)
Re: DES cfb stream cypher and "whitening" or initialization (Tom St Denis)
Re: Please help a newbie... ("Kostadin Bajalcaliev")
Re: Different Encryption Algorithms ("Kostadin Bajalcaliev")
Re: Automated way to find the encryption algorithm ("Kostadin Bajalcaliev")
Re: RC4 or IBAA or ISAAC to generate large random numbers ("Kostadin Bajalcaliev")
Re: Some questions about stream ciphers ("Kostadin Bajalcaliev")
Re: Mystery inc. ("Douglas A. Gwyn")
Re: Different Encryption Algorithms (David A Molnar)
Re: point of a cipher ("Douglas A. Gwyn")
Re: Description of SQ ("Douglas A. Gwyn")
Re: Please help a newbie... (Tom St Denis)
Re: Alleged NSA backdoor in Windows CryptoAPI ("Douglas A. Gwyn")
Re: NSA and MS windows (Bill Unruh)
Re: DES cfb stream cypher and "whitening" or initialization (Scott Fluhrer)
Re: NSA and MS windows (Dave Salovesh)
Re: arguement against randomness ("Douglas A. Gwyn")
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
Re: THINK PEOPLE (Tom St Denis)
Re: Second "_NSAKey" ("Rick Braddam")
Are there any RSA encryption / decryption source in JAVA ? (Dennis To)
Re: 512 bit number factored ("Roger Schlafly")
Re: NSA and MS windows ("Roger Schlafly")
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: point of a cipher
Date: Sun, 05 Sep 1999 02:59:38 GMT
(this is addressed towards Dave Scott, but feel free to comment),
The point of a cipher is to hide the contents of a message M with an
encryption method E, and the key K. The goal is without knowledge of K,
nothing of M can be derived from E_K(M) .
Now tell me where 'magical' compression methods come in. Either you know the
key, and get the message, or you don't know the key and you only get random
crap. I agree that compression helps remove redundancies, but it doesn't
hinder brute-force or any other attack outisde of just trying to decompress
what you guessed M could be.
You argue for 'all or nothing' but the thing is, from an outsiders point of
view, either you know K or you don't. So either you get the message or you
don't. No two ways about it. If the encryption algorithm sucks and you can
find M without K, then yes you are right, but many ciphers have stood the
test of time.
So can you clear up how either 'magical compression' or 'w-pcbc' actually
protect M from the attacker?
Another argument against w-pcbc is what if there is a burst error (say in a
MPEG stream) do I want to lose the entire contents? (this plus it's slower,
no more secure and awkwards should strongly suggest not to use it).
So tell me where you gain info from a CBC stream without knowledge of M or K?
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: DES cfb stream cypher and "whitening" or initialization
Date: Sun, 05 Sep 1999 02:40:06 GMT
In article <7qrflp$446$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Cary O'Brien) wrote:
> I (like probably 10% of the readers) need to encrypt a data stream with a
> stream cypher. I want to use des in cfb mode (specifically des_cfb64_encrypt
> from libdes). The system will use shared secrets for keys. The problem
> is that the packet structure of the underlying data stream would be know
> to an attacker (ok, ok, it is ppp). I'm worried that this will provide
> the attacker with a known-cleartext attack. Not good.
>
> I propose to insert 4 bytes of "random" data to the beginning of the
> cleartext data stream on the encryption side, and drop the first 4 bytes
> on the decryption side.
>
> 1) Is this worth the effort?
> 2) Am I being otherwise stupid?
>
> Thanks,
Here's a question.... why are you using des? Is this to be compatible with
another app? In this case your question is moot.
Otherwise... DROP DES. Use RC4 if you need a good stream cipher (or just
make up some Algorithm M clone). RC4 is about 20 times faster, more compact
and easier to get RIGHT. It's also not yet vulnerable to any known attack.
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Kostadin Bajalcaliev" <[EMAIL PROTECTED]>
Subject: Re: Please help a newbie...
Date: Sat, 4 Sep 1999 18:04:08 +0200
Use hash function, hash the password and store the hash value into
pass-file. Every time user log he/she enter the password, and the hash
values are comapared. This maximum you can get. If you encrypt the pass-file
you mast store the password somewhere in your program, so there is no
advence in security.
Ragni Panjala wrote in message <[EMAIL PROTECTED]>...
>Hi all
>I am developing an application in Power Builder with Foxpro as my
>backend..so, I would need to store the passwords the user enters to
>access the application in a file - for security purposes, I need to
>encrypt this file so that only the application can read and write to
>it..I have never done anything like thisbefore and I am stuck..I have
>looked at Microsoft cryptoAPI but have no idea how to use it..
>PLease help..
>Thanks
>Ragni
------------------------------
From: "Kostadin Bajalcaliev" <[EMAIL PROTECTED]>
Subject: Re: Different Encryption Algorithms
Date: Sat, 4 Sep 1999 18:07:32 +0200
Hello
Usualy people do not publish comapration of algorithms, you can easy find
description of all these algorithms and their analisys. "Applied
Cryptography" is good source of information if you not require deep
understending of the theory behing these angorithms.
entropy wrote in message ...
>I'm doing a high school research paper on different encryption algorithms,
>such as CAST, IDEA, blowfish, RCx, DES, etc. Could anyone point me to
>informative web sites pertaining to the differences between these
encryption
>methods?
>
>Thank you.
>
>--
>
>a.
>
>
>:::entropy:::
>ktheory.com
>
>
>
>
------------------------------
From: "Kostadin Bajalcaliev" <[EMAIL PROTECTED]>
Subject: Re: Automated way to find the encryption algorithm
Date: Sat, 4 Sep 1999 18:10:54 +0200
Yes there is, but the encryption process must be fully speciefied. If you
use some standard algorithm like DES, Differential Cryptoanalisys and
Linnear cryptoanalysis can discover the key, so you can generate all posible
couples. However you must know the algorithm used to thansform integer to
strin of 48 characters.
Lukas Lord wrote in message ...
>I'm interested to know if there exists tools or methods to do the
following:
>
>Lets say I can get information about as many unencryped value / encrypded
>value pairs as I want in the form below
>
><integer> <string of 48 characters>
>
>Is there a way to find what the encoded value of a certain unencoded value
>will be?
>
>Lukas Lord
>
>
>
>
------------------------------
From: "Kostadin Bajalcaliev" <[EMAIL PROTECTED]>
Subject: Re: RC4 or IBAA or ISAAC to generate large random numbers
Date: Sat, 4 Sep 1999 18:14:50 +0200
If the generator support to be extend to 64-bit integers that do it.
Generaly the second method is used, because if a[i] and a[i+1] are randomly
generated then a[i]|a[i+1] can be consider random too.
Gaston Gloesener wrote in message <7qm7qi$mun$[EMAIL PROTECTED]>...
>
>
>The named random number generators (RC4, IBAA, ISAAC are beased on an
>array of 32-bit (m) values and each run returns another array of the
>same size than the first giving a set of random numbers (r).
>
>What is the correct way to generate larger random numbers (>64 bits):
>
>Two Methods can be done:
>
>1. Handle large integers inside the algorithm, for example through a
>C++ class of huge binaries. The question here is if the algorithm works
>without any restrictions on large integers, or will the result no longer
>be high-quality random numbers ?
>
>2. Compute a set of results (r-array) and use consecutive 32-bit values
>to fill-up the resulting random number. Thus the first result of a 128
>bit random-number will be (r[0]<<96)|(r[1]<<64)|(r[2]<<32)|r[3],
>combining the first 4 32-values to one 128-bit value. This would be the
>way I would suggest, but is the result really satisfying all criteria
>of random numbers, especially the gussian-distribution ?
>
>Thanks,
>Gaston
>
>
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.
------------------------------
From: "Kostadin Bajalcaliev" <[EMAIL PROTECTED]>
Subject: Re: Some questions about stream ciphers
Date: Sat, 4 Sep 1999 18:19:47 +0200
DO NOT use Mush and Self shrinking generator or any LFSR, there simpler to
implement algorithms as RC4 to encrypt communication channel that secure (if
I correctly got your question).
Stefano Crispino wrote in message <7qke73$qme$[EMAIL PROTECTED]>...
>Hi to everyone. I'm a programmer (well, actually a sort of), and I need to
>realize a little (and FAST) encryption tool for a communication channel. So
>I immediately search for some provably secure s.c.. I found in AC two
>interesting models: Mush and Self shrinking generator. Have they been
>studied or cryptanalyzed nowadays? Can I safely implement one of them? I
>also need coefficients of some dense primitive polynomials mod 2 (the best
>would be A LOT of them), with 64 or 80 as the highest degree. Thanks for
>every help and suggestion.
>Ciao,
> Stefano Crispino
>
>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Mystery inc.
Date: Sun, 05 Sep 1999 03:57:58 GMT
[EMAIL PROTECTED] wrote:
> Looking for somewhere to discuss possible "real world" ciphers such as
> Poe and Beale.
> Where people can exchange and share their thoughts, info. and progress
> in such ciphers.
So far as net news groups go, sci.crypt seems to be the place.
Less interactive, but still of value, are articles in the ACA's
"The Cryptogram" and in "Cryptologia".
The nature of the Beale cipher is such that any real progress is
more likely to be exploited (by mounting a treasure-digging
expedition) than shared.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Different Encryption Algorithms
Date: 5 Sep 1999 03:03:45 GMT
entropy <[EMAIL PROTECTED]> wrote:
> I'm doing a high school research paper on different encryption algorithms,
> such as CAST, IDEA, blowfish, RCx, DES, etc. Could anyone point me to
> informative web sites pertaining to the differences between these encryption
> methods?
Try the Block Cipher Lounge :
http://www.ii.uib.no/~larsr/bc.html
-David
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: point of a cipher
Date: Sun, 05 Sep 1999 04:10:04 GMT
Tom St Denis wrote:
> The point of a cipher is to hide the contents of a message M with an
> encryption method E, and the key K. The goal is without knowledge
> of K, nothing of M can be derived from E_K(M).
First of all, that is an overly restrictive view.
More accurate would be the goal of requiring an eavesdropper
to perform more work than is economically feasible in order
to have a significant chance of recovering the plaintext.
> Now tell me where 'magical' compression methods come in. Either
> you know the key, and get the message, or you don't know the key
> and you only get random crap. I agree that compression helps
> remove redundancies, but it doesn't hinder brute-force or any
> other attack outisde of just trying to decompress what you guessed
> M could be.
As I've advised before, one should develop some practical experience
in cryptanalysis before trying to discuss its feasibility in any
particular case. In fact, I've cracked messages in some systems
without ever recovering the key. Precompression *does* hinder
cryptanalysis, because it obscures underlying statistical properties
of the source language that could otherwise be exploited. I don't
know why you even mention exhaustive keyspace search ("brute-force
attack"), because no competent cryptosystem designer is going to
choose a key so small as to make that attack feasible.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Description of SQ
Date: Sun, 05 Sep 1999 03:35:45 GMT
Kostadin Bajalcaliev wrote:
> ... Shannon theories are just theories nothing else, ...
That shows a profound misunderstanding of the usage of the word
"theory" in such contexts. Information theory, probability theory,
group theory, etc. are organized bodies of knowledge, not "just
theories" in the sense of "falsifiable hypotheses".
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Please help a newbie...
Date: Sun, 05 Sep 1999 03:51:59 GMT
In article <7qsj8s$[EMAIL PROTECTED]>,
"Kostadin Bajalcaliev" <[EMAIL PROTECTED]> wrote:
> Use hash function, hash the password and store the hash value into
> pass-file. Every time user log he/she enter the password, and the hash
> values are comapared. This maximum you can get. If you encrypt the pass-file
> you mast store the password somewhere in your program, so there is no
> advence in security.
>
Also salt the hashes to prevent dictionary attacks.
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Alleged NSA backdoor in Windows CryptoAPI
Date: Sun, 05 Sep 1999 03:41:13 GMT
DJohn37050 wrote:
> The obvious reason for an NSA key (assuming that is what it is) is to
> allow NSA to write their own CSP's without needing to get permission
> from Microsoft. That is, they can put in their algorithms without
> going to Microsoft for approval. But the CSP still needs to be put
> on the machine somehow and this is a voluntary act (as far as I
> know), so I do not see anything nefarious.
That's more or less how I see it, too, but I would add that this
illustrates the need to base *real* information security on open,
verifiable processes rather than on mysterious binary DLLs.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: NSA and MS windows
Date: 5 Sep 1999 04:51:02 GMT
In <7qsihm$ot5$[EMAIL PROTECTED]> [EMAIL PROTECTED]
(David Wagner) writes:
>They may not be, but regardless, it doesn't excuse claims that the
>"_NSAKEY" lets the NSA spy on every Windows box around the world.
>I haven't seen a single shred of evidence for claims like that.
>(I realize you're not making those types of claims. I guess I'm just
>disappointed with a lot of the reporting on this issue.)
>If MS or the NSA have committed some sin here, so far it appears to
>be at worst a minor one.
I do not think you understand cryptography. The key point is that users
are being forced to trust someone else when using something whose
purpose is precisely to protect against betrayal of trust. It is the
duty of the provider to convince the user that they can be trusted. In
all other software, incompetence or maliciousness can usually be
detected in the running or the output. Crypto is precisely something
where you cannot see from the output whether or not the crypto is
working.
Ie, it is the company who must, beyond a reasonable doubt, prove itself
trustworthy if they are to sell crypto, without source code so that the
consumer can check for themselves. It is not the consumer who must prove
lack of trust beyond a reasonable doubt.
MS has committed a sin in not explaining beforehand exactly what their
crypto api did and how it worked. They have compounded it by their
idiotic defense of their actions, and their continued refusal to come
clean.
The whole point of crypto is trust, and they have destroyed that trust.
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: DES cfb stream cypher and "whitening" or initialization
Date: Sun, 05 Sep 1999 05:01:07 GMT
In article <7qsl65$5fs$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <7qrflp$446$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Cary O'Brien) wrote:
>> I (like probably 10% of the readers) need to encrypt a data stream with a
>> stream cypher. I want to use des in cfb mode (specifically des_cfb64_encrypt
>> from libdes). The system will use shared secrets for keys. The problem
>> is that the packet structure of the underlying data stream would be know
>> to an attacker (ok, ok, it is ppp). I'm worried that this will provide
>> the attacker with a known-cleartext attack. Not good.
>>
>> I propose to insert 4 bytes of "random" data to the beginning of the
>> cleartext data stream on the encryption side, and drop the first 4 bytes
>> on the decryption side.
>>
>> 1) Is this worth the effort?
>> 2) Am I being otherwise stupid?
>>
>> Thanks,
>
>Here's a question.... why are you using des? Is this to be compatible with
>another app? In this case your question is moot.
>
>Otherwise... DROP DES. Use RC4 if you need a good stream cipher (or just
>make up some Algorithm M clone). RC4 is about 20 times faster, more compact
>and easier to get RIGHT. It's also not yet vulnerable to any known attack.
>
Actually, it is. If the attacker knows the plaintext of a message, he can
modify the ciphertext so that, when the receiver decrypts that modified
ciphertext, he gets a message of the attacker's choosing (of the same
length as the original message). In other words, the attacker can change:
"Pay to Alice: $1064.76"
to
"Pay to Mallet: $999999"
CFB is slightly stronger, in that if the attacker attempts to modify a
block, the next block will decrypt to garbage.
--
poncho
------------------------------
From: Dave Salovesh <[EMAIL PROTECTED]>
Subject: Re: NSA and MS windows
Date: Sun, 05 Sep 1999 01:08:58 -0400
In article <7qqgs3$oan$[EMAIL PROTECTED]>,
"Roger Schlafly" <[EMAIL PROTECTED]> opined:
>Maybe. Perhaps someone from the NSA suggested using a
>backup key, and the MS programmers called it the NSA key.
See <http://www.radium.ncsc.mil/tpep/process/faq-sect2.html#Q4>
"The NSA is prohibited by the Computer Security Act of 1987 from
attempting to directly address the needs of commercial systems."
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: arguement against randomness
Date: Sun, 05 Sep 1999 04:14:01 GMT
Tom St Denis wrote:
> Isn't one of the laws of thermaldynamics stating the spontaneuous
> creation of energy is impossible (or something to that effect)?
> Also wouldn't something truly random fall into this category?
> If I am dead wrong, please let me know.
You're close to dead wrong. Even if thermodynamic entropy were
the same as informational entropy (which it is *not*), all that
one could conclude is that one would have to expend some energy
in order to increase the amount of *order*. (Disorder tends to
increase on its own.)
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Crossposted-To: talk.politics.crypto
Subject: --- sci.crypt charter: read before you post (weekly notice)
Date: 5 Sep 1999 05:00:35 GMT
sci.crypt Different methods of data en/decryption.
sci.crypt.research Cryptography, cryptanalysis, and related issues.
talk.politics.crypto The relation between cryptography and government.
The Cryptography FAQ is posted to sci.crypt and talk.politics.crypto
every three weeks. You should read it before posting to either group.
A common myth is that sci.crypt is USENET's catch-all crypto newsgroup.
It is not. It is reserved for discussion of the _science_ of cryptology,
including cryptography, cryptanalysis, and related topics such as
one-way hash functions.
Use talk.politics.crypto for the _politics_ of cryptography, including
Clipper, Digital Telephony, NSA, RSADSI, the distribution of RC4, and
export controls.
What if you want to post an article which is neither pure science nor
pure politics? Go for talk.politics.crypto. Political discussions are
naturally free-ranging, and can easily include scientific articles. But
sci.crypt is much more limited: it has no room for politics.
It's appropriate to post (or at least cross-post) Clipper discussions to
alt.privacy.clipper, which should become talk.politics.crypto.clipper at
some point.
There are now several PGP newsgroups. Try comp.security.pgp.resources if
you want to find PGP, c.s.pgp.tech if you want to set it up and use it,
and c.s.pgp.discuss for other PGP-related questions.
Questions about microfilm and smuggling and other non-cryptographic
``spy stuff'' don't belong in sci.crypt. Try alt.security.
Other relevant newsgroups: misc.legal.computing, comp.org.eff.talk,
comp.org.cpsr.talk, alt.politics.org.nsa, comp.patents, sci.math,
comp.compression, comp.security.misc.
Here's the sci.crypt.research charter: ``The discussion of cryptography,
cryptanalysis, and related issues, in a more civilised environment than
is currently provided by sci.crypt.'' If you want to submit something to
the moderators, try [EMAIL PROTECTED]
---Dan
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: THINK PEOPLE
Date: Sun, 05 Sep 1999 02:48:49 GMT
In article <7qjtcd$1c5$[EMAIL PROTECTED]>,
Greg <[EMAIL PROTECTED]> wrote:
> I think you got a point.
>
Where was his point?
Duh, if I use a stream cipher and the same key a million times is that
safe... no he doesn't have a point.
With a proper salt method even if you find the session key for one message
you will not find the master key for all sessions.
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Second "_NSAKey"
Date: Sat, 4 Sep 1999 23:22:04 -0500
Ed Stone <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
<snip> <sorry, my news server won't let me post "too much" quoted material">
>
> As Andrew says, "Export controll is effectively dead for Windows."
>
> So if a person wanted to create his own CSP, and sign it with his own
> key, and then load his public key to replace _NSAKey, he would have
> altered the cryptographic strength that comes out of apps that use the
> CAPI....
>
> Might that be why the NSA wants a second key, whether they have it or
> not, if in fact, that allegation is correct? If Andrew is correct that
> the hack above allows one to load his own CSP regardless of MS or NSA
> approval, why would NSA "require" an approach that destroys the MS
> control over what CSPs are allowed by the CAPI?
>
Let's see if I've got this correctly:
1. There is an MS key (_Key) used to validate CSPs for CAPI.
2. If CSPs validate correctly using _Key, they will be loaded and used, otherwise, not.
3. There is another key (_NSAKey) which can also validate CSPs, and the CSPs can be
used.
4. Any attempt to change or replace _Key will disable use of CAPI.
5. I can replace _NSAKey and it will not disable CAPI.
6. I can replace _NSAKey with my own and sign my own CSP with it and my CSP can be
used.
7. The existence of _NSAKey was just recently discovered when debugging symbols were
"accidently" left in release code, even though
the _NSAKey goes back to Win95.
8. The "replaceability" of _NSAKey **does** effectively destroy control of what CSPs
can be used under CAPI.
Does anyone have any idea of how many copies of Windows which use CAPI there are in
use worldwide?
I suspect that the probability is zero that all those copies of Windows can be
modified to restore export control over Windows.
Doesn't anyone else think it strange that _Key cannot be replaced without disabling
CAPI but _NSAKey can?
Is there a virus called "time bomb" that works essentially the same way (i.e. wait
until a certain date and time, or a certain
amount of time, then do your thing)?
I guess if you believe in accidents, coincidence, and the total collapse of Murphy's
Law, then anything is possible.
Rick
------------------------------
From: Dennis To <[EMAIL PROTECTED]>
Subject: Are there any RSA encryption / decryption source in JAVA ?
Date: Sun, 05 Sep 1999 13:41:10 +0800
==============E79058EE75E2A29CA0A5AC17
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Any one know where I can find source for RSA encryption and decryption
in JAVA so that I can use it in my school project ?
Dennis
==============E79058EE75E2A29CA0A5AC17
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<TT>Any one know where I can find source for RSA encryption and decryption
in JAVA so that I can use it in my school project ?</TT><TT></TT>
<P><TT>Dennis</TT></HTML>
==============E79058EE75E2A29CA0A5AC17==
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: 512 bit number factored
Date: Sat, 4 Sep 1999 22:16:55 -0700
Bob Silverman wrote in message <7qsig0$3jr$[EMAIL PROTECTED]>...
>We do that now. The sieve region is partitioned into pieces that
>fit in cache. The problem is that as the modulus increases, so must
>the factor base. Most of the memory requirements for sieving come
>not from the sieve region, but from the two factor bases, the roots
>of the polynomials modulo those primes, the sieve start and end points,
>and saving the sieve start points so factoring may be done by resieving.
>
>If you start paging this data, sieving slows to a crawl.
>
>Have you implemented the algorithm? Your response shows
>a superficial view of what is really required to make it work.
Even with a superficial knowledge, one can guess that someone
will find a way to implement the algorithm with paging efficiently.
Just about every other algorithm can be paged efficiently if done
cleverly.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: NSA and MS windows
Date: Sat, 4 Sep 1999 22:15:19 -0700
David Wagner wrote in message
<7qsihm$ot5$[EMAIL PROTECTED]>...
>In article <7qs5q0$[EMAIL PROTECTED]>,
>Roger Schlafly <[EMAIL PROTECTED]> wrote:
>> I don't think MS is telling us the full story.
>
>They may not be, but regardless, it doesn't excuse claims that the
>"_NSAKEY" lets the NSA spy on every Windows box around the world.
>I haven't seen a single shred of evidence for claims like that.
>
>(I realize you're not making those types of claims. I guess I'm just
>disappointed with a lot of the reporting on this issue.)
>
>If MS or the NSA have committed some sin here, so far it appears to
>be at worst a minor one.
You gotta admit that it is a tantalizing tidbit of info for the press.
It links two of the great boogeymen of the net -- MS and NSA.
People will believe any conspiracy about either of them, and
this story has both. It is like finding out that Vince Foster had an
affair with Janet Reno. <g>
Why is there a big uproar over the recent revelations about
pyrotechnics being used at Waco, when it is very unlikely that
those pyrotechnics had anything to do with the big fire?
It is because it is a smoking gun that shows that the govt
has been lying and covering up facts about Waco. We don't
like being lied to, and we wonder what they are still lying about.
Likewise, in the view of many, MS and NSA have too much
power, are too secretive, and are not leveling with us. The
"NSAKEY" is evidence of a link, and they are acting like kids
who got caught with their hands in the cookie jar. Until MS
documents CryptoAPI a little better, people are going to be
suspicious.
------------------------------
** 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
******************************
