Cryptography-Digest Digest #866, Volume #13 Sun, 11 Mar 01 19:13:01 EST
Contents:
Re: Blowfish name (SCOTT19U.ZIP_GUY)
Re: [REQ] SHA-1 MD5 hashing software (Eric Lee Green)
Re: Noninvertible encryption ("Douglas A. Gwyn")
Re: Really simple stream cipher ("Henrick Hellstr�m")
Re: Really simple stream cipher (David Wagner)
Re: FIPS 140-2 PRG (Gregory G Rose)
Quantum Computing & Key Sizes (Tom McCune)
Re: Quantum Computing & Key Sizes ("Tom St Denis")
Re: Text of Applied Cryptography (Anonymous)
Re: RSA encryption on Windows -- C++ source code (Ben Cantrick)
Re: Quantum Computing & Key Sizes ([EMAIL PROTECTED])
Re: Quantum Computing & Key Sizes ("Sam Simpson")
Re: Freeware issues? ("Nick Payne")
Re: => FBI easily cracks encryption ...? (CR Lyttle)
Re: Quantum Computing & Key Sizes (Tom McCune)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Blowfish name
Date: 11 Mar 2001 21:59:05 GMT
[EMAIL PROTECTED] (Liam McGann) wrote in
<TfSq6.9082$[EMAIL PROTECTED]>:
>Anyone know where Blowfish gots its name?
>
>Thanks,
>
>L.M.
>
>
>
I could guess break it up into words "blow fish". Two
nice 4 letter words let you imagination run. Also if
I worked for the NSA and wanted to trick people into
using fishy software what better name. It would be
funny. Note these just my thoughts I have no idea why
he named it that. I also don't think I would belive the
originator if he told me while on truth serum during a
polygraph test while he was under hypnosis and knew if
he lied his loved ones assuming the person had any would be
terminated.
David A. Scott
P.S. I hope that helps.
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: [REQ] SHA-1 MD5 hashing software
Reply-To: [EMAIL PROTECTED]
Date: 11 Mar 2001 16:04:23 -0600
On Sun, 11 Mar 2001 21:20:14 GMT, Doom the Mostly Harmless <[EMAIL PROTECTED]
> wrote:
><snip>
>> Oh boy trialware... hot digittiy. Who on earth would buy an
>implementation
>> of SHA?
>
>Someone without your 3l33t k0d1ng sk1LLz? :-)
Or somebody too stupid to go to:
http://www.openssl.org
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/
http://www.eskimo.com/~weidai/cryptlib.html
http://www.cryptix.org/
etc. etc. etc.
But what can I say, there's a sucker born every day.
--
Eric Lee Green [EMAIL PROTECTED] http://www.badtux.org
AVOID EVIDENCE ELIMINATOR -- for details, see
http://badtux.org/eric/editorial/scumbags.html
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
Date: Sun, 11 Mar 2001 22:24:54 GMT
"SCOTT19U.ZIP_GUY" wrote:
> One would like to be able to give a false key so they will be happy.
However, if the decryption is gibberish they won't be happy.
So you at the very least would want a system that encrypts
both the real message and an alternate, meaningful message
under separate keys. This isn't hard under the usual OTP
system, because you can take the CT and fake PT and easily
find a corresponding key, but for systems with short keys
it's not going to be possible unless you allow the CT to be
about twice as large as would otherwise be necessary.
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Sun, 11 Mar 2001 23:40:11 +0100
Well, no, that's not the way I view it. I view crypto engines as (a)
inflexible, (b) performance sinks and (c) potential security risks, at least
those that are linked to / called by the executable at run time. It is not
that hard to write a dll-file called e.g. "cryptnet.dll" with the right
interface entries but with rigged implementations, and plant it in a
computer of your choice. Since the dll is there and it has the right
interface entries, the application will happily inform the user that he has
connected securely - although he hasn't, because the person who planted the
dll has made sure that he is able to mount a MITM attack.
Sure, you could perform the same kind of attack against any kind of
executable, but on e.g. Win32 platforms a dll file is usually well hidden in
the system directory under a suspiciously non-informative name. Few users
would know which file to check if they suspected that someone had tampered
with the internet security functions of their computer. Most users would
however, at least with a little help, be able to locate a stand alone
executable file. And that's the one they would check if they were to check
anything. Security products and security dependent products should
preferrably not call any library files at all, at least none that might have
any impact of the security of the product.
Maybe I am a bit over paranoid, and maybe key stroke recorders are a bigger
threat. But why should the users be exposed to yet another risk just because
they already are exposed to other risks? (travesty ;-))
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
"David Wagner" <[EMAIL PROTECTED]> skrev i meddelandet
news:98grkj$bvs$[EMAIL PROTECTED]...
> Yes. All of those other recommendations [avoid ECB mode, change session
> keys, make sure stupid applications can't cause re-use of IV's, etc.] are
> good ones. But so what? Good crypto layers already follow all this
> advice. And there's no reason they can't follow one more guideline:
> namely, make sure the app never gets to see decrypted data unless it
> has been correctly MAC'ed. This is not hard to do.
>
> I do suspect you may be viewing this the wrong way. You seem to be
> arguing: "Some crypto engines expose apps to certain types of risks,
> therefore it can't hurt to add yet another risk". This is asking for
> trouble. Better is to say "Some crypto engines expose apps to certain
> types of risks, therefore it would be prudent to eliminate as many risks
> as we can, and to minimize the number of failure modes we can't avoid".
> The existence of one pitfall does not justify adding still more pitfalls!
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Really simple stream cipher
Date: 11 Mar 2001 22:49:09 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Henrick Hellstr�m wrote:
>Well, no, that's not the way I view it. I view crypto engines as (a)
>inflexible, (b) performance sinks and (c) potential security risks, at least
>those that are linked to / called by the executable at run time. It is not
>that hard to write a dll-file called e.g. "cryptnet.dll" with the right
>interface entries but with rigged implementations, and plant it in a
>computer of your choice. Since the dll is there and it has the right
>interface entries, the application will happily inform the user that he has
>connected securely - although he hasn't, because the person who planted the
>dll has made sure that he is able to mount a MITM attack.
Huh? Whether you use static vs. dynamic linking is orthogonal
to what your crypto code does. When I say "crypto engine", I'm
referring to what your crypto code does (i.e., whether it uses
a MAC or not, whether it uses CBC mode or CFB mode), no matter
whether it's in a DLL or hard-coded into your application.
If you're having troubles with spoofed DLL's, you may want to
re-consider your choice of operating systems.
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: FIPS 140-2 PRG
Date: 11 Mar 2001 15:00:09 -0800
In article <98fl0s$a4k$[EMAIL PROTECTED]>,
Yoad Lustig <[EMAIL PROTECTED]> wrote:
>I've recently implemented the test (FIPS 140-2) and run it on the first
>three files from marsglia's
>random CD. I got considerably more failures then the expected 0.0001
>(time 5 tests).
>
>Does anyone know whether there is a mistake in the document? or
>there is an implementation of the test I can use as reference to check my
>code?
The tests are "two-ended" so in fact you expect
twice as many failures as the "P" value. But if
you got more than 0.0002 by ratio I think there's
something wrong either with your code or
Marsaglia's numbers (but probably your code).
I have an unencumbered FIPS-140-2 program at
http://www.home.aone.net.au/qualcomm that you can
use to either duplicate or refute your result.
I've used it as a quick verification for attacks
on stream ciphers and almost always get the
expected results (with the occasional "eureka"
when I don't...)
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199
Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/
Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
------------------------------
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Quantum Computing & Key Sizes
Date: Sun, 11 Mar 2001 23:18:51 GMT
On page 361 of Secrets & Lies, Bruce Schneier states
"Quantum computation techniques will render most public-key algorithms
obsolete..., but will only force us to double the key lengths for symmetric
ciphers, hash functions, and MACs."
Does this suggest that the newer PGP symmetric algorithm options of 256
Twofish and AES, would be sufficient (they are twice the key lengths of the
128 bit symmetric algorithms used by PGP at the time of that writing)?
At least one of the papers submitted to NIST during the AES selection
process suggested that brute force attacking these 256 bit algorithms would
be equivalent to factoring a 15000 bit RSA key. So if these 256 bit
algorithms would withstand Quantum Computing, wouldn't that also suggest
that a 15k RSA or DH key would also withstand that attack?
Using currently available official PGP public key sizes, would such Quantum
Computing attacking have a significant time difference in factoring a 2048
bit key, instead of a 4096 bit key?
Tom McCune
http://www.McCune.cc
Please use PGP for Privacy & Authenticity
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Quantum Computing & Key Sizes
Date: Sun, 11 Mar 2001 23:23:03 GMT
"Tom McCune" <[EMAIL PROTECTED]> wrote in message
news:vJTq6.241159$[EMAIL PROTECTED]...
> On page 361 of Secrets & Lies, Bruce Schneier states
>
> "Quantum computation techniques will render most public-key algorithms
> obsolete..., but will only force us to double the key lengths for
symmetric
> ciphers, hash functions, and MACs."
>
> Does this suggest that the newer PGP symmetric algorithm options of 256
> Twofish and AES, would be sufficient (they are twice the key lengths of
the
> 128 bit symmetric algorithms used by PGP at the time of that writing)?
>
> At least one of the papers submitted to NIST during the AES selection
> process suggested that brute force attacking these 256 bit algorithms
would
> be equivalent to factoring a 15000 bit RSA key. So if these 256 bit
> algorithms would withstand Quantum Computing, wouldn't that also suggest
> that a 15k RSA or DH key would also withstand that attack?
>
> Using currently available official PGP public key sizes, would such
Quantum
> Computing attacking have a significant time difference in factoring a 2048
> bit key, instead of a 4096 bit key?
Trollboy. There doesn't exist enough matter to use to make the ram required
to factor a 15kbit #. Regardless of the time...
Tom
------------------------------
Date: Sat, 10 Mar 2001 20:32:02 +0100
From: Anonymous <Use-Author-Address-Header@[127.1]>
Subject: Re: Text of Applied Cryptography
Crossposted-To: alt.security.pgp,talk.politics.crypto,alt.pot.kettle.black
On Sat, 10 Mar 2001, Nomen Nescio <[EMAIL PROTECTED]> wrote:
>Tom St Denis [EMAIL PROTECTED] wrote:
>> <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]...
>> > On Fri, 9 Mar 2001 17:31:37 -0500, "Ryan M. McConahy"
>> > <[EMAIL PROTECTED]> wrote:
>> > Handbook of Applied Cryptography
>> > http://www.cacr.math.uwaterloo.ca/hac
>> > Applied Cryptography: Schneier
<Link to copywritten material SNIPPED>
>> Wow you did an amazing dis-service to Schneier today.
>>
>> Tom
>
>You are doing an amazing dis-service to Schneier everyday, then what ?
>F___k off from this place, Tom.
Sheesh!
Check the followups and consider yourselves suitably admonished children.
------------------------------
From: [EMAIL PROTECTED] (Ben Cantrick)
Subject: Re: RSA encryption on Windows -- C++ source code
Date: 11 Mar 2001 16:39:35 -0700
In article <98ghpg$eel$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>So, what I've been trying to find is some C++ source code that fits the
>following criteria:
>- small: maybe < 20K, otherwise I'd love to use Wei Dai's Crypto++,
>- working on > Windows 98
>- free or very cheap
>- legal internationally or modifiable to handle export regulations
>- usable in a commercial product
>
>and maybe if I'm lucky, also:
>- easy-to-use
>- well-documented
I can't guarantee it meets all those conditions, but I think the
source code for older version of PGP is floating around out there
somewhere. You could tear most of what you need out of that, probably.
I doubt it would be as small as you want. I would also think there
would be licensing issues to deal with, but maybe if it's just for
academic use they'd let you have it free.
-Ben
--
Ben Cantrick ([EMAIL PROTECTED]) | Yes, the AnimEigo BGC dubs still suck.
BGC Nukem: http://www.dim.com/~mackys/bgcnukem.html
The Spamdogs: http://www.dim.com/~mackys/spamdogs
Dem0nseed sez - "Read cDc or I'll crush your skull, r0dent!"
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Quantum Computing & Key Sizes
Date: 11 Mar 2001 15:37:06 -0800
Tom McCune <[EMAIL PROTECTED]> writes:
> On page 361 of Secrets & Lies, Bruce Schneier states
>
> "Quantum computation techniques will render most public-key algorithms
> obsolete..., but will only force us to double the key lengths for symmetric
> ciphers, hash functions, and MACs."
>
> Does this suggest that the newer PGP symmetric algorithm options of 256
> Twofish and AES, would be sufficient (they are twice the key lengths of the
> 128 bit symmetric algorithms used by PGP at the time of that writing)?
Yes, even with a QC it should take 2^128 work to break a 256 bit AES
key.
> At least one of the papers submitted to NIST during the AES selection
> process suggested that brute force attacking these 256 bit algorithms would
> be equivalent to factoring a 15000 bit RSA key. So if these 256 bit
> algorithms would withstand Quantum Computing, wouldn't that also suggest
> that a 15k RSA or DH key would also withstand that attack?
These kinds of equivalence calculations require making assumptions on
the type of attack used against the public key algorithm. Quantum
computers would provide for different kinds of attacks and so the
equivalence would not hold.
> Using currently available official PGP public key sizes, would such Quantum
> Computing attacking have a significant time difference in factoring a 2048
> bit key, instead of a 4096 bit key?
Shor's algorithm for RSA factoring using a quantum computer takes time
proportional to the third power of the modulus size. So the 4096 key
would take 8 times longer than a 2048 bit key, which would take 8
times longer than a 1024 bit key, and so on. Of course you need twice
as big a quantum computer to handle twice as long a modulus, and that
might also slow things down if more time was needed for error
correction, etc.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Quantum Computing & Key Sizes
Date: Sun, 11 Mar 2001 23:51:12 -0000
Calling everyone who asks a question that doesn't measure up to your
intelect 'trollboy' is hardly constructive.
PS: He's specifically asking about Quantum Computers, not conventional 'RAM
limited' computing, maybe you should have considered this before idly
flaming.
And you wonder why people don't take you seriously?
--
Regards,
Sam
http://www.scramdisk.clara.net/
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:rNTq6.15132$[EMAIL PROTECTED]...
>
> "Tom McCune" <[EMAIL PROTECTED]> wrote in message
> news:vJTq6.241159$[EMAIL PROTECTED]...
> > On page 361 of Secrets & Lies, Bruce Schneier states
> >
> > "Quantum computation techniques will render most public-key algorithms
> > obsolete..., but will only force us to double the key lengths for
> symmetric
> > ciphers, hash functions, and MACs."
> >
> > Does this suggest that the newer PGP symmetric algorithm options of 256
> > Twofish and AES, would be sufficient (they are twice the key lengths of
> the
> > 128 bit symmetric algorithms used by PGP at the time of that writing)?
> >
> > At least one of the papers submitted to NIST during the AES selection
> > process suggested that brute force attacking these 256 bit algorithms
> would
> > be equivalent to factoring a 15000 bit RSA key. So if these 256 bit
> > algorithms would withstand Quantum Computing, wouldn't that also suggest
> > that a 15k RSA or DH key would also withstand that attack?
> >
> > Using currently available official PGP public key sizes, would such
> Quantum
> > Computing attacking have a significant time difference in factoring a
2048
> > bit key, instead of a 4096 bit key?
>
> Trollboy. There doesn't exist enough matter to use to make the ram
required
> to factor a 15kbit #. Regardless of the time...
>
> Tom
>
>
------------------------------
From: "Nick Payne" <[EMAIL PROTECTED]>
Subject: Re: Freeware issues?
Date: Mon, 12 Mar 2001 11:01:13 +1100
Cryptext will recursively encrypt directories.
http://www.tip.net.au/~njpayne/.
Nick
"Dan Hargrove" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> 1) Folder encryption
>
> There seem to be only a few products available to encrypt whole folders.
> Abi-Coder encrypts folders, but leaves them and their contents open for
> inspection. Folders lite encrypts folders, but as in the case of Abi-
> Coder, does not support recursive folders (or folders within folders). Is
> there a freeware (or free) product that encrypts and locks recursive
> folders with Blowfish or a similarly strong algorithm?
------------------------------
From: CR Lyttle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Mon, 12 Mar 2001 00:00:21 GMT
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (CR Lyttle) wrote in
> <[EMAIL PROTECTED]>:
>
> >Phil Zimmerman wrote:
> >>
> >> What encryption was Hansen using that it was so easily cracked?
> >
> >It was probably not anything very sophisticated, I would think. After
> >all Hansen was keeping his id secret from the Russians and they do not
> >seem to have been in regular electronic contact. If Hansen was using
> >anything as complex as PGP then he probably used only one key pair that
> >the FBI got from his home. Exchanging new keys for each transmission
> >requires two physical contacts, which increases the chances of being
> >detected. Most of the battle is knowing something is happening. So
> >whatever he used, it was probably pretty simple and designed to keep out
> >casual snoopers.
> >
>
> I can see for a first contact or even for a few months or even
> a year simple encryption may have been used. But give me a break
> he was an agent for MANY YEARS do you really think that he would
> have used a very simple encryption method just to keep out casual
> snoopers when he knew that if he was caught it meant death.
> I think he used at least something that is as secure as PGP.
> I am not saying he used PGP. Since he may have been in a position
> to know that it may be weak. I am just saying he most likely used
> something he considered very secure.
>
> David A. Scott
> --
>>SNIP<<
So where did he get his keys? Think about the field logistics. Each
exchange entails a risk of detection. To do crypto requires an exchange
of keys separate from the exchange of messages. Therefore each exchange
of keys means a risk of detection. So keys won't be exchanged very
frequently. Therefore, it is highly unlikely that something like DES or
1024 bit key PGP will be used. If he did use something like PGP, the key
wasn't changed often and the FBI probably found it (or them) on his
computer. Plus what is the reason for doing encryption in a case like
this? It is important to keep the very existence of a transfer secret.
If the existence of a transfer is secret, why encrypt it? Probably the
Russians trained Hansen is some simple technique just to make him feel
better. The FBI, in turn, probably found the key in Hansen's residence,
or got him to reveal it.
The problem with most crypto is key control. The best crypto is useless
if the key is known.
--
Russ
<http://home.earthlink.net/~lyttlec>
Home of the Universal Automotive Test Set
Linux Open Source (GPL) Project
------------------------------
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: Quantum Computing & Key Sizes
Date: Mon, 12 Mar 2001 00:00:06 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>> Does this suggest that the newer PGP symmetric algorithm options of 256
>> Twofish and AES, would be sufficient (they are twice the key lengths of the
>> 128 bit symmetric algorithms used by PGP at the time of that writing)?
>
>Yes, even with a QC it should take 2^128 work to break a 256 bit AES
>key.
>
>> At least one of the papers submitted to NIST during the AES selection
>> process suggested that brute force attacking these 256 bit algorithms would
>> be equivalent to factoring a 15000 bit RSA key. So if these 256 bit
>> algorithms would withstand Quantum Computing, wouldn't that also suggest
>> that a 15k RSA or DH key would also withstand that attack?
>
>These kinds of equivalence calculations require making assumptions on
>the type of attack used against the public key algorithm. Quantum
>computers would provide for different kinds of attacks and so the
>equivalence would not hold.
Are these different kinds of attack theoretical possibilities only at this
point, or are there good reasons to believe they are probable? Any
reasonable implication as to how key sizes with such newly available attacks
would relate to current attacks? Such as 16k QC (new attack) equating to 4k
"conventional" attacking? I hope that question makes sense.
>> Using currently available official PGP public key sizes, would such Quantum
>> Computing attacking have a significant time difference in factoring a 2048
>> bit key, instead of a 4096 bit key?
>
>Shor's algorithm for RSA factoring using a quantum computer takes time
>proportional to the third power of the modulus size. So the 4096 key
>would take 8 times longer than a 2048 bit key, which would take 8
>times longer than a 1024 bit key, and so on. Of course you need twice
>as big a quantum computer to handle twice as long a modulus, and that
>might also slow things down if more time was needed for error
>correction, etc.
I should have phrased that better. Would this be a matter of breaking a
2048 bit key in an hour, and a 4096 bit key in 8 hours, or more like
breaking a 2048 bit key in a week, and a 4096 bit key in 2 months?
I greatly appreciate your quick, sincere, and informative reply. I can't
believe Tom couldn't tell this is a sincere inquiry.
Tom McCune
http://www.McCune.cc
Please use PGP for Privacy & Authenticity
------------------------------
** 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
******************************
