deriving multiple keys from one passphrase

2006-10-10 Thread Travis H.

What is the accepted way to derive several keys from a user-supplied input?

Or, can you see anything wrong by prepending a counter to the passphrase
and hashing it to create derived keys?

k_n = hash(n || passphrase)

I suppose a faster system would involve using hash(passphrase) as the
key and encrypting a counter (assuming that hashes are slower than
block ciphers).

k_n = E(hash(passphrase), n)

Both seem vulnerable to dictionary attacks, and it's not immediately clear
to me how I could prevent them, or if that's even possible.

Terry Ritter suggested using CRCs over the passphrase, but I haven't really
analyzed that method at all.

Any opinions?
--
Enhance your calm, fellow citizen; it's just ones and zeroes.
Unix guru for rent or hire -- http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Discussion of SIGABA, FPGA query, automated cipher construction, c.

2006-10-10 Thread Travis H.

First, I found this interesting site by John Savard which discusses
the various crypto designs since... well, since pencil and paper
systems.  Notable is the detailed discussion of the declassified
SIGABA machine:
http://www.quadibloc.com/crypto/jscrypt.htm

Next, can anyone point me in the direction of any web references on
using FPGAs to implement cryptographic (or other) algorithms?  I would
like the speed of hardware, but feel that it is necessary to amend the
algorithms as the state of the art advances.  I've also wanted to do
some low-level hardware interfacing.

Have there been any attempts to construct ciphers based on a key or
random number?  It would be interesting to see a family of ciphers
from which one is chosen periodically, in addition to re-keying.  I
suppose that one could permute S-tables in Feistel-type ciphers fairly
easily (a la traditional Unix crypt() salt), but have there been any
more general efforts, perhaps using virtual machines or lisp?  I do
realize that an algorithm is already parameterized by the key, but the
general structure remains the same.

I found this amazing paper on sandboxing x86 code (software-based
fault isolation),
and due to some engineering the overhead is pretty minimal (20% on SPECint2000):
http://www.usenix.org/events/sec06/tech/mccamant.html

Using a method like this between two systems with the same instruction
set, the crypto protocol initiator could even send the algorithm they
want to use to encrypt, compress, or otherwise transform the rest of
the session, and the recipient could ostensibly execute it safely, and
vice-versa.

If any of you are die-hard assembly or algorithm mavens, this book
might interest you:
http://www.amazon.com/Hackers-Delight-Henry-Warren-Jr/dp/0201914654
--
Enhance your calm, fellow citizen; it's just ones and zeroes.
Unix guru for rent or hire -- http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-10 Thread James A. Donald

--
Kuehn, Ulrich wrote:
 However, this is the big problem with the TPM
 according to the TCG spec. While you can remotely
 verify that the system came up according to what you
 installed there, you have no means to force it to
 either come up the way you want, or to be in a clear
 error state. That is the huge difference between the
 verifiable booting the TPM provides and secure
 booting, which would run only predetermined software.

 I assume that the TCG chose not to implement the
 latter due to fear of public bashing...

What we want is that a bank client can prove to the bank
it is the real client, and not trojaned.  What the evil
guys at RIAA want is that their music player can prove
it is their real music player, and not hacked by the end
user. Having a system that will only boot up in a known
state is going to lead to legions of unhappy customers
who find their system does not come up at all.


--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 mzJSAlA4uoeaqcIPwxmdSTaMGpCr10BSXet2rKo+
 4C0qq8mGmz37gK89YinlEpVVumD1TtkcDOd8iHHGh

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


handling weak keys using random selection and CSPRNGs

2006-10-10 Thread Travis H.

Hi all,

It occured to me that there is a half-decent way to avoid weak keys in
algorithms
when it is undesirable or impossible to prompt the user for a
different passphrase.
It is even field-upgradable if new weak keys are found.

Basically, instead of using the hash of the passphrase up front, you do a PRNG
expansion of the passphrase.  For example,
k_1 = hash(1||passphrase)
k_2 = hash(2||passphrase)

and so on.

The important thing here is that it is not something like the following:

k_1 = hash(passphrase)
k_2 = hash(k_1)
...
k_n = hash(k_(n-1)

In that method, the number of input states is limited by the hash size, whereas
the former algorithm has a number of states that the k sequence can be in
is limited by the size of the passphrase.  I suppose that a running hash
would be limited by the size of the hash state (chaining variables).

Next you construct k = k_1 || k_2 || ... k_n

The computation can be done incrementally on an as-needed basis.

Then, you read in the number of weak keys, and perform a random selection
on the number of valid keys using the algorithm I posted earlier, with k as
the source of unpredictability.  This leaves you with a random number between
0 and the number of non-weak keys minus one.  Then you iterate over the weak
keys in numerical order, incrementing the value from the previous step
by one if it exceeds the weak key's numerical value.  This part runs in
time linear with the number of weak keys, not the size of the non-weak keyspace.

You are left with a value that has a uniform distribution over the
non-weak keys.

The random selection algorithm may run indefinitely, but the chances of
that are infinitesimal.  If there are a huge number of weak keys, then it
may take longer, but I'd be willing to bet that CPU speed increases faster
than discovery of weak keys, and if it doesn't the user might be
inconvenienced enough to upgrade to a less broken cipher algorithm.
--
The obvious mathematical breakthrough would be the development of an
easy way to factor large prime numbers.'' [sic] -- Bill Gates  --
URL:http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-10 Thread Brian Gladman
Adam Back wrote:

 So the part about being able to detect viruses, trojans and attest
 them between client-server apps that the client and server have a
 mutual interest to secure is fine and good.
 
 The bad part is that the user is not given control to modify the hash
 and attest as if it were the original so that he can insert his own
 code, debug, modify etc.
 
 (All that is needed is a debug option in the BIOS to do this that only
 the user can change, via BIOS setup.)

I haven't been keeping up to date with this trusted computing stuff over
the last two years but when I was last involved it was accepted that it
was vital that the owner of a machine (not necessarily the user) should
be able to do the sort of things you suggest and also be able to exert
ultimate control over how a computing system presents itself to the
outside world.

Only in this way can we undermine the treacherous computing model of
trusted machines with untrusted owners and replace it with a model in
which trust in this machine requires trust in its owner on which real
information security ultimately depends (I might add that even this
model has serious potential problems when most machine owners do not
understand security).

Does anyone know the current state of affairs on this issue within the
Trusted Computing Group (and the marketed products of its members)?

   Brian Gladman


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]