Cryptography-Digest Digest #197, Volume #10 Wed, 8 Sep 99 03:13:06 EDT
Contents:
Totally off topic ("rosi")
Confused about public key encryption (Timur Tabi)
Re: Win Crypto libs, was: Help with CryptoAPI: can not do the simplest
(SCOTT19U.ZIP_GUY)
Random and pseudo-random numbers (Eric Lee Green)
Re: GnuPG 1.0 released (SCOTT19U.ZIP_GUY)
Re: simple key dependent encryption (SCOTT19U.ZIP_GUY)
Re: Random and pseudo-random numbers (David A Molnar)
Re: Plaintext block size ("Kwong Chan")
Re: THE NSAKEY (fungus)
Re: GnuPG 1.0 released
Re: _NSAKey (Teonanacatl)
Re: Random and pseudo-random numbers
Re: Ways to steal cookies in HTTP and HTTPS (John Pliam)
----------------------------------------------------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Totally off topic
Date: Tue, 7 Sep 1999 22:20:36 -0400
rosi wrote in message <7r1uei$hnt$[EMAIL PROTECTED]>...
[snip]
>
> Overheard (coming from land that went through some kind of fanatic
>worshiping): Absolute truth is right-wherever-you-put-it nonsense. :)
>
I think I can safely guarantee that the utterer is absolutely no
mathmatician.
------------------------------
From: Timur Tabi <[EMAIL PROTECTED]>
Subject: Confused about public key encryption
Date: Wed, 08 Sep 1999 02:54:13 GMT
Hi,
I've been reading all sorts of web pages and
newsgroup posts, and I've even been reading the book
"Applied Cryptography", but I just cannot find what
I'm looking for. I know it can't be that difficult,
so I know I'm doing something incredibly stupid.
I am looking for source code for patent-free public
key encryption and decryption. The only two I know
of are RSA and Diffie-Hellman, and I can't seem to
find any source code for Diffie-Hellman.
What I need to do is encrypt and digitally sign a
short plaintext (about 100 bytes), and then decrypt
and verify the plaintext. So I need source code for
the encryption part, and source code for the
decryption part. Some people have pointed me to
pgpi.com or openssl.org, but I can't find anything
there that I can use. The whole thing is very
confusing, and I have some questions:
1. What patent-free algorithms are there besides
Diffie-Hellman?
2. It appears to me that (maybe) public key
encryption algorithms use symmetric key algorithms as
their basis. This doesn't make any sense to me. What
does DES have to do with PGP?
3. Apparently, PGP is not an algorithm per se, but a
way to implement encryption algorithms in such a way
to get public-key encryption. Again, I can't
understand how.
I have a dream. In this dream, I check my email, and
the email contains the source code to two functions:
void encrypt(char *plaintext, char *privatekey, char
*ciphertext);
Takes plaintext and privatekey as input, output is
ciphertext.
int decrypt(char *ciphertext, char *publickey, char
*plaintext);
Takes ciphertext and publickey as input, outputs
plaintext. Returns a 1 if the ciphertext is valid
(hasn't been tampered with), or a 0 otherwise.
Can anyone make my dream into reality?
--
Remove "nospam_" from my email address when replying
Timur "too sexy for my code" Tabi, [EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To:
microsoft.public.win32.programmer.networks,microsoft.public.win32.programmer,comp.os.ms-windows.programmer.win32
Subject: Re: Win Crypto libs, was: Help with CryptoAPI: can not do the simplest
Date: Wed, 08 Sep 1999 04:56:44 GMT
In article <[EMAIL PROTECTED]>, Taavo Raykoff <[EMAIL PROTECTED]> wrote:
>Okay, given that, does anyone have any suggestions for a library of
>basic crypto routines that will run on windows? I need DES, RC2, SHA,
>and HMAC.
>
>Thanks!!
>tr
>
>John Savard wrote:
>
>> Taavo Raykoff <[EMAIL PROTECTED]> wrote, in part:
>>
>> >How hard is it to allow importing the raw keys into CryptoAPI?
>>
>> The CryptoAPI is designed to prevent unauthorized use of its
>> functions, so that, for example, a foreign customer permitted to use
>> 56-bit encryption won't be able to use the provided DES function to
>> perform 112-bit or 168-bit Triple DES encryption.
>>
>> Hence, the CryptoAPI should be avoided unless you have a specific
>> export compliance requirement.
>>
>> John Savard ( teneerf<- )
>> http://www.ecn.ab.ca/~jsavard/crypto.htm
>
Well if you follow the threads on the NSA key you can replace it with
one of your choice and then use the CryptoAPI to allow any module of
your choice. This way you don't have to be subject to US export laws.
And if Bertsein is right at his site once you buy windows and mode it. Its
yours regardless of what there license says.
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: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Random and pseudo-random numbers
Date: Tue, 07 Sep 1999 20:38:56 -0700
Yarrow burrows into the innards of Windows to grab entropy. /dev/random
on Linux and FreeBSD uses various pieces of entropy within the OS. One
nice source of entropy is to use the low-order byte of a timer at the
exact time that you get keystrokes (the old PGP method). None of these
are working for me if I'm wanting my code to run on HPUX, Solaris, or
SCO Unix in unattended mode.
I looked at the whrandom.py included with Python and it's pathetic.
There are 2**24 possible initial states that the generator can start in,
meaning that if I start the generator immediately upon entering Python
and generate a key, it is one of those 2**24 keys irregardless of how
many bits I make the key or where I grab the bytes from to initialize
the generator. Obviously I need a generator that has a larger number of
initial states, no matter where I get the entropy from (and I think I
can find enough places to grab entropy to get the generator initialized,
even if I won't be able to get enough randomness to generate truly
random numbers).
Anyhow: Anybody have a suggestion here? One suggest I've seen is to use
my initial generated value (grabbing randomness from wherever I can find
it and feeding it into a hash routine such as MD5) as the key to a
cipher routine that operates upon non-random but constantly changing
inputs such as a timer and the amount of CPU time used so far by this
process (RC5 or RC6, being very simple, look like real possibilities
here), which assuming that my initial seed values are truly random
sounds like it would produce unpredictable output (which is all I care
about, unpredictability, I have to generate numerous 1024-bit keys and
don't want them to be predictable). But am I overestimating the
pseudo-random properties of the output of a cipher such as RC6?
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: GnuPG 1.0 released
Date: Wed, 08 Sep 1999 04:47:13 GMT
In article <7r4aj1$rlt$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Matthew
Skala) wrote:
>A number of people here have been wondering when GnuPG would be out of
>beta, and I haven't seen the release announced in sci.crypt yet, so I hope
>it's okay for me to post it:
>
>From [EMAIL PROTECTED] Tue Sep 7 17:22:25 1999
>Date: Tue, 7 Sep 1999 20:01:00 +0200
>From: Werner Koch <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: GnuPG 1.0 released
>Resent-Date: Tue, 7 Sep 1999 20:10:56 +0200
>Resent-From: [EMAIL PROTECTED]
>
>Hello folks,
>
>after about 9 months of Beta testing, I am now glad to tell you that I
>released the
>
> GNU Privacy Guard 1.0
>
>a few minutes ago. As usual it should build right out of the box on
>all GNU/Linux systems and most other Unices too.
>
>Get it from the FTP server or from one of the mirrors:
>
> ftp://ftp.gnupg.org/pub/gcrypt/gnupg/gnupg-1.0.0.tar.gz (1332k)
>
>Do not forget to verify the signature or the MD5 checksum, which is:
>
> bba45febd501acf8e19db402506dae94 gnupg-1.0.0.tar.gz
>
>You can also download a patch file:
>
> ftp://ftp.gnupg.org/pub/gcrypt/gnupg/gnupg-0.9.11-1.0.0.diff.gz (140k)
>
>This version is intended as a stable production version and we will
>only apply bug fixes and small enhancements to it. We will soon set
>up a development version 1.1 to play a little bit with the code ;-)
>
>The GNU Privacy Guard has been created by the GnuPG team:
>
>Matthew Skala, Michael Roth, Niklas Hernaeus, Rémi Guyomarch
>and Werner Koch. Gael Queri, Gregory Steuck, Janusz A. Urbanowicz,
>Marco d'Itri, Thiago Jung Bauermann, Urko Lusa and Walter Koch
>did the official translations. Mike Ashley is working on the
>GNU Privacy Handbook.
>
>The following people helped greatly by suggesting improvements,
>testing, fixing bugs, providing resources and doing other important
>tasks: Allan Clark, Anand Kumria, Ariel T Glenn, Bodo Moeller,
>Bryan Fullerton, Brian Moore, Brian Warner, Caskey L. Dickson,
>Cees van de Griend, Charles Levert, Christian von Roques,
>Christopher Oliver, Christian Recktenwald, Daniel Eisenbud,
>Daniel Koenig, David Ellement, Detlef Lannert, Dirk Lattermann,
>Ed Boraas, Enzo Michelangeli, Ernst Molitor, Fabio Coatti,
>Felix von Leitner, Frank Heckenbach, Frank Stajano, Gaël Quéri,
>Greg Louis, Greg Troxel, Gregory Steuck, Geoff Keating, Harald Denker,
>Hendrik Buschkamp, Holger Schurig, Hugh Daniel, Ian McKellar,
>Janusz A. Urbanowicz, James Troup, Jean-loup Gailly, Jens Bachem,
>Joachim Backes, John A. Martin, Johnny Teveßen, Jörg Schilling,
>Jun Kuriyama, Karl Fogel, Karsten Thygesen, Katsuhiro Kondou,
>Kazu Yamamoto, Lars Kellogg-Stedman, Marco d'Itri, Mark Adler,
>Mark Elbrecht, Markus Friedl, Martin Kahlert, Martin Hamilton,
>Martin Schulte, Matthew Skala, Max Valianskiy, Michael Roth,
>Michael Sobolev, Nicolas Graner, NIIBE Yutaka, Niklas Hernaeus,
>Nimrod Zimerman, N J Doye, Oliver Haakert, Oskari Jääskeläinen,
>Paul D. Smith, Philippe Laliberte, Peter Gutmann, QingLong,
>Ralph Gillen, Rat, Reinhard Wobst, Rémi Guyomarch, Reuben Sumner,
>Roland Rosenfeld, Ross Golder, Serge Munhoven, SL Baur, Stefan Karrmann,
>Stefan Keller, Steffen Ullrich, Steffen Zahn, Steven Bakker,
>Susanne Schultz, Thiago Jung Bauermann, Thomas Roessler, Tom Spindler,
>Tom Zerucha, Tomas Fasth, Thomas Mikkelsen, Ulf Möller, Urko Lusa,
>Walter Koch, Wim Vandeputte and Gerlinde Klaes.
>
>This software has been made possible by the previous work of
>Chris Wedgwood, Jean-loup Gailly, Jon Callas, Mark Adler, Martin Hellmann
>Paul Kendall, Philip R. Zimmermann, Peter Gutmann, Philip A. Nelson,
>Taher ElGamal, Torbjorn Granlund, Whitfield Diffie, some unknown NSA
>mathematicians and all the folks who have worked hard to create complete
>and free operating systems.
>
>
>Enjoy,
>
> Werner
>
>
Does it still have the weaknesses that I fell plague the old PGP.
Namely is the compression one to one or is it of a form helpful to
the NSA?
Does it do a quick check of correct key again like PGP so that
it would be easier for the NSA to break?
Does it use those nice friendly error recovery 3-letter chaining
so that it helps the NSA break it?
IF the anwser to all 3 is yes. Is there ever going to be an attempt
to make it more secure or is it just a toy clone of the old approved
for export PGP.
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: simple key dependent encryption
Date: Wed, 08 Sep 1999 04:51:36 GMT
In article <[EMAIL PROTECTED]>, steve cator <[EMAIL PROTECTED]> wrote:
>i don't know much, if anything, about encryption. nonetheless, i have
>written a simple encryption program to encrypt any type of file, and i
>have a couple of questions about the nature of the encryption scheme.
>
>here's basically how it works:
>
>1. the user enters a key.
>2. the program reads in a file, byte by byte.
>3. the value of each byte is added to the next ascii value of the key,
>and written back to the file.
>
>for decryption, the ascii value of the each key character is SUBTRACTED
>from the byte. the program does not care what the key is, and will
>subract values from the bytes dependent of the current key.
>
>my questions:
>
>a) what is this type of encryption called?
>b) am i wrong in thinking this type of key dependent encryption would be
>tough to crack?
>
>
IF the key is as long as the file being encrypted it is a type of
OTP (one time pad)
It is what 99% of people do when they first start to code but
most use a XOR instead of addition.
It is very secure if used properly. That is if you use the key
only once to encrypt and once to decrypt.
It you use same key on more than one file it is considered
very very weak.
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: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Random and pseudo-random numbers
Date: 8 Sep 1999 03:53:51 GMT
Eric Lee Green <[EMAIL PROTECTED]> wrote:
> Yarrow burrows into the innards of Windows to grab entropy. /dev/random
> on Linux and FreeBSD uses various pieces of entropy within the OS. One
> nice source of entropy is to use the low-order byte of a timer at the
> exact time that you get keystrokes (the old PGP method). None of these
> are working for me if I'm wanting my code to run on HPUX, Solaris, or
> SCO Unix in unattended mode.
Have you considered egd, the "entropy gathering daemon" distributed with
GnuPG ? It consists of a bunch of perl scripts which
* take timings of 'random' sources of your choice
(and it's easy to add or subtract new sources)
* collect a pool of random bits
* hash the pool with SHA-1
and then outputs the result when called. It's supposed to be a userland
implementation of /dev/random . Seems to work OK on the Digit..er, Compaq
UNIX box my shell account is on, although i'll admit to not having run
tests on it.
http://www.lothar.com/tech/crypto/
-David
------------------------------
From: "Kwong Chan" <[EMAIL PROTECTED]>
Subject: Re: Plaintext block size
Date: Wed, 8 Sep 1999 12:12:32 +0800
David Wagner <[EMAIL PROTECTED]> wrote in message
news:7qknqo$jp7$[EMAIL PROTECTED]...
> In article <7qjeto$[EMAIL PROTECTED]>,
> Kwong Chan <[EMAIL PROTECTED]> wrote:
> > Block ciphers such as DES, AES, etc., can be viewed as a monoalphabetic
> > substitution cipher which require a plaintext block size at least
128-bit
> > long.
>
> Only when used in ECB mode.
>
> > For a polyalphabetic substitution block cipher, what is the minimum
> > requirement for the plaintext block size?
> >
> > To my understanding, a stream cipher can also be viewed as a
polyalphabetic
> > block cipher with plaintext block size=1 and a key cycle length equal to
the
> > period of the employed generator.
>
> Unless I'm misunderstanding, your second statement below suggests that
> the minimum is one bit... Am I misunderstanding the question?
My understanding is that for a stream cipher, both the input plaintext
alphabets,
the ciphertext alphabets and the key alphabets consists of {0,1}. And the
substitution mapping is defined by
S=p xor z
Hence, each key stream bit z defines a substitution and for the same
plaintext, say p=0,
if z=0, then p is mapped to 0, if z=1 then p is mapped to 1.
If I am misunderstanding, please point me to the right direction.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: THE NSAKEY
Date: Wed, 08 Sep 1999 07:53:30 +0200
Guenther Brunthaler wrote:
>
> * It's part of the NSA's job to act in such a way
>
Right.
Remember that the NSA invested in Netscape a couple of years
ago for reasons unknown.
Ask yourself why the hell the NSA would give cash to Netscape?
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: GnuPG 1.0 released
Date: 8 Sep 99 05:14:35 GMT
SCOTT19U.ZIP_GUY ([EMAIL PROTECTED]) wrote:
: IF the anwser to all 3 is yes. Is there ever going to be an attempt
: to make it more secure or is it just a toy clone of the old approved
: for export PGP.
The answer to all 3 is yes, but PGP is not approved for export.
John Savard
------------------------------
From: Teonanacatl <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: _NSAKey
Date: Mon, 06 Sep 1999 12:38:42 -0600
Markku,
You are correct. The end of the conventional cold war was merely a
change in the battlefront, which shifted to the economic, info front.
Long before the "cold war end" it was apparent that control of
information obviated the need for vast quantities of hard armaments.
The CIA had long been involved in economic activities, and about 15
years ago, it shifted it's main emphasis into the economic and
technological research realm.
There has been a vast and long documented "revolving door" regarding the
employment and activites of intelligence operatives in the US and UK.
Certainly the Wassenaar control agreement is strategic and paramount in
the ability to control and access info in the world information
infrastructure, which was precisely why it was convened.
It would be extremely naive to believe that a company which controls 90%
of the desktop software, and a significant portion of datacenters
worldwide, would not have come under the scrutiny and control of the
us/uk comint (echelon) system.
Many of the so-called privacy and encryption programs and software, if
they cannot be analysed line by line in their code, should certainly not
be "trusted" to not contain the controlled "back door".
It would, of course be naive to believe that strategic intersections of
the information infrastructure were NOT subject to interception, like
the main interconnection hubs, search engines, etc.
Most Americans and undoubedly, most of the worlds citizens are unaware
of these FACTS. We must all be more diligent in the dissemination of
this info, if we are to stand any real chance of achieving and
maintaining any real privacy in this information age.
--
Valentin Guillen
remove capitalized letters to email me
-----------
"_NSAKEY signifies that it satisfies security standards." (Microsoft)
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Random and pseudo-random numbers
Date: 8 Sep 99 05:12:18 GMT
Eric Lee Green ([EMAIL PROTECTED]) wrote:
: which assuming that my initial seed values are truly random
: sounds like it would produce unpredictable output (which is all I care
: about, unpredictability, I have to generate numerous 1024-bit keys and
: don't want them to be predictable).
If you can only get 24 random bits from the time of day and the innards of
Windows, then you will only get 2^24 possible keys, even if your
pseudorandom number generator has many more internal states. But if the
time it is allowed to run before you ask for a key is a variable, that is
one way a few more random bits are entered.
So requiring the user to doodle on the keyboard, or play with the mouse,
probably is unavoidable, I think.
Here's a weird suggestion. Encrypt messages through two layers of
encryption, each one secure enough for the application. Use the
halfway-enciphered messages as input to the PRNG! Thus, message text is
safely (?) used as a source of randomness!
John Savard
------------------------------
From: John Pliam <[EMAIL PROTECTED]>
Crossposted-To: comp.infosystems.www.misc,comp.security.misc
Subject: Re: Ways to steal cookies in HTTP and HTTPS
Date: Wed, 08 Sep 1999 05:18:17 +0000
Nick Kew wrote:
> Browser sends server's cookie (if any) to server. Not to
> intruder.
>
> Now, what has intruder gained?
Not much for http cookies. But: a reduction of twenty-six orders
of magnitude in the work factor for https cookies. I have never
said that the victim's browser will send its cookie directly to
the intruder. That would be silly.
What the intruder controls is *when* the cookie is sent, and
thereby, potentially, the number of *bits* of encryption used
to protect it.
> A proxy server sees all the information in transit. If the
> entire transaction is going via your "intruder", then a cookie
> is the least of your problems.
A proxy server doesn't see the plaintext of encrypted traffic.
If a protocol claims to provide `strong authentication' what
this generally means is that there is an exchange of messages
end-to-end such that the identity of at least one party is proved
to the other party. Only a denial of service attack is feasible
no matter what's `out there'.
No self-respecting bank or e-commerce company should say to
you, "Hey, your buying power and credit card are safe with us
... unless, of course, someone happens to get access to your
ISP's gateway."
Going back to the original post, my point is simply this:
Were it not for the 3rd party cookie mechanism, SSL along
with https cookies acting as single single-on authentication
tokens *could* have provided strong authentication in the
sense described above. But unless the server uses SSLv3
exclusively (or impractically short cookie lifetimes, ~5 sec),
the authentication cannot strictly be considered strong.
3rd party cookies can thus be used to violate your surfing privacy
and subvert your shopping authenticity. Ergo, they are evil. ;-)
John
------------------------------
** 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
******************************
