Re: [IP] Master Key Copying Revealed (Matt Blaze of ATT Labs)
On 2003-01-24, Len Sassaman uttered to Arnold G. Reinhold: >(This is a purely physical limitation. If you had pins that were of >drastically different heights next to each other, key insertion would be >extremely difficult or impossible.) One should also note that this particular problem doesn't affect disc wafer designs, like ABLOY's. On other fronts such designs fail as badly as pin tumbler one, of course. I don't know about the newer designs, though -- it seems the basic design allows an affordable analog to double cylinder keying, which doesn't leak as much information. As Matt notes, such designs have other vulnerabilities, especially when somebody dismantles the lock itself. The next logical question is, are there ways of making locks more secure, starting from cryptanalytic principles? As far as information leakage goes, the problem is easily corrected by going to double ring designs or the applicable analogs. From the standpoint of reverse engineering, it seems we're off into the domain of mechanical computing or wishful fancy, depending on one's personal level of optimism. That means high security mechanical lock makers might have to suffer a flashback into Babbage's age. How's that for retro? ;) (Okay, they're going for infrared keys and/or RFID, now. That's about challenge-response, public keys and tamper resistance. I wonder if the lock community has recognized the inevitable link to what crypto people are doing...) >Heck, it's possible to construct a set of all possible *keys* for a given >lock. Even with the optimizations of knowing which pin combinations are >physically impossible to use, however, this is still a lot of >combinations. Sure. But trying those combinations out can be automated -- I don't think the kind of automatic lock pickers one sees in current action movies are *entirely* fictional. Rotational shear dictates that the key channel of every normal lock must have a certain minimum cross-section, given a material for the key. If you think about how long a lock cylinder can be in common applications, one has a whole lot of room for all sorts of mechanics within the space alloted for the key in a working lock. It might even be the length of the cylinder is strictly limited by rotational shear concerns. My first take on designing an automated probe would simply be to apply rotational noise to the lock, record the vibration coming back, while sliding a probe through the cylinder. When each disc/pin is pushed into the free position, one would expect it to be exceedingly difficult to hide changes such a match will cause in the response of the signal chain. >Most of the time, the lock is not the weakest point of attack. Naturally. I think both Matt and those interested in locks on-list primarily consider this a funky excercise in what I'd call far-too-applied cryptanalysis. >Attacking the lock in this manner is analogous to breaking a >crypto-system by attacking the cipher. Usually, other parts of the >implementation are much weaker. Yes. I say, jump the threat model. Ram a car through the door or arrange to deliver a promotional pizza to someone behind it, whichever feels more comfortable. I also think ideas like these can serve as *wonderful* examples of why threat models matter in security design -- like Matt says, locks often serve as a useful analogy to how crypto works. >If you have a location which is secured in such a manner that the lock's >security is of concern, you should look into a lock such as Medeco, which >employs a number of security features which resist these attacks. (Angled >cuts, restricted key blanks, etc.) I would equate the latter with both security-thru-obscurity, and purely legislative approaches to security. That is, I wouldn't lay a lot of weight on them. The former, that I've already found a minor complication. >(On another list, I joked that if Matt could get his technique to work on >a Medeco master-keyed system by July, I'd eat a pound of live crickets at >DEFCON. I'll hold myself to that.) That's the spirit. I wouldn't exactly go with the live stuff, but otherwise crickets sound simply nutritious. Not to mention delicious, after having been dipped in honey. ;) Seriously, I cannot really see why the approach wouldn't work on Medeco's rotating pin design as well. It certainly seems more complicated than a typical pin tumbler one, and it does add to the total number of key combinations, but in the end, I would suspect it succumbs to an attack with the same complexity measure as Matt's more conventional ones. I don't have the precise details, but I would suspect rotational positions simply Cartesian the search space, nothing more. Getting it to work in actuality might be a bit of a problem, especially with Matt's expected budget, but for those who actually wa
Re: Real-world steganography
On 2002-10-01, Ben Laurie uttered to Peter Gutmann: >Yeah, right - and green felt-tip around the edges of your CD improves >the sound, too. I'm not sure about HDCD as a technology, but the principle is sound. If we can compress sound transparently, we can also transparently embed quite a lot of data into the part which is perceptually irrelevant. We might also depart with perceptual equivalence and go with perceptual similarity instead -- e.g. multiband compress the audio, and embed data which allows us to expand to a higher perceptual resolution. Whatever the implementation, putting data in the gap between statistical (i.e. computed against a Markov model) and perceptual (against a perceptual similarity model) entropy which compensates for some of the perceptual shortcomings (like total dynamic range) of a particular recording technology seems like an excellent idea. However, applications like these have very little to do with steganography proper. In this case, we can (and want) to fill up the entire gap between statistical and perceptual entropy estimates with useful data, leaving us with signals which have statistical entropies consistently higher than we'd expect of a typical recording with similar perceptual characteristics. That is, the encoded signal will appear manifestly random compared to typical unencoded material from a similar source, and we can easily see there is hidden communication going on. Such encodings will be of little value in the context of industrial strength steganography used for hidden communication. Steganography used in the latter sense will also have to be imperceptible, true, but but here the entropic gap we're filling is the one between the entropy estimates of our best model of the source material vs. that of the adversary's. Be the models Markov ones, perceptual, something else, or composites of the above. Consequently the margin is much thinner (bandwidths are probably at least a decade or two lower), and the aims remain completely separate. Consequently, I don't believe encodings developed for the first purpose could ever be the best ones for the latter, or that HDCD-like endeavors really have that much to do with the subject matter of this list. -- Sampo Syreeni, aka decoy - mailto:[EMAIL PROTECTED], tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Challenge to David Wagner on TCPA
On 2002-08-01, AARG!Anonymous uttered to [EMAIL PROTECTED],...: >It does this by taking hashes of the software before transferring >control to it, and storing those hashes in its internal secure >registers. So, is there some sort of guarantee that the transfer of control won't be stopped by a check against cryptographic signature within the executable itself, in the future? That sort of thing would be trivial to enforce via licencing terms, after all, and would allow for the introduction of a strictly limited set of operating systems to which control would be transferred. I'm having a lot of trouble seeing the benefit in TCPA without such extra measures, given that open source software would likely evolve which circumvented any protection offered by the more open ended architecture you now describe. Such a development would simply mean that Peter's concern would be transferred a level up, without losing its relevance. I'd also contend that this extra level of diversion is precisely what TCPA, with its purported policy of "no trusted keys" aims at. >Then, when the data is decrypted and "unsealed", the hash is compared to >that which is in the TPM registers now. This can make it so that data >which is encrypted when software system X boots can only be decrypted >when that same software boots. Again, such values would be RE'd and reported by any sane open source OS to the circuitry, giving access to whatever data there is. If this is prevented, one can bootstrap an absolutely secure platform where whatever the content provider says is the Law, including a one where every piece of runnable OS software actually enforces the kind of control over permissible signatures Peter is so worried about. Where's the guarantee that this won't happen, one day? >In answer to your question, then, for most purposes, there is no signing >key that your TPM chip trusts, so the issue is moot. At the hardware level, yes. At the software one, it probably won't be, even in the presence of the above considerations. After you install your next Windows version, you will be tightly locked in with whatever M$ throws at you in their DLL's, and as I pointed out, there's absolutely no guarantee Linux et al. might well be shut out by extra features, in the future. In the end what we get is an architecture, which may not embody Peter's concerns right now, but which is built from the ground up to bring them into being, later. More generally, as long as we have computers which allow data to be addressed as code and vice versa, the ability to control use of data will necessarily entail ability to control use of code. So, either we will get systems where circumventing copyright controls is trivial or ones where you cannot compile your own code. All the rest is just meaningless syntax. In that light I bet you can guess why people are worried about TCPA and its ilk. -- Sampo Syreeni, aka decoy - mailto:[EMAIL PROTECTED], tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: building a true RNG
On 2002-07-28, Sampo Syreeni uttered to David Wagner: [Answering to my own mail. Sorry.] >and discard every 1/(p(x)-1/256)'th sample with value x. Actually the pedantic solution would be to put an arithmetic compressor/coder between the input and output, using the best model we've got. That still leaves model adaptation to be dealt with, but if we discard a sufficient number of output bits at start (estimable from the model), we *will* end up with (very nearly) flat statistics on the output. Asymptotic optimality and all that... (The qualification comes from limited precision arithmetic.) -- Sampo Syreeni, aka decoy - mailto:[EMAIL PROTECTED], tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: building a true RNG
On 2002-07-27, David Wagner uttered to Sampo Syreeni: >Just look at the first n bits of output; they are going to be a >deterministic function of the first n' bits of input, and we can simply >let f be the function mapping the first n' bits of input to the first n >bits of output. It's quite possible I don't get it in the finite case, but I don't see why you can do this either. With statistical adaptation the n on the output side will change based on the input stream, and |Y| cannot be both constant and finite. An example: presume we take a simple first order statistical model. If our input is an 8-bit sample value from a noise source, we will build a 256 bin histogram. When we see an input value, we look its probability up in the model, and discard every 1/(p(x)-1/256)'th sample with value x. When this happens, the sample is just eaten and nothing appears in the output; otherwise we copy. You *can* model this as a function from sequences to sequences, but certain input sequences (like repeated zeroes) will make the algorithm wait arbitrarily long before outputting anything. Hence, n on the output side cannot be finite. (This might "lose entropy" in our earlier, fuzzy sense, but it's near what I'm thinking. Once we discard the right samples, higher order models would work just as well.) -- Sampo Syreeni, aka decoy - mailto:[EMAIL PROTECTED], tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: building a true RNG
On 2002-07-27, David Wagner uttered to [EMAIL PROTECTED]: >In particular, there is no function f which doesn't waste entropy, >unless |Y|=1. The proof is simple enough that you can probably find it >with a moment's contemplation, but let me know if you want to see it. I would be lead to pigeonhole; still, this does seem like an eminently teachable moment to me. However, what we're working with in the case of a typical RNG isn't functions between finite buffer-fulls of data, but functions between infinite sets of entire bitstreams which need to be implemented within a finite memory constraint. Whatever the algorithm, it can have state. I'm thinking that is the reasoning which leads people to think that the problem is simple. In this framework one can very well gather statistics and try and normalize them based on what one's seen so far. (The minimalist example here is bias removal.) After that, what goes into the hash is (approximately) white and even with minimal assumptions (i.e. the hash is a one-way permutation) our RNG would seem to approach ideality. True, such an approach will always become a race in modelling the statistics. But still, I would think the generator has the advantage if sufficient margin is left for error. (That is, hash some constant times the number of bits containing the entropy you suspect to be there, based on the best model you've got.) -- Sampo Syreeni, aka decoy - mailto:[EMAIL PROTECTED], tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: FC: Politech challenge: Decode Al Qaeda stego-communications!
setting, neither does such a model exist nor do we have a guarantee that a specific method has indeed been used. We're left out in the cold, not knowing whether a communication has taken place. That, then, becomes both the beauty of steganography and the beast of inciting countless clueless reporters to suspect stego being present in places it isn't. If one cannot know, one cannot know. A number of reporters ought to be taught about knowable versus true/false if we're ever to get rid of this web-stego-osama-terrorism nonsense. Sampo Syreeni, aka decoy - mailto:[EMAIL PROTECTED], tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: FW: update.575
On Fri, 1 Feb 2002, Kossmann, Bill wrote: >The article below may be of interest to members of this list. [An article on categorizing textual strings by appending them on reference documents and measuring aggregate compressibility snipped.] This shouldn't be a big surprise, considering how close to the estimated entropy of various sources current compression algorithms get. In essence, compressors are statistical learners, and classification problems can be formulated as partitionings based on statistical similarity. I just wonder if the overhead of doing a significant number of compression runs against known sources isn't a bit expensive compared to current methods of identification. Sampo Syreeni, aka decoy - mailto:[EMAIL PROTECTED], tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: password-cracking by journalists...
On Thu, 17 Jan 2002, Steven M. Bellovin wrote: >For one thing, in Hebrew (and, I think, Arabic) vowels are not normally >written. If something, this would lead me to believe there is less redundancy in what *is* written, and so less possibility for a dictionary attack. >Also, there are a few Hebrew letters which have different forms when >they're the final letter in a word -- my understanding is that there are >more Arabic letters that have a different final form, and that some have >up to four forms: one initial, two middle, and one final. At least Unicode codes these as the same codepoint, and treats the different forms as glyph variants. Normalizing for these before the attack shouldn't be a big deal. >Finally, Hebrew (and, as someone else mentioned, Arabic) verbs have a >three-letter root form; many nouns are derived from this root. This would facilitate the attack, especially if the root form is all that is written -- it would lead us expect shorter passwords and a densely populated search space, with less possibility for easy variations like punctuation. Sampo Syreeni, aka decoy - mailto:[EMAIL PROTECTED], tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Best practices/HOWTO for key storage in small office/home office setting?
On Mon, 1 Oct 2001, Arnold G. Reinhold wrote: >Here are a few suggestions: > >o Use mini-CD-R's for key storage. There is even a rectangular, >credit-card sized format available. (Note that mini-CDs are not >compatible with slot loading CD drives.) I think one of those tiny USB flash memories IBM makes would be even better. Sufficient capacity, no moving parts, extremely discreet. >o Perform all encryption, signing, etc. on a lap top or palm top that is >kept in a safe or on your person when not in use and is never connected >to a network. Or integrate some computing power into those IBM thingies, and use remotely keyed encryption. Enough power is available through USB so that you don't have to end up with battery power. This isn't available now, though. I *really* hope IBM would take the hint. It would make key management a whole lot easier. Sampo Syreeni, aka decoy - mailto:[EMAIL PROTECTED], tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: "Pirate Utopia," FEED, February 20, 2001
On Mon, 24 Sep 2001, Ted Lemon wrote: >This presumes that people who use steganography in the real world right >now are similar in their password security habits to the general computer >user population. It also presumes that people use the precise same steganographic algorithm, I think. I've haven't seen the paper, though -- what's said there about the issue of multiple stego methods out there? Sampo Syreeni, aka decoy, mailto:[EMAIL PROTECTED], gsm: +358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
