what's wrong with HMAC?

2006-05-01 Thread Travis H.
Ross Anderson once said cryptically, HMAC has a long story attched to it - the triumph of the theory community over common sense He wouldn't expand on that any more... does anyone have an idea of what he is referring to? -- "Curiousity killed the cat, but for a while I was a suspect" -- Steven

Re: encrypted file system issues (was Re: PGP "master keys")

2006-05-01 Thread Travis H.
On 5/1/06, Perry E. Metzger <[EMAIL PROTECTED]> wrote: Not if you design it correctly. Disk encryption systems like CGD work on the block level, and do not propagate CBC operations across blocks, So is it vulnerable to any of the attacks here? http://clemens.endorphin.org/LinuxHDEncSettings I

Re: PGP "master keys"

2006-05-01 Thread Travis H.
On 29 Apr 2006 02:00:18 -, StealthMonger <[EMAIL PROTECTED]> wrote: Interesting epilog: theregister has apparently now edited out all mention of master keys. They probably had their misunderstanding pointed out to them by countless people by now. But... did anyone else note the phrasing of

non-cartesian A codes and latin squares

2006-04-30 Thread Travis H.
Background: An A-code is a matrix E x M, where e is the encoding rule used, and m is the message the transmitter should send (output). The message to be authenticated (input) is s in { s_1 .. s_k }, and the contents of the matrix are members of such that every row (encoding rule) contains s_1..

non-cartesian A codes

2006-04-17 Thread Travis H.
Hi, does anyone have a web reference on how to construct matrices for non-cartesian A codes a la Simmons? I see descriptions of what they should look like, but no algorithms for creating them. -- "Curiousity killed the cat, but for a while I was a suspect" -- Steven Wright Security Guru for Hire h

excellent wifi security page

2006-04-13 Thread Travis H.
http://www.drizzle.com/~aboba/IEEE/ -- "Curiousity killed the cat, but for a while I was a suspect" -- Steven Wright Security Guru for Hire http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 -

is breaking RSA at least as hard as factoring or vice-versa?

2006-04-02 Thread Travis H.
So I'm reading up on unconditionally secure authentication in Simmon's "Contemporary Cryptology", and he points out that with RSA, given d, you could calculate e (remember, this is authentication not encryption) if you could factor n, which relates the two. However, the implication is in the less

Re: Linux RNG paper

2006-03-23 Thread Travis H.
I have examined the LRNG paper and have a few comments. CC'd to the authors so mind the followups. 1) In the paper, he mentions that the state file could be altered by an attacker, and then he'd know the state when it first came up. Of course, if he could do that, he could simply install a troja

passphrases with more than 160 bits of entropy

2006-03-21 Thread Travis H.
Hi, Does anyone have a good idea on how to OWF passphrases without reducing them to lower entropy counts? That is, I've seen systems which hash the passphrase then use a PRF to expand the result --- I don't want to do that. I want to have more than 160 bits of entropy involved. I was thinking t

pipad, was Re: bounded storage model - why is R organized as 2-d array?

2006-03-20 Thread Travis H.
Anyone see a reason why the digits of Pi wouldn't form an excellent public large (infinite, actually) string of "random" bits? There's even an efficient digit-extraction (a/k/a "random access to fractional bits") formula, conveniently base 16: http://mathworld.wolfram.com/BBPFormula.html I dub th

bounded storage model - why is R organized as 2-d array?

2006-03-08 Thread Travis H.
Hey, In Maurer's paper, which is the last link here on the following page, he proposes to use a public random "pad" to encrypt the plaintext based on bits selected by a key. What I'm wondering is why he chose the strange construction for encryption; namely, that he uses an additive (mod 2) cipher

bulk quantum computation

2006-03-08 Thread Travis H.
Here's a 1997 paper on "quantum computing in the large" that I had been asking about: http://www.media.mit.edu/physics/projects/spins/home.html "Neil Gershenfeld and Isaac Chuang have developed an entirely new approach to quantum computation that promises to solve many of these problems. Instead

Re: hamachi p2p vpn nat-friendly protocol details

