Cryptography-Digest Digest #866, Volume #12 Sat, 7 Oct 00 18:13:00 EDT
Contents:
Re: securely returning password info to a server from a client (Paul Rubin)
RSA Key generation ("Martin Wolters")
More Cryptanalysis of TC8 (Tom St Denis)
Re: TC8 -- Yet Another Block Cipher (David Hopwood)
Re: RSA Key generation ("Martin Wolters")
Microsoft on modular multiplication (JCA)
Re: securely returning password info to a server from a client ("Martin Wolters")
Re: Error-correcting code ? (Marc)
Re: Pencil and paper cipher. (wtshaw)
Re: NSA quote on AES ("Scott Fluhrer")
Serial number scheme using DSA variant ([EMAIL PROTECTED])
Re: securely returning password info to a server from a client ("William A. McKee")
Re: Q: does this sound secure? ("William A. McKee")
Re: My Theory... ("Scott Fluhrer")
Re: How Colossus helped crack Hitler's codes (Andrew McDonald)
----------------------------------------------------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: securely returning password info to a server from a client
Date: 07 Oct 2000 13:12:12 -0700
"William A. McKee" <[EMAIL PROTECTED]> writes:
> I want to have my Java applet ask the user for password information
> that will be stored on a server for future password verification
> (using SRP). What is a secure way of getting the information from
> the client to the server?
Basically, unless you can already authenticate either the client or
the server somehow, you have no way to detect a MITM attack.
Normally the way you do this is have a secure SSL connection,
authenticated by a CA-issued certificate on the server side. But for
some reason you don't seem to want to do that. Another method is
to use a signed applet (Netscape only) or .cab file (MSIE), and
embed a public key in it that you authenticate the connection against.
Without signing the applet or the connection somehow, you don't have
any way to know that the applet itself hasn't been tampered with by a
MITM. If the attacker can mess with the applet, al the rest of your
protocols are useless.
It would help if you said something about what your application is.
That would make it easier to give concrete suggestions that fit your
constraints.
------------------------------
From: "Martin Wolters" <[EMAIL PROTECTED]>
Subject: RSA Key generation
Date: Sat, 7 Oct 2000 22:15:14 +0200
Hi,
In my Implementation of RSA, I use
the following algorithm to generate
d from e and phi:
1. k=0
2. increase k
3. d = (k*phi+1)/e
4. repeat steps 1+3 until d is an Integer.
Is there any faster way, to generate d?
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: More Cryptanalysis of TC8
Date: Sat, 07 Oct 2000 20:07:51 GMT
I found that the M Function is a multipermutation with a prob of
bounded by [1..1/64] since it doesn't matter what differences occur as
long as two are equal. The M function can be attacked as well, but
since both inputs are keyed you have a 1/4096 prob of picking the right
inputs. Thus the round function is "complete" except 1/2^18 of the
time, and it can be attacked with "at least" 1/2^36 work in a diff
attack and at most (which happens most of the time) with 1/2^72 since
all m functions will be active 95.3% of the time (63/64)^3 (1 for the
first step of the round and '2' for the second step).
I would appreciate some hrlp, comments, or suggestions... I am in the
middle of writting my notes for a TC8 paper I will post. I want to make
sure I am getting the math right.
http://www.geocities.com/tomstdenis/files/tc8.c
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sat, 07 Oct 2000 18:51:56 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: TC8 -- Yet Another Block Cipher
=====BEGIN PGP SIGNED MESSAGE=====
Mack wrote:
> [EMAIL PROTECTED] (Marc) wrote:
> >If I understand correctly, the "birthday attack" looks for two identical
> >blocks of ciphertext, and then uses their predessor ciphertext blocks
> >(which are the IV) to recover (cleartext1 XOR cleartext2)?
> >
> >A chaining mode like this (encryption)
> >
> > ciphertext = crypt( cleartext XOR chainregister );
> > chainregister += cleartext; // 64bit addition
> > chainregister += ciphertext; // 64bit addition
> >
> >shouldn't be vulnerable to birthday attacks, should it? The IV is
> >a) influenced by unknown information (the cleartext) and b) carried
> >on throughout the whole chain.
>
> That is very similar to PCBC which is
>
> ciphertext= crypt (cleartext XOR last_cleartext XOR lastciphertext)
>
> Since these propagate the state by an additional 64 bits no it isn't
> vulnerable to the birthday attack.
PCBC is vulnerable to matching ciphertext attacks in much the same way
as CBC, except that a matching ciphertext gives the XOR of four plaintext
blocks, rather than two.
In the mode that Marc described, matching ciphertext is more difficult to
exploit because the chaining variable depends on all the plaintext before
the second matching block. However, this is still not sufficient for the
scheme to be semantically secure, under the assumption that matching
ciphertext blocks can be found (note that the contribution of the ciphertext
to the chaining variable is known, and the plaintext may be highly patterned).
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOd6LiTkCAxeYt5gVAQGhFQf/SKcfRvn+vMEGvBc/27oPHo2wyFFlkaYl
d+exmH+IdeV8asc6pWV5fUXq3cKcK8k1JwqEH80r0fHoh8lO9ofGU19QctDbH+wc
RW+KxiwRhYR+fiJvzJGKdcog1oXAnZ1yy+4zHYFoqmfclDFvivWHPmoPW13ZXv7n
/+hFn9770Egy5Xu4b9leW5IqLbCrB6o7lkILoxPtSWcAAnsPWe7fB11ZL16moDay
Gl+KhhGEElxkhSW+udJ45uvOpDCniQtcpHey+it8PBMvoPatJhDp4rCGRaDgfuDV
mkgREHWlnFC8RGFph29r14QULEHUAJpQ3nm+cv5u4+qBmFKJ+gu76g==
=NCVT
=====END PGP SIGNATURE=====
------------------------------
From: "Martin Wolters" <[EMAIL PROTECTED]>
Subject: Re: RSA Key generation
Date: Sat, 7 Oct 2000 22:19:20 +0200
Martin Wolters schrieb in Nachricht <8ro0f2$h2p$[EMAIL PROTECTED]>...
>4. repeat steps 1+3 until d is an Integer.
oops. 2 and 3 of course.
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: Microsoft on modular multiplication
Date: Sat, 07 Oct 2000 13:14:17 -0700
In 1995 Microsoft claimed to have developed
a modular multiplication algorithm that outperforms
Montgomery's technique. They chose to keep it
proprietary.
I have two questions:
1) Have any independent parties verified that
claim?
2) Montogmery's technique is especially useful
when performing modular exponentiation. Is that
also true of Microsoft's purported technique?
------------------------------
From: "Martin Wolters" <[EMAIL PROTECTED]>
Subject: Re: securely returning password info to a server from a client
Date: Sat, 7 Oct 2000 22:22:13 +0200
William A. McKee schrieb in Nachricht <[EMAIL PROTECTED]>...
>I want to have my Java applet ask the user for password information that
>will be stored on a server for future password verification (using SRP).
>What is a secure way of getting the information from the client to the
>server?
I'd suggest to use Diffie Hellman to generate a key,
and use this key to encrypt the password. You can
send it to the server now.
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: Error-correcting code ?
Date: 7 Oct 2000 20:35:11 GMT
>Does anyone know an algorithm, simple or well-documented (like, source
>code) enough that an idiot like me can implement it, for
>error-correcting short strings of digits ?
>So that if someone writes down "123454321" and someone reads it back as
>"123454327" or "lZ34S43Zl" that I can recover the original number.
In your example, of 88 bits 12 are damaged (>13%, and not in bursts). This
is heavy duty for an error correcting code. I know of no simple algorithm
that can be explained in few lines, that is able to reliably correct this.
The simple to understand algorithms are good for burst errors (serial channel
communications) or single bit errors (storage). Is your example exaggerated
or do you in fact face such a high rate of bit errors?
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Pencil and paper cipher.
Date: Sat, 07 Oct 2000 14:17:29 -0600
In article <[EMAIL PROTECTED]>, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote:
> I'm not certain if anything like this has been done before, so if it
> has, somebody tell me. Also, if anyone can see any really obvious
> attacks, tell me.
>
> 1) Drop one letter from the alphabet, probably j (replace it with i).
My favorite letter to drop is W since there are only a few words with VV
in them and all are easily identified. JQ, or X might be dropped, but I
like the substitutions possible with JQX for comma, question, and period.
>
> 2) Convert the letters to numbers, writing them in base 5. Use either:
> 2a) Use the digits in order, so "a" becomes "00" and "z" becomes "44".
Of course, you are aiming for base 5 (25), but you could be aiming for
something else. Any base will work, but needing a square, rectangle
arrangement, as you might think you do, limits the choices. A more secure
cipher will cost you somehow.
--
A Pangram for the despot of your choice: 60) *He'd conquer the
pitiful by mixing key savage zeal with brutal injustice.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: NSA quote on AES
Date: Sat, 7 Oct 2000 13:32:46 -0700
UBCHI2 <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Let's see a definitive statement that they can't break the AES.
Why should they bother? Would anyone believe them?
--
poncho
------------------------------
From: [EMAIL PROTECTED]
Subject: Serial number scheme using DSA variant
Date: Sat, 07 Oct 2000 20:53:01 GMT
Hi!
First of all thanks for your help regarding short signatures.
After a while I came up with a scheme which could be the solution for
my problem.
I will sum up the requirements first so you can see for yourself if the
scheme meets those criteria.
This scheme will be used for secure serial numbers secure meaning that
no one else is able to forge serial numbers i.e. serial numbers can
only be given out by someone knowing the private key.
Requirements:
- serial numbers must be short (40 base32 characters at the most)
- serial numbers can be verified in reasonable time in the software
- no one should be able to generate serial numbers but me
(Security equal to cracking DES is secure enough)
- Only 16384 unique serial number required
Scheme:
I want to employ a DSA variant using only 128 bits for q instead of
160. The part of the signature for all possible messages (16384) which
is not dependant on the message is deployed with the software (the r
part in DSA). Therefore the application needs to store 16384*128 bits =
256 kbytes. The serial number will be delivered as
unique serial number|signature (s part)
thus taking up exactly 142 bits = 29 base-32 characters.
On runtime this serial number
Do you think this is secure? Any objections to this design?
As I understand it I do not need to hash the unique serial number
(otherwise I could use MD5 for example). Is this correct?
Thanks for your help...
kryps
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Reply-To: "William A. McKee" <[EMAIL PROTECTED]>
From: "William A. McKee" <[EMAIL PROTECTED]>
Subject: Re: securely returning password info to a server from a client
Date: Sat, 07 Oct 2000 21:19:21 GMT
Thanks for the replies. (I'm a real newbie at this crypto stuff.)
My applications is a Java (applet) based Asian language text editor with
server side resources for file i/o and language translation. I'm trying to
keep the applet small and off-load features to the server so the load time
is good.
I am using a stream cipher (ISAAC based) to encrypt the dialog between the
client and server. The dialog entails a detailed description of all edits
to the document so as to keep the client and server versions of the document
in sync. In addition, the client can request server side functions (like
"delete file", "rename file", etc.) be performed with the (optional) results
sent back to the client.
I generate the session keys using SRP so each user (by way of the client)
must first pick a password and register (store the user id and password on
the server) so the session can be secured each time the user logs on. Also,
for each user id, after logging on, the server returns a privilege mask that
enable or disables certain features in the client / server.
I plan to sign my Java code when I create a release (once I figure out how
to do it). This should prevent MITM attacks.
I have identified that sending password equivalent data in plain text is a
weakness in my current system. This is susceptible to password-guessing
attacks. How do I go about securing it? I would like to use a royalty free
library if one exists. Plus I don't want to break any Canadian / US export
laws if my software were to be used abroad.
How can I make use of SSL in my application? Where is SSL described? Is
there a C++ (server) / Java (client) library I can use? The main problem is
that SSL requires that each customer that runs the server must get a
certificate. This is not good for me.
TIA,
Will.
--
William A. McKee
[EMAIL PROTECTED]
Asia Communications Quebec Inc.
http://www.cjkware.com
"We're starfleet: weirdness is part of the job." - Janeway
Paul Rubin <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "William A. McKee" <[EMAIL PROTECTED]> writes:
> > I want to have my Java applet ask the user for password information
> > that will be stored on a server for future password verification
> > (using SRP). What is a secure way of getting the information from
> > the client to the server?
>
> Basically, unless you can already authenticate either the client or
> the server somehow, you have no way to detect a MITM attack.
>
> Normally the way you do this is have a secure SSL connection,
> authenticated by a CA-issued certificate on the server side. But for
> some reason you don't seem to want to do that. Another method is
> to use a signed applet (Netscape only) or .cab file (MSIE), and
> embed a public key in it that you authenticate the connection against.
>
> Without signing the applet or the connection somehow, you don't have
> any way to know that the applet itself hasn't been tampered with by a
> MITM. If the attacker can mess with the applet, al the rest of your
> protocols are useless.
>
> It would help if you said something about what your application is.
> That would make it easier to give concrete suggestions that fit your
> constraints.
------------------------------
Reply-To: "William A. McKee" <[EMAIL PROTECTED]>
From: "William A. McKee" <[EMAIL PROTECTED]>
Subject: Re: Q: does this sound secure?
Date: Sat, 07 Oct 2000 21:24:42 GMT
Thomas Wu <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "William A. McKee" <[EMAIL PROTECTED]> writes:
>
[snip]
>
> > Also, why is SRP safe against password guessing attacks? Seems like it
> > suffers from the same problem I had originally in my first attempt.
>
> No it doesn't - the first attempt you described allowed an attacker who
> eavesdropped on an authentication session to verify guessed passwords
> against the exchanged messages. This attack doesn't work against SRP
> because of the random secrets generated by the client and server. The
> NDSS paper (available from the SRP Web site) explains the protocol in
> more detail.
>
I was considering that the password file on the server had been compromised.
Could a password-guessing attack then successed?
--
William A. McKee
[EMAIL PROTECTED]
Asia Communications Quebec Inc.
http://www.cjkware.com
"We're starfleet: weirdness is part of the job." - Janeway
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: My Theory...
Date: Sat, 7 Oct 2000 14:10:04 -0700
David Blackman <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> David Rush wrote:
> >
> > "Scott Fluhrer" <[EMAIL PROTECTED]> writes:
> > > Tom St Denis <[EMAIL PROTECTED]> wrote in message
> > > news:8rb78n$ijl$[EMAIL PROTECTED]...
> > > > So the millions of 32-bit i386+ chips are not included in this
> > > > thought? Also how slow is Twofish on a ia64 anyways?
> > >
> > > Since I happen to have on hand the figures from a paper presented at
AES3:
> > >
> > > On an IA-64 simulator (an actual CPU was not available),
> >
> > That is such bullshit. At the least, SourceForge has an Itanium in
> > it's compile farm, and I'm quite sure that they would have allowed
> > it's usage to benchmark the candidates. Are you trying to say that
> > NIST couldn't get an IA-64 box w/Linux for themselves?
> >
> > I mean, incompentence *is* a significant factor in the US Gov, but
> > this is a bit beyond belief.
> >
> > david rush
>
> Read it again, loser. "a paper presented at AES3". IE, some researcher,
> who is probably at some obscure university or company that Intel has
> never heard of, did the testing and presented the results to the AES3
> conference. NIST could probably get hold of an Itanium if they really
> wanted to, but some random researcher would find it more difficult.
Well, (for the record) the work was done by John Worley, Bill Worley, Tom
Christian and Christopher Worley of Hewlett Packard Labs, which I rather
suspect Intel has heard of. They did state that:
"Lacking IA-64 hardware, we employeed three different types of
simulators... final timings used fully simulated RTL designs of the Merced
(now Itanium) and McKinley chips. This approach was extremely slow, and our
results often varied from day to day, as engineers improved their designs."
(Quote from AES Finalists on PA-RISC and IA-64: Implementation &
Performance, presented at AES3 by the above authors).
Apparently, the Itanium design was not finalized when they were actually
doing the analysis...
--
poncho
------------------------------
From: [EMAIL PROTECTED] (Andrew McDonald)
Subject: Re: How Colossus helped crack Hitler's codes
Date: Sat, 07 Oct 2000 21:40:06 GMT
On Mon, 02 Oct 2000 21:50:33 +0200,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> My memory isn't too well about I lecture that I heard
> several years ago. The lecturer, if not director, had
> at least a rather important position in the museum.
> I have now not the faintest idea of his name. He said
> that he was writing a book about the machine and the
> crypto techniques involved. He seemed to have been
> principally involved in the reconstruction of the machine.
That would probably be Tony Sale then. Looking on amazon.co.uk, there
appears to be a book titled "The Colossus Computer 1943-1996" by him.
Andrew
--
Andrew McDonald
[EMAIL PROTECTED]
http://www.mcdonald.org.uk/andrew/
OpenPGP DSA/ElG 1024/2048 3EDE 0FBC 6138 DCA0 FC8E C508 FCBB A9C8 F2DE ED36
------------------------------
** 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
******************************
