Cryptography-Digest Digest #985, Volume #9 Wed, 4 Aug 99 15:13:03 EDT
Contents:
Re: cryptography tutorials (Helger Lipmaa)
Re: How to keep crypto DLLs Secure? (John McDonald, Jr.)
Re: Random numbers in practice ("Microsoft Mail Server")
[Q]:Got a RSA private key on CRT format, how can I find e and d?
([EMAIL PROTECTED])
Random numbers in practice (vincent)
Standaarden in Belgi� ("Bart Reyserhove")
Where does the SSL ID get stored? ([EMAIL PROTECTED])
Software License Generation - Assistance Requested ("Kirk E. Lieb")
Ways to steal cookies in HTTP and HTTPS ([EMAIL PROTECTED])
Re: Microsoft Word 97 ([EMAIL PROTECTED])
Re: [Q]:Got a RSA private key on CRT format, how can I find e and d? (DJohn37050)
Re: Is breaking RSA NP-Complete ? (Bob Silverman)
Re: Is this a new authent/encrypt protocol? (Medical Electronics Lab)
ORB - Open Random Bit Generator (Alwyn Allan)
----------------------------------------------------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: cryptography tutorials
Date: Wed, 04 Aug 1999 14:51:19 +0000
David A Molnar wrote:
> Try checking out the notes by Shafi Goldwasser and Mihir Bellare -- go to
> http://theory.lcs.mit.edu/ and follow the links to Crypto & Info Security
> group, then click on Goldwasser's name to get to her web page.
The GB course notes is a very good one (1) for those who already know what is
cryptography about and (2) who like more theoretical approach. (for example,
it only mentions areas differential and linear cryptanalysis, but gives an
overview of the recent work by Bellare et al. about security of different
block cipher modes). GB-notes do not contain many proofs, one has to check
for the original papers for them. Overall, they are not for beginners (trust
me, I handled them as an experiment to some of my students).
If you need lecture notes, why not start with
http://www.uni-paderborn.de/fachbereich/AG/agmadh/WWW/english/scripts.html? It
has links to the next notes:
Oded Goldreich: Foundations of Cryptography
William Korner: Coding and Cryptography
Miroslaw Kutylowski & Willy Strothmann: Wyklady z kryptografii (well, in
Polish)
Also, J.S. Milne has a couple of relevant math notes on his homepage
http://www.math.lsa.umich.edu/~jmilne/ (including courses on elliptic
curves...)
And many of the chapters of the "Handbook of Applied Cryptography" (by
Menezes, van Oorschot and Vanstone) are online for
free. Cf: http://www.cacr.math.uwaterloo.ca/hac/
Helger
http://home.cyber.ee/helger
------------------------------
From: [EMAIL PROTECTED] (John McDonald, Jr.)
Subject: Re: How to keep crypto DLLs Secure?
Date: Wed, 04 Aug 1999 14:27:20 GMT
On Wed, 04 Aug 1999 02:18:45 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>The Internet protocol suite in common use is horribly insecure;
>there is almost no authentication, and what little there is,
>is not performed often enough to prevent connections from being
>hijacked. There are numerous books explaining the many security
>deficiencies, e.g. Stallings' "Network and Internetwork Security";
>the problems are summarized in ARL-MR-412, which I co-authored.
Hey Douglas--
Your statements are true, but I think I hacked you off with my first
statement and you skipped the rest of my post. <G> (I do have that
effect on people sometimes...)
This is what I mean. TCP/IP was not designed to be secure in any
sense of the word. It was designed to get whole packages torn up,
sent to the recipient and put back together regardless of the order
the package actually was recieved. It was also designed to re-request
any packets that could have been broken in transit, or are missing.
And for this, TCP/IP works amazingly well.
The result is of course that at an application level, I do not have to
pray that the data was sent correctly. I can write my code with the
knowledge that any data that is sent to me I will recieve correctly.
This does cause a problem with people using modems over the internet,
where packages actually can fail in transit and not be resent, ie when
the modem connection breaks.
What I said still stands. For the most part, I am happy to use
TCP/IP. If I need extra security, the solution is simple. I use VPN,
encrypt on one end and decrypt on the other. Then, even if someone
gets a hold of packets in the middle, I could care less. It will do
them no good.
One other thing... The extra time that encrypting and decrypting take
is not worth it to those of us that use dial-up connections. For
instance, if I am playing Quake2 online, the amount of time it takes
me to encrypt and decrypt is the difference between me railing
someone, and me eating their rail.
[-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-]
John K. McDonald, Jr. Alcatel, USA
[EMAIL PROTECTED]
please remove -delete- for responses.
--
"I speak for me and not this company"
TO SPAMMERS:
Please view the definitions for
"telephone facsimile machine,"
"unsolicted advertisement," and the
prohibition and penalty for sending
unsolicited faxes before sending Un-
solicited Commercial E-mail to the
above address. Violators WILL BE
PROSECUTED. These can be found
in:
The Telephone Consumer Protection Act
of 1991, Title 47, Chapter 5,
Subchapter II, Section 227.
[=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=]
------------------------------
From: "Microsoft Mail Server" <[EMAIL PROTECTED]>
Subject: Re: Random numbers in practice
Date: Wed, 4 Aug 1999 11:36:14 -0400
here we go again!
--
best regards,
hapticzemail at email.msn.com
remove first email, sorry i had to do this!!
------------------------------
From: [EMAIL PROTECTED]
Subject: [Q]:Got a RSA private key on CRT format, how can I find e and d?
Date: Wed, 04 Aug 1999 15:32:22 GMT
Hi, assuming that I have access to a RSA private key on the Chinese
Remainder Theorem Format, can I then somehow calculate d and e?
If so, how do I do it?
kind regards
Thora Sennils
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: vincent <[EMAIL PROTECTED]>
Subject: Random numbers in practice
Date: Wed, 04 Aug 1999 16:07:14 +0100
Hi guys,
Sorry for those of you who have already seen that message, I've
previously posted when I had my clock set at sunday, so it didn't appear
where I wanted it to appear.
Following is the same message.
Thanks, you who have knowledges about RNG for looking at it.
I am currently developing a RSA keys generation prog.
I have everything BUT a good random generator (assuming the one in C is
not good, which is a pretty straightforward assumption).
My questions are :
Can I use a Pseudo-random generator (PRG) or a Real random generator
(RRNG, like a device).
If I can use a PRNG, then which one is better to use, where can I find
the algorithm or the C++ code to do it, how do I initialise the seed and
when do I initialise it.
If I have to use a RRNG, where can I find one (buy one or how do I write
one).
I've heard about one which could use the variation of a disk drive
motor's speed caused by Air turbulence.
I really need a good Random number generator (cryptographically secure
as well as quick) to generate a lot of keys.
Thanks for any answers (practical if possible).
--
============================
Vini boy
[EMAIL PROTECTED]
------------------------------
From: "Bart Reyserhove" <[EMAIL PROTECTED]>
Subject: Standaarden in Belgi�
Date: Wed, 4 Aug 1999 18:40:02 +0200
Wat zegt de wetgeving over encryptie in Belgi�? Zijn er beperkingen zoals in
Amerika of niet?
Does anybody know if there are any restrictions in Belgium, which have to do
with encryption?
Bart
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Where does the SSL ID get stored?
Date: Wed, 04 Aug 1999 16:29:49 GMT
I am using CISCO Local Director to perform load balancing for two
Netscape web servers. The web site is set up for encryption. The Local
Director redirects users via their SSL ID. My questions is where, and
how does the clients browser store the SSL ID that it is assigned so
that the user will continue to access the same web server.
The problem I am having is when I run a virtual user generator the
virtual users do not seem to be accessing the same server of the coarse
of the navigation through the web site.
-David
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Kirk E. Lieb" <[EMAIL PROTECTED]>
Subject: Software License Generation - Assistance Requested
Date: Wed, 04 Aug 1999 10:25:52 -0700
Hello,
I am developing a WinNT sw product which requires a one-time licensing
scheme, and I am looking for assistance in understanding existing
products or libraries that would be useful.
Thanks in advance,
Kirk
==============================================================
License Key Generation:
- UNIX utility (accessed via a web server)
- inputs: hostname, customer id, order id, etc.
- output: <= 16 character license key
License Key Consumption:
- WinNT functionality
- input: license key
- outputs: hostname, customer id, order id, etc.
Additional Requirements:
- Does not require unbreakable encryption
- Symmetric key preferred (I think)
- If library is available, C++ is preferred
=============================================================
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.infosystems.www.misc,comp.security.misc
Subject: Ways to steal cookies in HTTP and HTTPS
Date: Wed, 04 Aug 1999 01:27:32 GMT
"Cookies are inherently evil.
Just say no to cookies."
- Randal Schwartz
The mechanism for 3rd party cookies has been criticized because
of its implications for user privacy. With the cooperation of
many websites, 3rd party cookies are used to monitor the surfing
habits of users. However repugnant this may seem, it stems
from the legitimate function of HTTP, namely the willingness
of your browser to accept IMG tags as "instructions" of where
to connect. But consider the security implications of a malicious
abuse of this mechanism.
While I am unwilling to go as far as Randal about cookies in general,
I am beginning to conclude that "3rd party" cookies really are evil.
Unfortunately, you cannot just say 'no' to 3rd party cookies. In
both Netscape Communicator and MS Internet Explorer, there is no way
to turn off all 3rd party cookie activity (unless you disable cookies
entirely). Communicator will let you refuse to *accept* these
cookies but will not control their divulgence.
IMHO, the unauthorized divulgence of 3rd party cookies makes up the
other half of their "evil" equation. This is particularly true when
a cookie is used as a kind of weak authentication token. (At
least one E-commerce site will let you charge to a user's credit
card by merely presenting the correct persistent cookie. I won't
give their name publicly because, hey, it's a jungle out there ;-)
The active attacks presented below show that an arbitrary HTTP cookie
of the attacker's choosing can literally be *demanded* from a browser
any time its user surfs. Under certain circumstances, HTTPS cookies
can be stolen. These secure cookies are at best, only as secure as
the weakest mode of SSL *ever* used by the browser. This may be very
different from the mode of SSL enabled when the user *intends* to
send a secure cookie.
Stealing HTTP Cookies
=====================
A single web page may make connections to several sites in order to
retrieve all of its graphical hypertext media. Thus, typing a single
URL
http://www.acme.com/
may spawn many connections to graphics.acme.com, each resulting from
IMG tags of the form
<IMG src="http://graphics.acme.com/foo.jpg">.
The graphics.acme.com site could make use of cookies in order to
provide dynamic images tailored to the user's preferences. This
example has every appearance of being legitimate, but the implicit
trust placed by the browser in the HTTP response could be
unwarranted. A malicious adversary could actively modify the HTML to
include a false IMG tag such as
<IMG src="http://e-commerce.widgetstore.com/hrule.jpg">
forcing the unsuspecting browser to send its Widget Store cookie out
into the Internet. The attacker -- acting as an "intruder in the
middle" -- steals the the cookie of choice from user's browser. With
TARGET_URL = http://e-commerce.widgetstore.com/hrule.jpg,
and
server = any legitimate server (e.g. home.netscape.com),
the main stages of this attack are depicted below:
GET ...
browser --------------------------------------> intruder
GET ...
intruder --------------------------------------> server
<html>...</html>
server --------------------------------------> intruder
<html>...<img src=TARGET_URL></html>
intruder --------------------------------------> browser
Cookie: foo=bar; ...
browser --------------------------------------> intruder
(intended for TARGET_URL)
forged TARGET_URL resource
intruder --------------------------------------> browser
Note that it is not necessary for the intruder to stand
in between the browser and the server corresponding
to TARGET_URL. That is just the easiest way for the intruder
to go undetected.
Stealing HTTPS Cookies
======================
By definition, HTTPS cookies are never sent without SSL protection.
However, variants of our attack to steal HTTP cookies could be
designed to exploit SSL weaknesses.
Suppose your Widget Store E-Commerce cookie is secure and its server
supports 128-bit encryption. On the other hand, suppose that Al's
Shitty Mortgage Company supports only 40-bit encryption and only SSL
version 2. You don't like 40-bit SSLv2, but you are willing to drop
your guard temporarily in order to connect to Shitty Mortgage and get
Al's latest interest rate.
Throughout this section, the target cookie is the Widget Store
E-Commerce cookie with SSL URL
TARGET_URL = https://e-commerce.widgetstore.com/hrule.jpg
Also take,
server = any http server (e.g. Netscape home)
target = e-commerce.widgetstore.com
We assume that the small horizontal rule image (common to many servers)
is available from Widget Store and can be added to any HTML without
being noticed. The following attack combines our HTTP cookie
stealing with the well-known ciphersuite rollback attack (see [WS96])
in which an SSLv2 session is forced into 40-bit mode. The attacker
actively acquires the desired cookie encrypted with an unknown 40-bit
key. After a couple hours of exhaustive search, the plaintext cookie
is recovered.
intruder: Wait for browser to drop to 40-bit SSLv2 and
connect to server (listen to Al's traffic).
GET ...
browser --------------------------------------> intruder
GET ...
intruder --------------------------------------> server
<html>...</html>
server --------------------------------------> intruder
<html>...<img src=TARGET_URL></html>
intruder --------------------------------------> browser
Ciphersuite rollback attack: browser
& target establish 40-bit session key, k.
browser <-------------> intruder <------------> target
{Cookie: foo=bar; ...}_k
browser --------------------------------------> intruder
{Cookie: foo=bar; ...}_k
intruder --------------------------------------> target
{hrule.jpg}_k
target --------------------------------------> intruder
{hrule.jpg}_k
intruder --------------------------------------> browser
Note that because the intruder cannot easily determine the 40-bit
session key in real time, she must remain in the loop and wait to
conduct a brute-force search off-line.
References
==========
[CKY1] Persistent State HTTP Cookies, Netscape Communications,
URL: http://www.netscape.com/newsref/std/cookie_spec.html
[CKY2] D. Kristol, L. Montulli, HTTP State Management Mechanism,
RFC 2109, 1997.
[W3C] World Wide Web Consortium Security FAQ,
URL: http://www.w3.org/Security/Faq/.
[WS96] D. Wagner, B. Schneier, "Analysis of the SSL 3.0 Protocol",
1996, URL: http://www.counterpane.com/ssl.html.
====================================================================
John Pliam
[EMAIL PROTECTED]
http://www.ima.umn.edu/~pliam
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Microsoft Word 97
Date: Wed, 04 Aug 1999 17:37:32 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
Try MSOfPass97 at:
http://www.lostpassword.com
Help forgetfull users to "crack" password to Word, Excel, etc.
> I lost the password for a Microsoft Word 97 document.
> Help me !!!
> Thank's
> NPW
>
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: [Q]:Got a RSA private key on CRT format, how can I find e and d?
Date: 04 Aug 1999 18:29:41 GMT
Check out IEEE P1363 for details on this format.
Don Johnson
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Is breaking RSA NP-Complete ?
Date: Wed, 04 Aug 1999 18:18:40 GMT
In article <7o9tbe$mvj$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I wrote:
> > Anton Stiglic wrote:
> >
> > > def. (NP-Hard)
> > > A problem (any problem, no just a decisional problem
> > > (important distiction)) is NP-hard if the existence of a
> > > polynomial -time algorithm for its solution implies
> > > that P = NP.
>
> [...]
>
> > Note that the two definitions disagree about more than
> > whether NP-Hard is a set of languages. If P!=NP, then
> > there are subsets of NP that are neither in P nor
> > NP-Complete. These languages would be NP-Hard under
> > the definition in the Handbook, but not under the
> > definition in /Introduction to Algorithms/.
>
> I find the definition from the /Handbook of Applied
> Cryptography/ is corrected in the errata, and is only
> listed as an error in the first and second printing.
> HAC now defines NP-Hard thus:
>
> "A problem is NP-hard if there exists some
> NP-complete problem that polytime reduces to it"
Allow me to quote from what I consider to be a more definitive reference
in this regard: (Garey & Johnson). [Not that the HAC isn't a good
reference for crypto, but that G&J is better for *this* subject]
"however, although the definition of NP-Complete seems to be fairly
stable, the definition of NP-Hard is somewhat less so".
I have seen different definitions of NP-Hard. The definition I prefer
is:
A problem is NP-Hard if it is polynomial time reducible (in the sense
of Karp reducibility) to the hardest problem in NP.
Although G&J is slightly dated, and a more stable definition may have
since emerged, I still see different definitions, which implies that
a "definitive" definition may not yet have emerged.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Is this a new authent/encrypt protocol?
Date: Wed, 04 Aug 1999 12:44:34 -0500
Greg wrote:
>
> Can anyone tell me if this resembles an existing protocol?
> If not, I submit it to the public domain.
>
> Given Elliptic Curve encryption (points are uppercase),
> Given message m, and its hash h,
> Given Alice's private key a and public key A,
> Given Bob's private key b and public key B,
> Given a base point P,
>
> Assume A and B are well known, cannot be spoofed, and are verifiable
> via alternate means (e.g.- phone call, personal visit).
>
> Alice sends message m to Bob by deriving a hash (h) for the message
> then encrypting it with abhP producing c (cipher text). The secret S
> is defined as:
>
> S = abhP = ahB = bhA = bJ (J = hA)
>
> Alice sends c and J. Bob derives S from bJ, then m from S and c,
> then h from m. With h, Bob can verify J. That is, haB can only
> come from Alice.
>
> If m is altered, then so also is h and a. Bob would detect this
> with the decryption process failing.
It took me a bit to figure out what you mean here.
c = E(S,m) is some kind of symmetric cipher, yes?
Then what you've got is DH plus the hash of the message to create
the key. This is probably a good thing for similar messages
assuming the hash is a good randomizer (which most good hashes
are).
If the keys haven't been verified then it's subject to man-in-
the-middle attack, just like DH. Adding the hash doesn't really
improve anything there.
Depending on the symmetric cipher, making the key message dependent
could lead to a weak key (very very unlikely, but possible).
I don't see how adding the hash improves the authentication over
DH given that the keys are preverified anyway, but it does mean
you use a different key for each message and that's a good thing.
Patience, persistence, truth,
Dr. mike
filler
------------------------------
Date: Wed, 04 Aug 1999 14:49:20 -0400
From: Alwyn Allan <[EMAIL PROTECTED]>
Subject: ORB - Open Random Bit Generator
Announcing ORB - Open Random Bit Generator
ORB is a single-chip random bit generator featuring:
* Low cost (~$2 each in production quantities)
* Low power consumption (2 mA, 1 mA standby)
* Wide operating voltage range (2.5 - 5.5 V)
* Wide temperature range (-40 to 85�C, 125�C avail.)
* Moderate speed (1000+ bits/sec)
* Good statistical properties
* Cryptographic quality randomness
* Open design (not free)
* Simple interface
* Small footprint (5.3 x 8.1 mm, 8-lead SOIC)
ORB is based on a Microchip Technology 8-bit microcontroller, and uses
one external resistor. Entropy is generated by a unique (patent pending)
process in which a capacitor is charged and discharged according to the
contents of a bitstream, and the capacitor's voltage is measured by an
A/D converter. The low-order bits of the A/D results are "stirred" into
an entropy pool, which is then processed through a cryptographic hash
function (MD2). Part of the hash result is the random output and part of
it forms the bitstream to continue the process.
Orb is now shipping in sample quantities. Please see
www.delanet.com/~apa/orb
for more details.
[The hushmail address is for spam control. Use the address on my
website.]
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
======== Over 73,000 Newsgroups = Including Dedicated Binaries Servers =======
------------------------------
** 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
******************************
