Cryptography-Digest Digest #196, Volume #10 Tue, 7 Sep 99 23:13:03 EDT
Contents:
Does SSL use RSA keys?...follow up question ([EMAIL PROTECTED])
Re: Schneier/Publsied Algorithms ("John E. Kuslich")
Re: Beale (was: Mystery inc.) (sha99y00000)
Re: Schneier/Publsied Algorithms (Bruce Schneier)
GnuPG 1.0 released (Matthew Skala)
simple key dependent encryption (steve cator)
Re: simple key dependent encryption (JPeschel)
Re: Beale (was: Mystery inc.) (Jim Gillogly)
Re: NSAKEY as an upgrade key (Was: NSA and MS windows)
Win Crypto libs, was: Help with CryptoAPI: can not do the simplest (Taavo Raykoff)
----------------------------------------------------------------------------
Date: Tue, 07 Sep 1999 16:40:12 -0500
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Does SSL use RSA keys?...follow up question
To all,
First, to all that contributed responses so far, thank you very much for
being patient and providing a wealth of information to my sort of
clueless mind.
I've read everyone's responses in detail. Spent hours mulling over the
original article in the NY Times
(http://www.nytimes.com/library/tech/99/09/biztech/articles/06code.html)
that started all this hoopla.
What's scary, is that I think I'm getting a clue here. But I’d like to
submit my thoughts and a few questions to you’all for review/comment
before I even think I might have a clue. Here we go:
Background: Web server using SSL 128-bit Strong U.S. encryption
w/compatible browser.
My understanding of the process:
1. Browser opened. Person types in “https” something or other.com.
2. Server responds with handshake saying sure go ahead.
3. Browser then generates a ephemeral (temporary) symmetrical key from a
48 Byte master key and a random value. (BTW, anyone know what the random
values are?)
4. This key that’s generated is then encrypted with the 1024 bit
(public) RSA key. (Strong U.S. only, 512 for export version)
5. This “session key” hidden in the RSA 1024 bit key is then transmitted
and received by the web server.
6. Web Server then “decrypts” the 1024 RSA key and derives the “session
key”.
7. Time back up for a moment. The “key” in the web server is generated
each re-boot. The last time the web server was re-booted, it generates
a key. This key is transmitted to the browser encrypted with the RSA
1024 bit public key.
8. So encryption from browser to server is done using the browsers
“session key”. And the traffic from the Web Server to the browser is
done using the Web Server’s “session key” that was generated at the last
re-boot.
9. Person is done with, browser is closed.
10. Web Server is not re-booted.
11. Next day person starts another https session.
12. Steps 3 – 9 happen over again, EXCEPT a DIFFERENT symmetrical key is
generated by the browser from the last time it was opened. (This is
good, yes?)
13. Person is done with, browser is closed.
14. Web Server IS re-booted that night.
15. Next day person starts another https session.
16. Steps 3 – 9 happen over again, EXCEPT a DIFFERENT symmetrical key is
generated by the browser from the last time it was opened and a
DIFFERENT session key is now also in use by the Web Server because of
the re-boot. (This is good, yes?)
QUESTION: Is what I’ve said above correct? (in CEO’s terminology)
Please keep in mind that I’m from the “old” crypto days (70’s & 80’s)
before PC’s. I’m trying, be gentle.
Thanks a bunch,
Michael Sorbera
Webmaster
Randolph-Brooks Federal Credit Union
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: Schneier/Publsied Algorithms
Date: Tue, 07 Sep 1999 13:58:31 -0700
But, the point is, the PC cannot be made secure. At least not in its present state (I
refer to the standard desktop pc using a Pentium processor - the so
called IBM clone...).
Once the software is in memory, it doesn't matter how good the source is. A trojan on
the system can alter the binary image of your carefully written and
compiled source (oh gees, don't forget, the compiler could be bogus also). The binary
image of your software can be changed, used by the unsuspecting, and
changed back.
Our new QuickBooks and Quicken crackers work this way (in this case with the blessing
of the user) to cause QuickBooks or Quicken to simply ignore whatever
password protection is on the file. Now, these two programs are especially simple
illustrations of the principle because the files in question are never
actually encrypted. Nevertheless, the technique has wide application in a system
that allows access to the memory space of any process (Windows95 and
Windows98).
The source code is entirely irrelevant! (even if it were feasible to re-compile
source everytime the code is used :--). What are you going to do, re-read and
verify your compiler source each time you compile).
I agree, you start to get a little paranoid when considering some of the
possibilities, but remember the words of the great blues artist BB King "No one ever
loved me 'cept my Mama...and she might have been just jivin' me too..."
JK http://www.crak.com
Geoff Thorpe wrote:
> Hi there,
>
> > properly on your machine. Once in memory, the code is easily altered by a trojan
>inserted by Back Orifice or by other surreptitious means. The PC is not
> > secure, ergo code running on a PC is not secure. The only secure encryption is
>harware encryption.
>
> Wrong. The above is deduced from the PC being insecure. Make the PC
> secure and you don't have a problem, trust potentially insecure hardware
> and you do have a problem. Hardware encryption is just software running
> a server in a different process on a different OS on a different machine
> on a different network interface. If you're running a decent operating
> system, then doing the same in a different process under different user
> priviledges is just a more convenient method for doing the same job. Now
> for acceleration ... then dedicated hardware can start to come in handy
> - but it's simply not true that hardware crypto is the only solution to
> weakling operating systems.
>
> BTW: Do any hardware crypto vendors actually publish the source code to
> their micro-controller OSs? My PC operating system comes with source.
>
> Cheers,
> ME
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
Date: Wed, 08 Sep 1999 00:45:41 +0100
From: sha99y00000 <[EMAIL PROTECTED]>
Subject: Re: Beale (was: Mystery inc.)
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<blockquote TYPE=CITE>Oh, if that's all you meant, that's pretty obvious.
<br>Since T.J.'s own writings were nearly all under 2906 words,
<br>I used that to narrow the search, which is how I came to
<br>his "Bill to Abolish Slavery in Virginia", which has other
<br>reasons that suggest it also.</blockquote>
I wasn't pertaining to the size of the numbers but to the pattern and the
possible "hint key" code. I didn't want to spell it out yet, but see if
anyone else noticed.
<p>#1 => 2906
<br>#2 => 994 Declaration of Independence
<br>#3 => 975
<blockquote TYPE=CITE>There was only *one* stretch, and it wasn't a contiguous
piece of
<br>the normal alphabet, although it resembled one.</blockquote>
That makes a big difference. I have to agree with you on this part of the
problem. Thanks. I'll have to look into this a bit more. My opinion is
anything continual 6 or more in length, more than once occurring, within
a short piece of text, is a pattern of suspect over random occurrence.
[Does that make sense?]
<p>Sha99y
<br> </html>
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Schneier/Publsied Algorithms
Date: Wed, 08 Sep 1999 00:19:47 GMT
On Sun, 5 Sep 1999 20:52:21 +0200, Anonymous
<[EMAIL PROTECTED]> wrote:
>But I insist on having my quetion ANSWERED...Please Bruce Schneier:
>
>Is this code for 2Fish on your Site...a comercial grade product or is it just
>a piece of semi tested code for 2fish. What is it exactly ?
The code on the website is 1) Twofish reference source code, as
required by NIST for an AES submission, 2) optimized Twofish code for
various CPU and compilers, and 3) other public domain Twofish source
code. It is not a product in any way. There is nothing to sell and
nothing to buy. There is no technical support (although we have been
pretty good at answering implementation questions from rational
people).
All the code that we have written has been tested, and conforms to the
Twofish test vectors. I cannot say the same about third-party Twofish
code, even code that we point to. If you make changes to the source
code to get it to run on your particular CPU, it may change the
algorithm in subtle ways. That's why there are test vectors.
>As I asked in my last posting..if I wanted to develop a commercial apps using 2fish..
If you want to use Twofish in a commercial product, you are free to
do so without restriction. You are free to use the source code on the
website or write your own. In any case, you should ensure that the
code you use (whether it is a modification of the website code or your
own implementation) conforms to the test vectors on the website.
>What do I use? The code on your site...or is there ANOTHER DEAL.....???
There is no deal. You can use the code on the Twofish website, you
can use Brian Gladman's Twofish code, you can use Twofish code that
I've never seen before, or you can write your own.
>Please Answer my Question...And as a pro programmer..I would not consider this stuff
>on your website to be a robust commercial grade cipher...
That's fine. You can write your own Twofish implementation, or you
can use another cipher.
Bruce
**********************************************************************
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: [EMAIL PROTECTED] (Matthew Skala)
Subject: GnuPG 1.0 released
Date: 7 Sep 1999 17:28:17 -0700
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
--
Werner Koch at guug.de www.gnupg.org keyid 621CC013
------------------------------
From: steve cator <[EMAIL PROTECTED]>
Subject: simple key dependent encryption
Date: Tue, 07 Sep 1999 20:41:49 -0400
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?
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: simple key dependent encryption
Date: 08 Sep 1999 01:10:31 GMT
steve cator <[EMAIL PROTECTED]> writes:
>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?
a) A polyalphabetic cipher with a mixed alphabet and a repeating key.
b) Yes, you are wrong.
John, Doug, and Jim are likely champing at the bit to tell you how to
crack it. :-)
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Beale (was: Mystery inc.)
Date: Wed, 08 Sep 1999 01:33:41 +0000
sha99y00000 wrote:
> > There was only *one* stretch, and it wasn't a contiguous piece of
> > the normal alphabet, although it resembled one.
>
> That makes a big difference. I have to agree with you on this part of the problem.
>Thanks. I'll
> have to look into this a bit more. My opinion is anything continual 6 or more in
>length, more than
> once occurring, within a short piece of text, is a pattern of suspect over random
>occurrence.
In fact, there are four alphabetic sequences, as I detailed in another
message in this thread. Their lengths, using John King's DOI which
was adjusted to match Beale #2 without trying to optimize Beale #1,
are 10, 11, 5, and 17 letters. The last one is 20 letters long if you
grant an off-by-one.
Even without King's adjustments the longest one is 14 letters:
DEFGHIIJKLMMNO. In my experience you never find something this
long and coherent in a text the length of B1. Note that some of
these are rare initial letters, and thus would be even less likely
to show up there by chance.
You don't need to trust me on this -- it's right there to decrypt
with the DOI. Check it out.
Any credible explanation of the Beale ciphers must have a credible
explanation of these strings. Carl Hammer agreed that they were
causal, but suggested that they might be a clue to the decryptor
that he was on the right track, and that there was still a treasure
at the end of the rainbow. This seems pretty lame, considering
the alleged provenance of the ciphers: the alleged Beale was not
setting a puzzle for would-be treasure hunters, but rather allegedly
setting out a precise description of the location.
It's usually not possible to prove that a cipher is a hoax: either
you can decrypt it or you can't. That's why this was one of my
favorite papers.
--
Jim Gillogly
Sterday, 17 Halimath S.R. 1999, 01:16
12.19.6.9.5, 11 Chicchan 13 Mol, Fifth Lord of Night
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: NSAKEY as an upgrade key (Was: NSA and MS windows)
Date: 8 Sep 99 01:51:36 GMT
Thomas J. Boschloo ([EMAIL PROTECTED]) wrote:
: Microsoft's explanation "Why is a backup key needed?" is bogus (they
: claim it would be needed for when the building in which it is kept is
: destroyed by a natural disaster, LOL).
Well, while keeping two copies of the key would solve that, two copies of
the same secret key won't help if one key is _compromised_. For that, a
second key, to which the corresponding secret key is stored _elsewhere_,
would serve a useful backup function.
John Savard
------------------------------
From: Taavo Raykoff <[EMAIL PROTECTED]>
Crossposted-To:
microsoft.public.win32.programmer.networks,microsoft.public.win32.programmer,comp.os.ms-windows.programmer.win32
Subject: Win Crypto libs, was: Help with CryptoAPI: can not do the simplest
Date: Tue, 07 Sep 1999 21:40:18 -0400
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
------------------------------
** 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
******************************
