Re: TPM & disk crypto
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]
handling weak keys using random selection and CSPRNGs
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 -><- 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
-- 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]
cryptography@metzdowd.com
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]
deriving multiple keys from one passphrase
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]
