Cryptography-Digest Digest #17, Volume #11 Sun, 30 Jan 00 18:13:01 EST
Contents:
Using blowfish as a one-way hash? (ChenNelson)
Encryption Puzzle Contest (John Cairns)
Re: XML vs Javabean for B2B ("John A. Malley")
Diffie-Lamport Signatures on Web Site (John Savard)
Re: Mac encryption algorithm? (Richard Outerbridge)
KEA gains something with RSA instead of D-H (John Savard)
Re: "Trusted" CA - Oxymoron? (Anne & Lynn Wheeler)
Re: A Stronger VIC Cipher (was Re: Pencil & paper cipher question) ("r.e.s.")
What is the status of AES? (Ed Pugh)
Re: Intel 810 chipset Random Number Generator ("Douglas A. Gwyn")
Re: Clock drift (was Intel 810 chipset Random Number Generator) (Sandy Harris)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (ChenNelson)
Subject: Using blowfish as a one-way hash?
Date: 30 Jan 2000 21:30:22 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
In _Applied Cryptography_ Schneier noted that blowfish is not to be
used as a one-way hash. Why is this so, in CBC mode?
Later,
Nelson Chen
=====BEGIN PGP SIGNATURE=====
Version: PGP for Personal Privacy 5.5.2
Comment: For public key, go to key server with key ID 0xD28C0DD9
iQA/AwUBOJSt4m1ACZTSjA3ZEQKF1gCfU6QM9NjaRwHZ7AJhs6fCyjag0xQAn3OM
VeUGPymlQf86N+LxKWpYb8ji
=Sspx
=====END PGP SIGNATURE=====
==========================
To earn $0.05 per clickthrough from your web page, please go to
http://www.3wmart.com/ and sign up for our button banner program.
------------------------------
From: John Cairns <[EMAIL PROTECTED]>
Subject: Encryption Puzzle Contest
Date: Sun, 30 Jan 2000 14:39:10 -0700
Encryption Puzzle Contest, Feb 2000
Hi,
I thought it would be fun to post an encryption puzzle contest. I've
had the idea to host an encryption party for a long time, and thought
that the natural extension would be to do it on USENET, i.e., to up the
stakes and make it fun for anybody who is interested in participating.
If you are interested, please go to rec.puzzles and search for the
thread "Encryption Puzzle."
Contest Rules:
1. The contest is a sequence of encrypted messages that all lead up
to a solution, an event, place, thing, person, whatever, based on
the
category. The winner will be the individual who solves the most
parts of the puzzle first, and earns the most points. Each weeks
message will become progressively harder until I sense that the
puzzles are beyond many people's ability. We'll have to experiment
with difficulty until we get it just right. The contest is
designed for humans, hopefully machine solution will not be
strictly needed.
2. An enciphered message will be posted once per week. The message
will include basic clues, category, and other information to
get you started. Anyone who solves one of these puzzles will
receive 50 points. If you are first to solve it, you will receive
a 100 point bonus.
3. At mid-week a hint will be posted that should clear up muddied
waters, and reveal a bit more information. Anyone who solves the
puzzle after the hint has been posted will receive 25 points.
4. Each message is really part of a series of messages that leads up
to the final puzzle solution. The first one to find the overall
solution will receive 250 points, and end the contest. You
have a chance to win even if you don't decrypt any of the
messages, however, no guessed solutions will be accepted before
the third week. I don't want a mailbox full of guesses! If you
think you know the answer, tell me how you got it based on the
decrypted clues. Once the contest is over, points will be
tallied, and the winner will be announced in rec.puzzles.
5. You may use any means at your disposal to solve the puzzle. This
includes computers, puzzle groups, friends, relatives, the NSA,
whatever. I will accept any valid solution.
6. Must show your work. To level the playing field you must reveal
which programs, persons, books, if anything you may have consulted
to
determine the solution. Please, also include a description of how
you solved the puzzle, so others can learn. Identify your sources.
7. In order to be included in point tallies you must send your
solution along with your name and E-mail address to
[EMAIL PROTECTED] If you win I will post your name and E-mail
address so let me know if you wish to remain anonymous. The
winner can not be anonymous!
8. Please feel free to discuss the contest, puzzle, post additional
information, etc. in the newsgroup, however, please do not reveal
the solution, or the means to obtain a solution until after I have
announced the answer!
9. I will post the deciphered message at the end of the week, along
with information about how the message was encrypted.
10. Don't cheat. There is nothing to gain by cheating, this is all
just for fun, so play fair, and we will all have a good time.
11. The default language will be English, but proper names,
substitutions, and other languages may be used depending on
appropriateness. Proper names and use of other languages should
be considered a clue. Language translation will not be used as a
specific form of encryption.
--
John Cairns
contest E-mail: [EMAIL PROTECTED]
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: XML vs Javabean for B2B
Date: Sun, 30 Jan 2000 14:08:48 -0800
Drew Cutter wrote:
>
> Which would offer better encryption , XML or Javabean for B2B
> transactions ? Wireless ?
That's an unusual question. "Better" in what sense?
XML is a logical representation of the layout of data to be
displayed/used by the recipient. We send / receive XML files (just like
HTML files.) We can tag items in a file with our own Document Type
Definitions. Software at one location can make an XML file and send it
to other software on other locations. The recipient parses XML and acts
on the content per some intended design.
A JavaBean is a "piece" of software with a defined interface allowing
other pieces of software at run-time to interact with it via public
methods. These public methods allow us to set and get the values of
public attributes and to invoke the javabean's public behaviors.
Encryption/decryption fits either. Any software generating XML can
embedded encrypted data in the XML format. The recipient must parse the
XML and decrypt the data. Or the XML generator can send the XML file
"as-is" to the recipient through a secure communications protocol like
Secure Socket Layer (SSL.) A JavaBean can send/receive data or file
streams with other software. The public methods can encrypt data before
sending it by stream and the recipient can decrypt the stream when it
gets there. And vice versa. A JavaBean could even generate XML files and
parse XML files from other JavaBeans.
It's the expected data volume per session verses the bandwidth between
nodes AND the communications "environment" between nodes that count.
How much data must pass between two modes verse the bandwidth? How much
will it cost per byte to send/receive data? How often does a connection
between nodes drop per unit time? What's the overhead of encrypting at
the nodes on the communications "pipe" - how fast can the data be
encrypted/decrypted? Can it keep up with or surpass the data rate
through the "pipe?" What's the least acceptable sacrifice in terms of
"security" to gain in terms of bandwidth use? (Thinking of chaining
modes, error recovery.)
Low bandwidth intermittent communications between modes can require the
sender node "pre-process" as much as possible - i.e.. encrypt the
message before sending it, not while sending it, since encryption
(depending on the algorithm) may take some time. Example - make an XML
file with embedded encrypted data before a connection is made, make the
connection, then send the file as fast as possible.
An environment with limited bandwidth and high risk of signal loss (say
with a highly mobile mode that may pass beyond range occasionally as it
moves) it may make sense to send a small XML file with embedded
encrypted data in it. Or to just encrypt the entire file and send it.
John A Malley
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Diffie-Lamport Signatures on Web Site
Date: Sun, 30 Jan 2000 22:02:17 GMT
I had been trying to look up information about implementing
Diffie-Hellman, and I happened to run across the Diffie-Lamport
signature scheme. As it is a method of performing digital signatures
without the use of public-key methods (essentially, it uses DES to
produce plaintext/ciphertext block pairs as a one-way hash of the key,
and then associates each hash with a particular value for each bit in
the message to sign later; revealing the keys corresponding only to
the actual bits proves the message was sent by you), I thought it
important to mention it, to illustrate the limits of different types
of technique.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: Richard Outerbridge <[EMAIL PROTECTED]>
Subject: Re: Mac encryption algorithm?
Date: Sun, 30 Jan 2000 17:24:04 -0500
=====BEGIN PGP SIGNED MESSAGE=====
2000-01-30 16:58:31 EST
Gentlemen, gentlemen, gentlewomen, let's settle down.
Big-endian, little-endian: it's all in the idioms. It's as
easy to move the least-significant byte from a long into place
from one scheme or the other once you know what you are doing.
The only place it could possibly make any difference is right
at a serial port, which in turn depends upon which end of the
byte you're shunting out first. But all of that is handled
in hand-waving hardware at this point. OK, I'm a big-endian
Mac 68K bigot, but I've seen the light: it just doesn't matter.
It's like The One True Brace Style in C: what makes the most
sense to you? Or rather, which way of thinking about it makes
it easier for you to make sense of it?
Oh, obligatory Mac encryption algorithm? Look for Curve Encrypt.
outer
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.5.1i
iQEVAwUBOJS5vUJrWteExW9jAQHBEAf/R/coO8ucfhOBu8SqJtL8z+BnsKH6lZBB
x9VNMouIwrOPjbZ4tXKMvxCZly4Y6k55y4e96RNiQONEWzNTrWvwzHSGj3WRfUV0
C/aT75qAeyoOhn4ekujDoLx6aFDJ9/w8tU1OeiFAgPTrBwZF2GaQByHMbznVvhxo
Prbqw8KkeCEaQQ7+8OwnxBQkEuuu+5vvkjxYdaVRyYHL8lCLWOLq75yslAoaDKH1
j8wWWYFPf7v0uiV9bQWXgPgjaL2kOEOxd5Y6BFP9+jeDpoLWrmIJ4t/YbwBx0FyZ
JgATHclpXzZ6JW+ts/xCPLWQ2qXxvlUmXKPlN3Q6iHCIjszX7Ml/hw==
=BIAC
=====END PGP SIGNATURE=====
--
<[EMAIL PROTECTED]> :
Just an eccentric soul with a curiosity for the bizarre.
Payloads to: A902/MCE307/17TPU-28433615 (or thereabouts)
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: KEA gains something with RSA instead of D-H
Date: Sun, 30 Jan 2000 22:09:48 GMT
The Diffie-Hellman key exchange method involves one party knowing x,
the other knowing y, A^x and A^y (mod p) being public, and only the
two parties can determine A^(xy) (mod p). Note that knowing either
party's private key is sufficient to derive A^(xy) from A^x and A^y.
RSA, on the other hand, involves the exchange of messages which, while
they were composed by the originator, can only be read with the
private key of one of the parties.
Hence, if a protocol like KEA were used, sending two session keys in
opposite directions simultaneously, but with RSA instead of
Diffie-Hellman, with the XOR of the two session keys being used as the
actual session key, communications would remain secure *even if the
private key of one party had been compromised*. (There is, however, no
inherent immunity to the man-in-the-middle attack. But if one party
has access to a better key certificate database - or more secure
access to the certificate database - than the other, then KEA with D-H
will also help avoid that attack. Perhaps that is its point.)
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
Subject: Re: "Trusted" CA - Oxymoron?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Sun, 30 Jan 2000 22:33:36 GMT
[EMAIL PROTECTED] (Timothy M. Metzinger) writes:
> as many people have indicated, for a transfer of wealth, the identities of the
> individuals aren't important, only the identities of the two containers ("from"
> and "to") matter.
>
> But for signed documents, legal briefs, title transfers, and other
> applications, it IS important to verify individual identities.
>
> While many commercial CA's don't verify identity, some do... Digital Signature
> Trust Corp, Verisign, Baltimore (formerly GTE CyberTrust), and the DOD CA's do
> have certificate policies where they do a face-to-face registration of
> individuals, and stand behind the certificate's binding.
note that manufactored certificates done at some time in the past is
relying on some consensus/domain about the information being
certified.
(not having) identity is issue in many circumstances. also, to some
extent a business process would come down to doing a string compare
against some arbritrary, generalize "identity" representation carried
in sort of string embedded in a manufactored certificate and so other
arbritrary identity representation string (presumably if the string
compare match ... then some business process can proceed). There have
been recent SSN privacy postings citing both same SSN as well as same
first/last name (i.e. same SSN number given out to two different
people with same first/last name).
financial transfers need near-time certification associated with
specific domain (and circumstances like current account balance and/or
outstanding debt) by institutions carrying at least some liability
associated with the process (as opposed to random 3rd parties).
simplified certificates have been transition from offline/paper to
offline/electronic. however, in growing number of even document
transactions (not limited to purely financial transactions) there is
more & more of a move to online/electronic (pretty much anything
involving value exchange and/or liability).
Effectively starting to see transition to real time certification
within the domain/context of the specific operation taking place
... especially when the certifying agency carries some liability, risk
& handling filing (transaction is registered in some central filing
place ... so the repository also does a form of real time
certification).
Example is title insurance company handling title transfers, they will
certify individual(s) within the context of the title transfer & just
for the specific title transfer (in part because they carry liability
on each specific title transfer ... so the idea of a "blank check"
certificate for an arbritrary & unknown number of title transfers
involving arbritrary & unknown value is not likely).
Stale certificates represent much more of transition from
offline/paper to offline/electronic ... but I would expect to see much
more real-time certification in transition to online/electonic, even
for document signing, especially where there is value/liability
involved and especially when some sort of filing is required. Each one
becomes a specific, known, & likely time-stamped certification ... as
opposed to a blank check certification/certificate that might be used
in an arbritrary & unknown number of times involving arbritrary &
unknown value (businesses tended to not like unknown/unbounded
liability/risk).
The play for offline/electronic identity certificates would tend to be
when value proposition seems to be negligible risk/liability (say
government employees within legislated context) &/or an online+filing
infrastructure represents significant percentage of value proposition.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: A Stronger VIC Cipher (was Re: Pencil & paper cipher question)
Date: Sun, 30 Jan 2000 14:35:49 -0800
"David Wagner" wrote ...
: r.e.s. wrote:
: > After mulling this over a bit more, I wonder if, instead of literally
: > making the seed longer (with all the adjustments that entails), it may
: > be better to simply use additional passphrase letters to define two
: > independent 10-digit substitution tables to add confusion to the
: > transposition keys extracted from the LSFR output. (Details below.)
: > This will add about 44 bits of entropy to the 10-digit seed's 33 bits,
[...]
:
: If I guess the LFSR's initial fill (2^33 trials), I can recover the
: inputs to the transposition tables. (Right?)
I'm not sure what you mean by "inputs to the transposition tables".
If that means the sequence of digits used to fill them, then no. You
couldn't deduce that sequence from the seed together with the ciphertext,
because you wouldn't know the transposition keys -- that's just what the
"modified version" prevents by introducing additional confusion in each
of those keys.
Correctly guessing the 10-digit LFSR seed will give you the number of
columns used in each transposition -- and also the checkerboard, unless
the checkerboard's letter-arrangement is considered secret. In any case,
you'd still not know the keys for the columnar readouts of the two
transpositions, because they've each been "re-keyed" by separate 10-digit
substitution tables. So there would still be 10!^2 ~ 2^44 possibilities
to search.
: Is there a way to recover information about the tables
: given their inputs, the ciphertext, and a statistical model
: for the plaintext and the passphrase?
:
: Here's one approach one might try. Look for repeated table inputs.
: They cause the table outputs to repeat in the same positions. Then,
: I can check whether that patten of repeats in the keystream looks
: plausible given the ciphertext. Does this provide enough information
: that I can expect to rule out wrong guesses at the initial fill?
: If so, that's an O(2^33) break.
Unless I'm misunderstanding, such "table inputs" wouldn't be available.
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Ed Pugh)
Subject: What is the status of AES?
Date: 30 Jan 2000 22:48:35 GMT
Reply-To: [EMAIL PROTECTED] (Ed Pugh)
I am wondering whether the cipher for the AES has been chosen yet.
If so, which one was chosen? If not, what ciphers are on the
current "short list"? What is the schedule for the AES project?
I am also wondering whether any of the candidates have been
implemented in any high-speed ASIC device (other than 3DES if
that is, indeed, a candidate).
Is there a web site which keeps up-to-date news on the AES? Also
is there a web site that details comparitive strengths and weaknesses
of the different ciphers being considered for the AES or one which
lists high-speed chip implementations?
Due to the busy-ness of this group, I would appreciate it if you could
CC: your follow-ups to:
[EMAIL PROTECTED] (alias [EMAIL PROTECTED])
TIA for any help.
--
Ed Pugh, <[EMAIL PROTECTED]>
Richmond, ON, Canada (near Ottawa)
"Bum gall unwaith-hynny oedd, llefain pan ym ganed."
(I was wise once, when I was born I cried - Welsh proverb)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: Sun, 30 Jan 2000 22:53:22 GMT
Tim Tyler wrote:
> While (obviously) you could - in principle - extract *some* randomness
> from crystal clock drift, it is /far/ from clear that the effect could
> be used to produce random numbers at a practical rate.
The idea of using a *crystal* as basis for a RNG was dumb in the
first place, and the entire "discussion" since then seems to have
been an attempt to rationalize what was always a mistake.
------------------------------
From: [EMAIL PROTECTED] (Sandy Harris)
Crossposted-To: sci.physics
Subject: Re: Clock drift (was Intel 810 chipset Random Number Generator)
Date: 30 Jan 2000 22:55:03 GMT
[EMAIL PROTECTED] (Michael Kagalenko) spake thus:
>Sandy Harris ([EMAIL PROTECTED]) wrote
>][EMAIL PROTECTED] (Michael Kagalenko) spake thus:
>]
>]> ... So far, no one evinced any signs of having
>]> understood what I am saying in plain English over and over and over.
>]
>]I'm coming in to this discussion late.
>]
>]From here it looks as though you're advocating at least three clearly
>]nonsensical propositions:
>]
>] 1) clock drift has enough randomness to be interesting for
>] cryptographic purposes
>
> Not quite. The specific kind of clock drift does. What kind
> was explained several times, so I am nto going to repeat just for you.
> Dejanews has my earlier posts.
Let's see.
One clock might drift few seconds per hour and you might have resolution
down to nanoseconds. Difference of two clocks after an hour is some
number in the range of a few billion nanoseconds. Even assuming that is
entirely random, you've got at best about 32 random bits an hour.
Sorry, we need a few K bits per second for a heavily loaded crypto server.
So perhaps we should compare clocks a few dozen times/second and if each
comparison gives a few dozen random bits (I'd be surprised if it does,
but this can be measured and I could easily be wrong.), then we'll be in
the right range?
OK, but we have to do it inside our computer to avoid silly amounts of
net traffic, and of course for security reasons.
So now we have two clocks locally and we're looking at drift. Of course
we don't want to publish either clock, since we want this to be secure.
So we need a third clock for system use. The two drifting clocks are
dedicated to this use.
At that point, you no longer need clocks. You can simplify the design
by replacing the clocks with a pair of free-running oscillators and
some sort of digital circuit that turns their random phase differences
into bits.
So your idea, in what appears to be the only sensible implementation,
reduces to the two-oscillator design Intel and quite a few others use.
>]
>] 2) a protocol involving connections to an Internet time server
>] can be secure enough to trust for cryptographically important
>] random numbers
>
> Yep. In every mechanism of random data generation you have to trust
> something.
Sure, but when I'm generating a personal key or a random number my system
will trust (e.g. nonce in an authentication protocol) it would be insane
to trust anything not under my control.
------------------------------
** 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
******************************
