Cryptography-Digest Digest #869, Volume #12 Sun, 8 Oct 00 00:13:01 EDT
Contents:
Re: Error-correcting code ? (Peter Pearson)
Re: NSA quote on AES (Mack)
Re: Advanced Encryption Standard - winner is Rijndael (Mack)
Re: securely returning password info to a server from a client (Thomas Wu)
Re: Advanced Encryption Standard - winner is Rijndael (John Savard)
Re: Deadline for AES... (Mack)
Re: Q: does this sound secure? (Thomas Wu)
Re: Q: does this sound secure? (Thomas Wu)
Re: TC8 -- Yet Another Block Cipher (Mack)
Re: No Comment from Bruce Schneier? (Joaquim Southby)
Re: Q: does this sound secure? (Paul Rubin)
----------------------------------------------------------------------------
From: Peter Pearson <[EMAIL PROTECTED]>
Subject: Re: Error-correcting code ?
Date: Sat, 07 Oct 2000 19:18:14 -0700
[EMAIL PROTECTED] wrote:
> 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.
I'm sure there are more sophisticated approaches (c'mon, guys, help
me out), but a simple technique is to add two check digits and
to insist that all legal strings be multiples of, say, 97. When
a string shows up that is not a multiple of 97, look for the most
likely modification that would fix it. "Most likely" depends on
what sort of corruptions you're anticipating.
Hoping this helps -
Peter
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: NSA quote on AES
Date: 08 Oct 2000 02:48:40 GMT
>On 06 Oct 2000 20:30:12 -0700, Eric Smith
><[EMAIL PROTECTED]> wrote, in part:
>>[EMAIL PROTECTED] (Mack) writes:
>
>>> After the Skipjack fiasco the NSA is being much more careful.
>
>>What Skipjack fiasco is that?
>
>Perhaps he means the Clipper Chip controversy. (No, AFAIK, SKIPJACK
>hasn't been cracked.)
>
>John Savard
>http://home.ecn.ab.ca/~jsavard/crypto.htm
>
>
The whole thing was a bit of a fiasco. The algorithm was finally
made public. There was a weakness but it wasn't in Skipjack itself.
But Skipjack does have a structure that lends itself to impossible
differential analysis. So far as I know the 80 bit key was
the major weakness. 56 bit keys are obviously crackable.
80 bits is 16 million times harder but that certainly isn't going
to prevent attack 20 years from now. Anyone with enough money
could probably build a skipjack cracker that will provide keys for
a specific known plaintext/ciphertext pair.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: 08 Oct 2000 02:57:15 GMT
>
>Anonymous wrote:
>>
>> Is there truly ANYONE stupid enough to believe ANY government would
>> adopt an encryption standard that DIDN'T have a back door for unlimited
>> government access?!?!?!
>> This is just the software version of the "clipper" chip- only >this
>> time<, the government didn't repeat their earlier mistake of admitting
>> they have the capability to easily decrypt the data.
>> But in all fairness, the US government >has< established itself as
>a
>> decade-long enemy of encryption that they can't easily decrypt.
>> It's a safe bet the government chose the Rijndael encryption method
>> because they can >already< decrypt it.
>
> So what good would this do them? They couldn't, for example, admit
>decrypted data into evidence because that would make it obvious that
>they could break the cipher. They couldn't even use the information
>indirectly to aid prosecution, because that would mean an ever-widening
>circle of law-enforcement personnel who knew that the cipher was broken.
>
> About all they could use it for are issues of the highest national
>security, where the decrypts and information relating to them, were held
>in to the smallest number of people possible.
>
> I give very little weight to poorly reasoned arguments advanced
>anonymously.
>
> DS
>
The NSA never admitted to owning a DES cracker. However it is
very likely that one was built in the 80's. It was technically feasible and
not outrageously expensive. By government standards anyway.
I doubt they had one when the standard was approved. They could have
though. It does show that they 'might' do something like that.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: securely returning password info to a server from a client
Date: 07 Oct 2000 20:02:50 -0700
"William A. McKee" <[EMAIL PROTECTED]> writes:
> 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.
SRP solves the problem of deriving a big secret (a session key)
from a little secret (a password) securely, but it doesn't solve the
problem of how the little secret is initially established. Usually,
the user is given the initial password out-of-band. If that isn't
possible, then for the initial registration process do a D-H key
exchange (or some equivalent) and have the client compute the
verifier (g^x mod p) and send that encrypted under the D-H session
key to the server. Although the anonymous D-H might be attacked
by a MITM, note that the adversary must then get in the middle of
all subsequent sessions to avoid detection.
Embedding a root cert/public key in your applet, as was suggested
before, is another solution that buys a bit more security at the
expense of more infrastructure, since you now have to certify
servers by issuing them certs and figure out how to prevent one
certified party from impersonating another. Or you could have
your server admins embed their own root keys into the applets
themselves and push the applet signing into their court, but now
the server admins need to buy code-signing certs. All in all,
the D-H solution above might start to look appealing after a while.
:-)
> 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.
Are you talking about session encryption? There are lots of free ways
to accomplish that. Please clarify.
> 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.
The best way to do this would be do boostrap SSL with the SRP session
key instead of relying on certs, but it's not clear if you can use
just the transport-layer security of SSL without using some form of
cert-based authentication first.
> 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
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Sun, 08 Oct 2000 02:49:49 GMT
On Sat, 07 Oct 2000 17:50:23 -0700, David Schwartz
<[EMAIL PROTECTED]> wrote, in part:
> So what good would this do them? They couldn't, for example, admit
>decrypted data into evidence because that would make it obvious that
>they could break the cipher. They couldn't even use the information
>indirectly to aid prosecution, because that would mean an ever-widening
>circle of law-enforcement personnel who knew that the cipher was broken.
Breaking ciphers is usually used for purposes of collecting
intelligence, as in espionage, where keeping success a secret is a
matter of course.
I will agree, however, that the "usual paranoia" need not be taken
seriously.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Deadline for AES...
Date: 08 Oct 2000 03:18:55 GMT
>
>
>David Hopwood schrieb:
>
>>
>> Mok-Kong Shen wrote:
>> > David Crick wrote:
>> > > Mok-Kong Shen wrote:
>> > > >
>> > > > > Would you please point out what is incomplete in the
>> > > > > documentation of *any* of the finalists?
>> > > >
>> > > > The most conspicuous one and about which I have the
>> > > > most concern is that there are lots of numbers (numerical
>> > > > constants) whose derivation is not clear to the reader,
>> > > > i.e. these cannot be reproduced by them in some way. This
>> > > > provides an essential ground to nurish doubts about the
>> > > > absence of backdoors. Certainly it hinders a proper
>> > > > understanding and hence probably also analysis.
>> > >
>> > > Section 7 of the Rijndael submission document explains the
>> > > reasons for the design choices. Is there anything in there
>> > > that you are not happy with?
>> >
>> > I want specifically to be able to re-calculate every
>> > number that is in a cipher.
>>
>> As far as I can see this is satisfied for Rijndael. What specific
>> number do you think can't be recalculated?
>>
>> > If certain groups of numbers
>> > are said to have been chosen to lead to a certain property,
>> > I like to be able to run a program to verify that that
>> > property is indeed (optimally) achieved.
>>
>> Section 7 and the sources it references ([LiNi86] and [Ny94])
>> provide enough information to do that.
>
>By recalculation I mean one has to start from some
>concepts of the author of a cipher and obtain certain
>numbers the same as given and 'only' these numbers.
>I have currently only the AES document. Could you please
>tell how the affine transformation of ByteSub is arrived
>at, i.e. why is this particular transformation chosen?
>Thanks.
>
>M. K. Shen
>
>
That choice is fairly arbitrary I think. They state that it
provides certain properties. No fixed points for one.
If you are unhappy with the choice it would certainly be easy
to replace the ByteSub for 'private' use. It could even
be set up as a keyed table.
Back to Rijndael. The properties of the s-box are such that it
is unlikely that a backdoor exists. The very simplicity of the
polynomials used certainly hinders the insertion of trap doors.
The s-box itself is taken from the Nyberg construction.
The affine transformation is stated to
1) remove fixed points.
2) be the simplest possible.
3) add the most complexity to prevent interpolation attack.
It seems a reasonable choice given the design criteria. The
whole algorithm seems to be a 'fix' of Square. It is definitely
a direct derivative.
I believe that a document was produced further explaining
the design rationale, but don't quote me on that.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Q: does this sound secure?
Date: 07 Oct 2000 20:29:42 -0700
Paul Rubin <[EMAIL PROTECTED]> writes:
>
> Look, do yourself a favor, stop trying to design protocols. The
> simplest way to do what you're describing is encrypt the whole channel
> with SSL if you can. Then you can just send the unhashed password
> over the encrypted channel and hash it on the server side if you're
> storing hashed passwords in the database. If you're writing a web
> application, this also lets you avoid needing an applet, and avoiding
> applets is always a good thing.
>From the way he described his system, though, the application he was
trying to protect was in fact an applet, and this applet needed a
secure authenticated channel back to the server. So avoiding an applet
wasn't possible anyway, and SSL is the harder approach since you don't
get to leverage the browser's builtin SSL code.
> If you can't use SSL and you're serious about protecting the
> passwords, you have to use something like SRP
> (http://srp.stanford.edu) or one of its many equally complicated
> competitors. But I don't recommend that because it's a big hassle,
> plus AFAIK all these schemes require secure random numbers on the
> client side, which are not necessarily easy to come by.
Well, it used to be a hassle until prepackaged distributions for SRP and
PAK, etc. showed up. As far as client-side random numbers go, doesn't
SSL require the client to generate a pretty big random chunk and
encrypt it for the Web server? Is there in fact a strong cryptographic
authentication/key-exchange protocol that doesn't require strong
client-side randomness (128 bits entropy or more)?
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Q: does this sound secure?
Date: 07 Oct 2000 20:36:26 -0700
"William A. McKee" <[EMAIL PROTECTED]> writes:
> 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?
If an attacker reads the password file, then he could brute-force each
entry and guess at the password, yes. But I believe that under your
original scheme, an attacker who read the password file would gain
instant access to all the accounts without even needing a
dictionary attack. So there's an attack, but it's not the same attack.
There's a paper out by W. Ford and B. Kaliski from Verisign that describes
a scheme that splits the verifiers across multiple servers so that
a password-guessing attack requires the compromise of all the servers,
not just one. If such a configuration is practical for your customers,
you might want to give their paper a read.
> --
> William A. McKee
> [EMAIL PROTECTED]
> Asia Communications Quebec Inc.
> http://www.cjkware.com
>
> "We're starfleet: weirdness is part of the job." - Janeway
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: TC8 -- Yet Another Block Cipher
Date: 08 Oct 2000 03:40:26 GMT
>-----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.
But that would require by the birthday paradox 2^64 pairs which for a 64 bit
block
cipher is the entire codebook. From the original description it appears to be
a
64 bit block cipher. if the key is also 64 bits then it is equivalent to brute
force
search.
>
>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).
This is true but for a 64 bit block cipher with a 64 bit key you
really can't improve significantly on PCBC. If the key is larger
this may not be true.
On a side note for the matching text attack to be useful
a) you must be trying to forge a new message with a specific block of text.
b) you must be trying to decipher a specific block of text
In either case the birthday paradox no longer holds. if you
can use a random block in a) then you don't really need to know
what it means.
>
>- --
>David Hopwood <[EMAIL PROTECTED]>
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: No Comment from Bruce Schneier?
Date: 8 Oct 2000 03:54:35 GMT
In article <[EMAIL PROTECTED]> SCOTT19U.ZIP_GUY,
[EMAIL PROTECTED] writes:
>>Try again, Mr. Scott. Have you forgotten the claims you made a year or
>>so ago about altering software in fielded weapons systems? I challenged
>>you to prove those claims and you were unable to do so. Not only are
>>you a liar, you are an accomplished one.
>>
>>
>
> Well as Clinton or his clone Gore would say. It depends on your
>defination of "lie" and just what is considered a fielded weapons
>system. As an example I was an expert TC2 programmer and made
>numberous changes in the programs and algoriths for that. But I
>doubt you even know what a TC2 computer is. Hint it was made by
>IBM.
>
I remember that thread. You tried to hide behind these "depends on your
definition" tricks of evasion and obfuscation back then, too. Somehow,
you never answered any of Forrest's questions about your "exploits". Not
only did you never do the things you claimed to do, you defamed others by
calling them lazy, incompetent and/or malicious. Forrest called your
bluff back then and gave us all a calibration point on the overall worth
of your statements. I'll go with him on this one -- you are a liar,
through and through.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Q: does this sound secure?
Date: 07 Oct 2000 21:05:55 -0700
Thomas Wu <[EMAIL PROTECTED]> writes:
> From the way he described his system, though, the application he was
> trying to protect was in fact an applet, and this applet needed a
> secure authenticated channel back to the server.
This wasn't clear from the descriptions I saw.
> So avoiding an applet wasn't possible anyway, and SSL is the harder
> approach since you don't get to leverage the browser's builtin SSL code.
Applets can open SSL connections back to the server, at least in MSIE,
I believe.
> Well, it used to be a hassle until prepackaged distributions for SRP and
> PAK, etc. showed up.
Is there a Java implementation of SRP that can be used in an applet?
> As far as client-side random numbers go, doesn't
> SSL require the client to generate a pretty big random chunk and
> encrypt it for the Web server?
Yes it does. SSL in browsers is usually implemented in native code
of the machine the browser is running on. You can get a reasonable
amount of entropy in native code, though it's not necessarily that
simple to do so. However, in Java applets it appears to be harder.
The browser's SSL stack might generate good random numbers, but I
don't know of any way to get at them from an applet.
------------------------------
** 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
******************************