2006-02-26 Thread Travis H.
On 2/24/06, Alex Pankratov <[EMAIL PROTECTED]> wrote: > Tero Kivinen wrote: > >> Secondly I cannot find where it > >> authenticates the crypto suite used at all (it is not included in the > >> signature of the AUTH message). > > Crypto suite is essentially just a protocol number. It requires > no a

Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-02-24 Thread Travis H.
On 2/23/06, Ed Gerck <[EMAIL PROTECTED]> wrote: > Usability should by now be recognized as the key issue for security - > namely, if users can't use it, it doesn't actually work. There was an informative study on the usability of PGP, here if you haven't seen it: http://www.gaudior.net/alma/johnny

hamachi p2p vpn nat-friendly protocol details

2006-02-23 Thread Travis H.
http://www.hamachi.cc/security Based on a cursory look over this, I'm impressed by both the level of detail and the level of security apparently afforded. Too bad I can't see the source code. -- Security Guru for Hire http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 9D3F 395A DAC5 5C

choosing building blocks, was Re: general defensive crypto coding principles

2006-02-14 Thread Travis H.
On 2/13/06, Peter Gutmann <[EMAIL PROTECTED]> wrote: > >I would expect that typically implementors would be following a published > >standard, which would (well, one would hope) have had expert cryptographers > >check it over sometime prior to publication Published implementations aren't immune to

Re: general defensive crypto coding principles

2006-02-11 Thread Travis H.
On 2/8/06, Jack Lloyd <[EMAIL PROTECTED]> wrote: > An obvious example occurs when using a > deterministic authentication scheme like HMAC - an attacker can with high > probability detect duplicate plaintexts by looking for identical tags. I think though that the solution is fairly simple; prepend

general defensive crypto coding principles

2006-02-08 Thread Travis H.
Hey, In "Practical Cryptography", Schneier mentions a couple of general principles that he thinks wise when writing code which uses or implements cryptographic routines. Bear with me as I try to remember them: 1) When using a user input, run it through a OWF first. NB: This is a possible DoS ve

Re: thoughts on one time pads

2006-02-08 Thread Travis H.
If anyone is interested in participating in the design of a system that could be used for manual key distribution and/or OTP purposes, email me. I figure we can talk about our special cases off-list, and maybe submit the final design to the list for people to take their best crack at it. -- "Whoso

Re: EDP (entropy distribution protocol), userland PRNG design

2006-02-04 Thread Travis H.
Assume that one is the sole user of a LAN and that the 10-20 machines on this network have a need for unpredictable numbers. Assume further that it is not cost-effective to furnish each with a HWRNG, even one as inexpensive as a sound card (for example, they may not have a spare slot on the mother

methods of filling encrypted disks

2006-02-04 Thread Travis H.
So on this page: http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedDevice there is a suggestion that people fill the encrypted image of a dm-crypt target with random data. Why? I assume this is because making the filesystem on the unencrypted (upper) layer will only write to a small porti

Re: serious threat models

2006-02-04 Thread Travis H.
On 2/3/06, Jaap-Henk Hoepman <[EMAIL PROTECTED]> wrote: > could this be > done using phone conference facilities? Good guess! http://www.schneier.com/blog/archives/2006/02/phone_tapping_i.html ``The code tapped into the conference call system. It "conference called" phone calls to 14 prepaid mob

Hiding data on 3.5" using "40 track mode"

2006-02-04 Thread Travis H.
In the FBI's public statement about Hannsen, they relate how he used a 3.5" floppy in "40 track mode" to store data, but if it was read in the ordinay way it would appear blank. IIRC, high-density floppies are 80 tracks per inch, and double density were 40 tpi. So, how do you suppose this trick w

Re: Unforgeable dialog.

2006-02-03 Thread Travis H.
In one environment I worked in, it was important that people know what kind of data they were looking at. The way they solved it was to put a green colored border and label on one kind of data, and a red border and different label on another kind of data. This reduces usable screen area a bit, bu

CD shredders, was Re: thoughts on one time pads

2006-02-01 Thread Travis H.
On 1/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > In our office, we have a shredder that happily > takes CDs and is designed to do so. It is noisy > and cost >$500. Here's one for $40, although it doesn't appear to "shred" them so much as make them pitted: http://www.thinkgeek.com/gadge

Re: thoughts on one time pads

2006-01-28 Thread Travis H.
> There are various versions of getting rid of a disk file. > 2) Zeroizing the blocks in place (followed by deletion). This >is vastly better, but still not entirely secure, because there >are typically stray remnants of the pattern sitting "beside" >the nominal track, and a sufficie

