Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:15:22
David R. Conrad (drc@adni.net)
Mon, 26 Oct 1998 09:57:10 -0500 (EST)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm working on a java version of a program for a client and have run into
a few difficulties. Some are with java, some with export regs, but the
ones relevant to this list are the crypto protocol for exchanging data
with the server. (But if anyone here can help me with java or export,
which I'll touch on further on, please don't hesitate to contact me.)
(If you just want to read my original haiku in memory of Jon Postel (which
puts to shame the dreck published by CU Digest), seek to the end.)
In brief, a customer contacts us out-of-band (on the phone) and buys an
access code to use our system. They hit our web site and download our
applet. They enter some medical data, and we produce an analysis and some
stats. We also store it in a database. Later, they can return to the
site and view the data again.
As they go through the data entry process I collect bits of entropy from
mouse and keyboard events in a java.security.SecureRandom object. When
the time comes to transfer data to or from the server, this entropy is
employed to generate a session key (see below). One problem is that,
although there's a lot of user interaction involved in entering data,
there's very little on a return visit when they retrieve previously
entered data. I suppose the best I can do here is give them a dialog
and make them move the mouse for a while, eh?
Primarily, what I'm concerned about is the security of the protocol that's
used between the applet and the server. (Secondarily, I'm concerned about
exporting it and/or having an unexportable java applet embedded in a web
page that's accessible outside the U.S. and Canada.)
I'm using a variant of Diffie-Hellman which seems to me to be safe from a
MitM attack. The server's x is fixed and X = g^x mod n is built into the
client at compile time. (Obviously, this makes x a big target and I plan
to replace it from time to time, perhaps with each released version of the
applet.) The modulus I've taken from the Photuris draft (the 1024-bit one
with generator 2), and the server's x is an 800-bit random number. You
can find out how it was generated, if your interested, after the summary.
The client uses its SecureRandom to generate y, and then it computes
Y = g^y mod n. Next problem: how many bits do I need here to be secure?
If y is only 160 bits, will this be weak?
The client can now compute k = X^y mod n. How should I generate my
symmetric session key from this? I'm thinking of simply K = SHA1(k) where
K is the session key, but is that sufficient? (Of course, I may desire
128, 112, or 168 bits of session key, rather than 160, but I can deal with
that.)
Next, the client sends a message to the server, of the form Y|E_K(M) where
E_K(M) indicates encryption of message M with key K, and | is
concatenation. Okay, next question, what should I use as my symmetric
algorithm? I'm currently toying with IDEA, 3DES and Arc4, but suggestions
and comments are more than welcome.
(By the way, the client's message can be either: 1) here's the customer's
data, chosen password and id, and assigned token, please store this data,
or 2) here's the customer's id and password, please retrieve data. So
far it's a very primitive protocol.)
The server computes k = Y^x mod n, computes K from k, and attempts to
decrypt the message, returning an unencrypted error code on failure. On
success the server returns a reply of the form E_K(M) (and M here can be
one of three things: 1) data stored, ACK 2) password correct, here is the
stored customer data 3) invalid password).
In summary (thanks for reading this far):
Protocol: variant of DH, 1024-bit modulus from Photuris draft, g=2
Server: has fixed 800-bit x, X = g^x mod n is precomputed
Client: has X built in at compile-time, harvests entropy for y
computes Y = g^y mod n, K = SHA1(k = X^y mod n)
send message Y|E_K(M1)
Server: receives Y|E_K(M1), computes K = SHA1(k = Y^x mod n)
decrypts E_K(M1), sends reply E_K(M2)
Client: decrypts E_K(M2)
Questions:
anything?
1a) Am I correct that this is proof against the man in the middle?
1b) How often do I need to change x?
1c) The server has to compute Y^x mod n for an 800-bit x; is this
excessive, and will it be a performance problem for the server?
2) Is 160 bits sufficient for y?
3) Is K = SHA1(k) a suitable way to generate the session key?
4) What symmetric cypher would you recommend I use?
If you don't care how the 800-bit x value for the server was generated,
skip the next two paragraphs.
Okay, I generated the server's x as follows: by repeatedly running an
applet I designed which collects entropy in a SecureRandom object from
mouse movements and dumps it to stdout in hex. I took five such 160-bit
samples, hashed them all, then put the hash of all five plus 49 rolls of a
ten-sided die (thanks, AD&D) in each of the five files.
So, at this point, these five files each have 160 bits generated by mixing
(with SHA1) mouse data with data from a spinner, 160 bits of hash based on
the other files, so that they affect one another, and about 160 bits of
physically random data. Then I hashed each file with SHA1 and
concatenated the five hashes to get one 800-bit number, making one slight
change in the process: I finagled the order in which they were
concatenated to get a 1 bit as the high bit. This 800-bit number is the
server's x.
Okay, on to things that are off-topic for the list. The export regs,
never seeming the work of a sane mind, are particularly infelicitous here.
The applet cannot be used to transmit general data, only very specific
medical information entered via multiple choice questions. It cannot send
the information to any place other than our server, where the information
will be stored in the clear, indefinitely (in our current design). Unless
a terrorist, child pornographer, money launderer, or drug dealer wishes to
tell us that, on a scale of 1 to 8, his or her alcohol problems rate a 5,
this applet has no use to any of the four horsemen. Even then, the feds
could always subpoena our database.
Plus, we have a real liability problem, both ethical and legal, if the
medical records of our customers were to leak, or be hacked (and yes, I
know that keeping the records on our server in the clear is a problem in
that regard, and that is an aspect of the system I'm looking to improve).
Any comments, especially on obtaining an export license (I am the greenest
newbie when it comes to that) will be greatly appreciated.
Question 5) We're 'escrowing' the plaintext (basically), which is a cut
above escrowing the keys ... should that get us a break?
Yet further off topic is java. Anyone with experience printing from java,
I'd love to hear from you. I was flabbergasted when I found out that jdk
1.0 had no printing API and so our applet, if it should allow users to
print, must be a 1.1 applet, and very few browsers have 1.1 support
(although netscape was getting there in 4.0x so I have high hopes for
4.5). The java live plug-in, or whatever it's called, seems to be a real
kludge from what I've read so far, and this is all putting an enormous
cramp in our style. Run Everywhere was the reason we went for java, and
now it looks like it's going to amount to Run In A Few Bleeding Edge
Browsers, which is a big letdown.
Finally, something really off-topic. Jon Postel died, and Computer
Underground Digest ran some haiku that ranged from mediocre to bad to
downright insulting. I knew I could do better, and here 'tis:
Myocardial
Infarction leaves net guru
In state FIN_WAIT2
Requiescat In Pace, Jon Postel
David R. Conrad <drc@adni.net>
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBNjSN14POYu8Zk+GuEQLvBwCgvoUPKfyt6ncZXUu6x3qJ2XkYn/EAnjXg
8BJqMZk3ASot0s5FJXzB1agt
=KJZa
-----END PGP SIGNATURE-----
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:15:22