Re: thoughts on one time pads

2006-01-27 Thread Travis H.
> I think that's because you missed the point. You're confusing manual > key distribution (which makes sense in some cases, but is unworkable > in others) with using a one-time pad (a specific method of encrypting > information that uses up key material very fast but has a security > proof). Actu

a crypto wiki

2006-01-26 Thread Travis H.
http://www.cryptodox.com/Main_Page -- "The generation of random numbers is too important to be left to chance." -- Robert Coveyou -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B -

thoughts on one time pads

2006-01-26 Thread Travis H.
In this article, Bruce Schneier argues against the practicality of a one-time pad: http://www.schneier.com/crypto-gram-0210.html#7 I take issue with some of the assumptions raised there. For example, you may have occasional physical meetings with a good friend, colleague, family member, or forme

Re: quantum chip built

2006-01-19 Thread Travis H.
I'm fairly ignorant of quantum computers, having had the opportunity to see Schor lecture at a local university but unfortunately finding myself quickly out of my depth (I still don't understand the weird notation they use for representing [superpositions of?] "states" in Bell inequalities and his

Re: Echelon papers leaked

2006-01-18 Thread Travis H.
Two chapters are online here: http://www.fas.org/irp/eprint/sp/ -- "If I could remember the names of these particles, I would have been a botanist" -- Enrico Fermi -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B ---

Re: long-term GPG signing key

2006-01-13 Thread Travis H.
I must admit, I just had a "duh" moment. Why the heck am I expiring encryption keys each year? Anyone who records the email can crack it even if the key is invalid by then. All it really does is crudely limit the quantity of data sent under that key, which is little to none anyway. *bonks foreh

Re: long-term GPG signing key

2006-01-11 Thread Travis H.
On 1/10/06, Ian G <[EMAIL PROTECTED]> wrote: > 2. DSA has a problem, it relies on a 160 > bit hash, which is for most purposes the > SHA-1 hash. Upgrading the crypto to cope > with current hash circumstances is not > worthwhile; we currently are waiting on > NIST to lead review in hashes so as to

Re: phone records for sale.

2006-01-10 Thread Travis H.
You can get records of most kinds from various private investigators and data brokers for a fee. I first found out about this in the mid-90s, but I'm sure they existed before that. Where the data collection is illegal, the reputable firms assure you that they are not doing anything illegal, which

long-term GPG signing key

2006-01-10 Thread Travis H.
I'd like to make a long-term key for signing communication keys using GPG and I'm wondering what the current recommendation is for such. I remember a problem with Elgamal signing keys and I'm under the impression that the 1024 bit strength provided by p in the DSA is not sufficiently strong when c

new openssh directions

2005-12-28 Thread Travis H.
Interview with OpenSSH developer: http://www.securityfocus.com/columnists/375 Summary: Arbitrary layer 2/3 tunnelling using tun(4) interfaces over ssh. Various changes to reduce attack possibilities. My first encounter with the term "attack surface". Commentary: TCP over TCP --- retransmit tim

Re: another feature RNGs could provide

2005-12-27 Thread Travis H.
On 12/26/05, Ben Laurie <[EMAIL PROTECTED]> wrote: > Surely if you do this, then there's a meet-in-the middle attack: for a > plaintext/ciphertext pair, P, C, I choose random keys to encrypt P and > decrypt C. If E_A(P)=D_B(C), then your key was A.B, which reduces the > strength of your cipher from

Re: RNG quality verification

2005-12-27 Thread Travis H.
On 12/23/05, Philipp Gühring <[EMAIL PROTECTED]> wrote: > It´s easy to say that it´s their responsibility. > But how should they do it? Very carefully. Picking random numbers is far too important to be left to chance. -- http://www.lightconsulting.com/~travis/ "Vast emptiness, nothing sacred." --

Re: RNG quality verification

2005-12-22 Thread Travis H.
On 12/22/05, Philipp Gühring <[EMAIL PROTECTED]> wrote: > So if I extract the key, remove the first and the last bit, then I should have > the pure random numbers that are being used. If I do that with lots of keys, > I should have a good amount of random material for the usual statistical > tests.

Re: another feature RNGs could provide

2005-12-22 Thread Travis H.
On 12/21/05, Perry E. Metzger <[EMAIL PROTECTED]> wrote: > > Good ciphers aren't permutations, though, are they? Because if they > > were, they'd be groups, and that would be bad. > > Actually, by definition, a cipher should be a permutation from the set > of plaintexts to the set of ciphertexts. I

whoops (residues in a finite field)

2005-12-19 Thread Travis H.
Schneier mentions whooping values (whoops? I don't know the precise term) in doing modular arithmetic. I was wondering what people thought of this. Basically if you've got a huge finite field, and do arithmetic on it, the whoop values are the residues in a much smaller field that is unknown to t

Re: crypto for the average programmer

2005-12-19 Thread Travis H.
On 12/19/05, Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> wrote: > unsigned char foo[8]; > > (no, it isn't fool proof, but close enough after 1 second of thought). I think C guarantees that a char is a byte, but exactly how wide that is is processor-dependent. IIRC, some of the machines it w

Re: crypto for the average programmer

2005-12-19 Thread Travis H.
On 12/19/05, Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> wrote: > C has three really strong points: > > - portability. It's one of the most wide-spread and portable > compiled languages that I know of. I beg your pardon? If I want to store 128 bits of information, and access the 8 most

Re: Crypto and UI issues

2005-12-19 Thread Travis H.
On 12/18/05, Ben Laurie <[EMAIL PROTECTED]> wrote: > > It would happen at least as much as it happens with > > https, and it happens enough with https that false > > negatives enormously outweigh true negatives. > > True, but I don't see false negatives very often with https at all. And > I visit f

Re: crypto for the average programmer

2005-12-18 Thread Travis H.
Anytime someone wants to rewrite a C library in a language less prone to buffer overflows, I'm totally for it. Some say that "it's not the library, it's the programmer", but I think that denies human factors. C simply requires too much machinery on top of it to use it securely. It is possible to

Re: crypto for the average programmer

2005-12-14 Thread Travis H.
On 12/14/05, Peter Gutmann <[EMAIL PROTECTED]> wrote: > I don't know if there's any site tracking this, but (as the tutorial says) you > can either go with PKCS #1 (the de facto standard, easy to implement and > widely used) ... Actually, I'm embarassed to admit this but I've seen PKCS before but

Re: secure links using classical (i.e., non-quantum) physics

2005-12-14 Thread Travis H.
I am discussing implementing a very simple version of this with the author. If anyone else is interested in participating or just watching, email me and I'll keep you in the loop. -- http://www.lightconsulting.com/~travis/ -><- P=NP if (P=0 or N=1) "My love for mathematics is like 1/x as x approa

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-12 Thread Travis H.
Not to side track the discussion, but frequently I've heard PKI compared to PGP's model. Isn't PGP's trust model the same as everyone being their own CA? I find PGP to be problematic. Many keys I see are only self-signed, and this includes important keys like CERT. Many others sit unsigned on t

crypto wiki -- good idea, bad idea?

2005-12-12 Thread Travis H.
Seems like a lot of new folks (myself included) ask questions that have the following answer: Read the literature, no there's no one site, that would be too much effort, &c. Would a wiki specifically for crypto distribute the burden enough to be useful? Or should we just stick to wikipedia? Is i

crypto for the average programmer

2005-12-12 Thread Travis H.
In Peter Gutmann's godzilla cryptography tutorial, he has some really good (though terse) advice on subtle gotchas in using DH/RSA/Elgamal. I learned a few no-nos, such as not sending the same message to 3 seperate users in RSA (if using 3 as an encryption exponent). My question is, what is the l

another feature RNGs could provide

2005-12-12 Thread Travis H.
One thing I haven't seen from a PRNG or HWRNG library or device is an unpredictable sequence which does not repeat; in other words, a [cryptographically strong?] permutation. This could be useful in all sorts of places in the kernel and elsewhere to prevent replay (for example, in DNS ID #s, in ch

Re: [Clips] Engineer Outwits Fingerprint Recognition Devices with Play-Doh

2005-12-12 Thread Travis H.
A recent magazine article suggested a spoofing technique involving wrapping one's finger with a few layers of cellophane; the latent print on the reader apparently is visible enough to be reused in this manner, at least with some currently-available scanners. -- http://www.lightconsulting.com/~trav

Re: [Clips] Diebold insider alleges company plagued by technical woes

2005-12-08 Thread Travis H.
Does anyone here have any links to voting system designs that use cryptography to achieve their goals? I'm curious what could be achieved in that direction. -- http://www.lightconsulting.com/~travis/ -><- Knight of the Lambda Calculus "We already have enough fast, insecure systems." -- Schneier &

Re: Proving the randomness of a random number generator?

2005-12-05 Thread Travis H.
On 12/4/05, Victor Duchovni <[EMAIL PROTECTED]> wrote: > Wrong threat model. The OP asked whether the system generating random > numbers can prove them to have been "randomly" generating to a passive > observer. I didn't read it that way, but the question wasn't particularly well-formed. I'm not s

RNG implementations and their problems

2005-12-04 Thread Travis H.
I'm dissatisfied with the state of /dev/random devices on Unix. Here are my gripes: So far I haven't seen any userland tools for updating the entropy count. This is unfortunate, because sometimes I generate entropy on one machine and want to pipe it into the /dev/random pool. However, I cannot

Re: Proving the randomness of a random number generator?

2005-12-04 Thread Travis H.
On 12/3/05, Victor Duchovni <[EMAIL PROTECTED]> wrote: > Actually, this is inaccurate, proving the strength of AES or factoring is > difficult, and may never happen, we may even prove AES to be not secure > (in a broad sense) some day. Proving an RNG secure is *impossible*. I'm not sure it's impos

Re: Haskell crypto

2005-12-02 Thread Travis H.
> IMO it is pointless to > write SHA in a language that ``can have properties of programs > proved,'' because test vectors are good enough, and there is no real > assurance that when you write the specification in a machine-readable > form you do not make the same mistake as in your code. I think

security modifications to current PCs

2005-12-02 Thread Travis H.
Hey, I've been reading through the TCPA documents and thinking a bit about changes that might give higher assurance to an ordinary PC, or at least a PC with only minor changes. Specifically, one of the things I've always been mulling over is a secure boot sequence. Basically, like the TCPA, I wa

Re: timing attack countermeasures (nonrandom but unpredictable de lays)

2005-11-30 Thread Travis H.
> Why do you need to separate f from f+d? The attack is based on a timing > variation that is a function of k and x, that's all. Think of it this way: > Your implementation with the new d(k,x) added in is indistinguishable, in > externally visible behavior, from a *different* implementation f'(k,

Re: timing attack countermeasures (nonrandom but unpredictable delays)

2005-11-30 Thread Travis H.
Good points all. I was implicitly assuming that d(k, x) is related to the timing of f(k,x) -- tailored to the algorithm(s) used, and that the attacker cannot control k. Actually the idea was to have k merely provide a unique function d_k(x) for each host. > The only way to avoid this is to make

Re: timing attack countermeasures (nonrandom but unpredictable delays)

2005-11-17 Thread Travis H.
> In many cases, the observed time depends both on the input and on some > other random noise. In such cases, averaging attacks that use the same > input over and over again will continue to work, despite the use of > a pseudorandom input-dependent delay. For instance, think of a timing > attack

solving, simplification and factorization of boolean equations

2005-11-17 Thread Travis H.
Does anyone have any references on how one would go about creating manipulating the boolean equations that govern symmetric ciphers? I know that most of the time ciphers describe an algorithm, often using tables (S-boxes and E-tables) in lieu of providing equations, and I'm wondering how one goes

Re: the effects of a spy

2005-11-17 Thread Travis H.
> actually justified for cryptosystems: It turned out, on the key escrow side > of the protocol design, NSA actually fell over the edge, and there was a > simple attack (Matt Blaze's work, as I recall). Details on the so-called LEAF blower here: http://www.crypto.com/papers/eesproto.pdf -- http:/

timing attack countermeasures (nonrandom but unpredictable delays)

2005-11-15 Thread Travis H.
The naive countermeasure to timing attacks is to add a random delay, but of course that can be averaged out by repeating the computation. I have never heard anyone propose a delay that is based on the input, and maybe some per-machine secret, so that it is unpredictable but constant. Of course th

Re: Pseudorandom Number Generator in Ansi X9.17

2005-11-15 Thread Travis H.
In Practical Cryptography, Schneier discusses a new PRNG design called Fortuna. It has some neat features. He also discusses problems with the ANSI PRNG here: http://www.schneier.com/paper-prngs.html -- http://www.lightconsulting.com/~travis/ -><- "We already have enough fast, insecure systems.

Re: On Digital Cash-like Payment Systems

2005-11-14 Thread Travis H.
> Don't ever encrypt the same message twice that way, or you're likely to > fall to a common modulus attack, I believe. Looks like it (common modulus attack involves same n, different (e,d) pairs). However, you're likely to be picking a random symmetric key as the "message", and Schneier even sug

Re: Fermat's primality test vs. Miller-Rabin

2005-11-14 Thread Travis H.
> > Although the Carmichael numbers fool the Fermat test > > (that is, $a^{n-1} = 1 (n)$) for *all* a, I thought it would work properly if a shares a factor with n. > Yes I guess the difference is that with MR you are trying to find a > number that is *likely* a prime, whereas with Fermat you are

Re: gonzo cryptography; how would you improve existing cryptosystems?

2005-11-08 Thread Travis H.
> Nice, but linux-only and requires special kernel support. cfs supports > lots and lots of different OSs and doesn't require kernel modes. So far > as I know, in this regard cfs is unique among cryptographic filesystems. The only thing close that I've seen is Bestcrypt, which is commercial and

Fermat's primality test vs. Miller-Rabin

2005-11-08 Thread Travis H.
In "Practical Cryptography", Schneier states that the you can prove that when n is not a prime, a certain property of a mod n holds for at most 25% of possible values 1 < a < n. He later states that Fermat's test can be fooled by Carmichael numbers, and finally he basically says that Miller-Rabin

Re: On the orthogonality of anonymity to current market demand

2005-11-07 Thread Travis H.
I'd recommend DRM (I think what you really mean is Palladium, err, excuse me, the Trusted Computing Platform Alliance, see the web site and Ross Anderson's take on it) to my grandmother, because I don't trust her to understand the implications of clicking on something in an email (thank you active

Re: gonzo cryptography; how would you improve existing cryptosystems?

2005-11-07 Thread Travis H.
> Does ISAKMP do encryption where the input is > meant to be secret, instead of the key? I meant MAC, not encryption, sorry. Of course encryption inputs are secret. -- http://www.lightconsulting.com/~travis/ -><- "We already have enough fast, insecure systems." -- Schneier & Ferguson GPG fingerpr

gonzo cryptography; how would you improve existing cryptosystems?

2005-11-07 Thread Travis H.
Hi folks, If one had the ability to create standards over, with reckless disregard for performance, how would you improve their security? Feel free to pick a protocol or system (e.g. gpg or isakmp) and let me know how it is done, and how it should have been done. For example, pgp doesn't hide th

Re: On Digital Cash-like Payment Systems

2005-11-07 Thread Travis H.
By my calculations, it looks like you could take a keypair n,e,d and some integer x and let e'=e^x and d'=d^x, and RSA would still work, albeit slowly. Reminds me of blinding, to some extent, except we're working with key material and not plaintext/ciphertext. Since I'm on the topic, does doing e

Re: Symmetric ciphers as hash functions

2005-11-03 Thread Travis H.
> Not so... the SHA family are all unbalanced Feistel structures. Sorry, I guess I am thinking of AES. I don't know where I got the "doesn't need to be invertible" bit, I must be conflating it with something else. He should also take a look at OCB, CCM, and CBC-MAC modes. Perhaps he intends to h

Re: Symmetric ciphers as hash functions

2005-11-01 Thread Travis H.
> How does one properly use a symmetric cipher as a cryptographic hash > function? I seem to be going around in circles. Isn't this is like asking a mechanic how to use a screwdriver as a hammer? > Reversing the situation (using the data as the key and a known plain- > text) makes a plaintext att

Re: NY Times reports: NSA falsified Gulf of Tonkin intercepts

2005-11-01 Thread Travis H.
For anyone interested in more details, Daniel Ellsberg's book "Secrets" deals with the content of the cables coming in in real-time during this incident. They dispell any certainty about the attacks actually happening the way they were officially reported. The picture it paints is a very confused

Re: packet traffic analysis

2005-10-31 Thread Travis H.
> I assume that the length is > explicitly encoded in the legitimate packet. Then the peer for the > link ignores everything until the next "escape sequence" introducing a > legitimate packet. I should point out that encrypting PRNG output may be pointless, and perhaps one optimization is to stop

Re: packet traffic analysis

2005-10-31 Thread Travis H.
Good catch on the encryption. I feel silly for not thinking of it. > If your plaintext consists primarily of small packets, you should set the MTU > of the transporter to be small. This will cause fragmentation of the > large packets, which is the price you have to pay. Conversely, if your > p

Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

2005-10-26 Thread Travis H.
> If you have > to be that confident in your computer security to use the payment > system, it's not going to have many clients. Maybe the trusted computing platform (palladium) may have something to offer after all, namely enabling naive users to use services that require confidence in their own

Re: [PracticalSecurity] Anonymity - great technology but hardly used

2005-10-26 Thread Travis H.
Part of the problem is using a packet-switched network; if we had circuit-based, then thwarting traffic analysis is easy; you just fill the link with random garbage when not transmitting packets. I considered doing this with SLIP back before broadband (back when my friend was my ISP). There are t

semi-preditcable OTPs

2005-10-25 Thread Travis H.
I recall reading somewhere that the NSA got ahold of some KGB numeric OTPs (in the standard five-digit groups). They found that they contained corrections, typos, and showed definite non-random characteristics. Specifically, they had a definite left-hand right-hand alternation, and tended to not

Re: EDP (entropy distribution protocol), userland PRNG design

2005-10-24 Thread Travis H.
> I can't say I a fan of the idea of having multiple ways of mixing entropy into > the system. In particular, the idea of producing output by XORing your PRNGs > output with the output of a semi-public RNG seems like a bad idea to me, > because an attacker can easily control those values by taking

Re: [EMAIL PROTECTED]: Skype security evaluation]

2005-10-24 Thread Travis H.
That's a fairly interesting review, and Skype should be commended for hiring someone to do it. I hope to see more evaluations from vendors in the future. However, I have a couple of suggestions. My understanding of the peer-to-peer key agreement protocol (hereafter p2pka) is based on section 3.3

Re: [Clips] Read two biometrics, get worse results - how it works

2005-10-21 Thread Travis H.
This problem has implications for "sensor fusion" (the latest hot topic) in IDS; for example when combining host logs (HIDS) with NIDS alerts. The risk of false positives is particularly relevant when you try to write signatures that match similar but unknown bad stuff, and false negatives when de

Re: EDP (entropy distribution protocol), userland PRNG design

2005-10-19 Thread Travis H.
On 10/18/05, Jack Lloyd <[EMAIL PROTECTED]> wrote: > Peter Gutmann has several good papers on RNG design, as have some folks > currently or formerly associated with Counterpane (ie Wagner, Kelsey, Hall, > ...). It is worth reading their analysis papers as well as their design > papers, > especiall

SecurID and garage door openers

2005-10-18 Thread Travis H.
Speaking of two-factor authentication, can anyone explain how servers validate the code from a SecurID token in the presence of clockskew? Does it look backwards and forwards in time a few minutes? Similarly, how do those garage door openers with "rolling codes" work, given that the user may have

Re: EDP (entropy distribution protocol), userland PRNG design

2005-10-18 Thread Travis H.
> I can't say I a fan of the idea of having multiple ways of mixing entropy into > the system. In particular, the idea of producing output by XORing your PRNGs > output with the output of a semi-public RNG seems like a bad idea to me, > because an attacker can easily control those values by taking

Re: Venona not all decrypted?

2005-10-12 Thread Travis H.
When they re-used the codebooks, you can assume that they did so until they got new codebooks, so I don't think such places should be so hard to identify. I think the problem is that once you've detected pad re-use, you have two plaintexts added (XORed) together. I don't know of an algorithm that

EDP (entropy distribution protocol), userland PRNG design

2005-10-12 Thread Travis H.
I am thinking of making a userland entropy distribution system, so that expensive HWRNGs may be shared securely amongst several machines. Here's the algorithm from generation to use: 1) Entropy harvested from HWRNG. 2) Entropy mixed with PRNG output to disguise any biases present in source. The

<    1   2