Re: Did you *really* zeroize that key?
At 03:55 PM 11/7/02 +0100, Steven M. Bellovin wrote: Regardless of whether one uses volatile or a pragma, the basic point remains: cryptographic application writers have to be aware of what a clever compiler can do, so that they know to take countermeasures. Wouldn't a crypto coder be using paranoid-programming skills, like *checking* that the memory is actually zeroed? (Ie, read it back..) I suppose that caching could still deceive you though? I've read about some Olde Time programmers who, given flaky hardware (or maybe software), would do this in non-crypto but very important apps. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New Protection for 802.11
At 03:32 PM 11/6/02 -0500, Perry E. Metzger wrote: Does anyone know details of the new proposed protocols? Small article at: http://www.eetimes.com/story/OEG20021031S0007 Somewhere I read a larger article; things that stuck in memory are: No AES, a cipher called Michael being used; also, the change is intended to be a software-upgrade to existing devices, which is why so many features were omitted. There were also comments about legacy issues --you have to upgrade everyone, so its likely that back-compatibility will not completely obsolete wardriving. Much like Microsoft's OS-interop-legacy-security problems. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Optical analog computing?
At 11:25 PM 10/1/02 -0400, R. A. Hettinga wrote: I'm at a speech by Terry Essex, CTO of Essex Corp. He worked on optical computing at the NSA for a long time. the first computer to crack enigma was optical In one of the historical books about crypto, there's a method described involving punching hollerith cards, stacking them, and looking through the stack for shared holes. That would be a parallel optical NAND gate. (And Java compatible if you wipe up fast enough.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: unforgeable optical tokens?
At 12:07 PM 9/20/02 -0400, Perry E. Metzger wrote: A couple of places have reported on this: http://www.nature.com/nsu/020916/020916-15.html An idea from some folks at MIT apparently where a physical token consisting of a bunch of spheres embedded in epoxy is used as an access device by shining a laser through it. On the surface, this seems as silly as biometric authentication -- you can simply forge what the sensor is expecting even if you can't forge the token. Does anyone know any details about it? This kind of thing has been done as conformal coatings in nuke-tracking work. Also diamond-tracking. The idea is you have a complex, optically-coupled-state (metal flakes or spheres in clear paint/epoxy; crystal flaws) which you can read out but not duplicate. This kind of 'unduplicable' conformal coating may appear on US-bound Canadian trucks, too. Certify in the great white north, spray, measure, drive, re-measure, pass, look ma, no long lines at the border. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum computers inch closer?
At 08:56 PM 8/30/02 -0700, AARG!Anonymous wrote: Bear writes: In this case you'd need to set up the wires-and-gates model in the QC for two ciphertext blocks, each attached to an identical plaintext-recognizer function and attached to the same key register. Then you set up the entangled state, and collapse the eigenvector on the eigenstate where the ciphertext for block A and block B is produced, and the plaintext recognizer for both block A and block B return 1, and then you'd read the plaintext and key out of the appropriate locations (dots?) in the qchip. The problem is that you can't forcibly collapse the state vector into your wished-for eigenstate, the one where the plaintext recognizer returns a 1. Instead, it will collapse into a random state, associated with a random key, and it is overwhelmingly likely that this key is one for which the recognizer returns 0. I thought the whole point of quantum-computer design is to build systems where you *do* impose your arbitrary constraints on the system. The whole difficult part of q-computer design is getting enough qubits to sit still to q-search the space of solutions (to Bear's Feistel-gates-machine), subject to your specific constraints (eg., here's a chunk of ciphertext; here's a function which discriminates noise from likely plaintext, or a set of likely plaintexts). The *whole problem* is calculating/enforcing your problem constraints on the q-system. No different from a sim annealing or evolution run, where all the domain-tricks are in the eval function. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: building a true RNG
At 11:24 AM 7/25/02 -0400, John S. Denker wrote: And most particularly I do not care if the analog threshold of my soundcard shifts slightly (as a function of recent history, temperature, phase of the moon, or whatever). A change in the analogue threshold of your digitizing step will change the variability (aka entropy) of your samples. The practical solution is wide engineering margins and monitor your raw input. (And, if you can (SHA users can't), measure the data just before it goes into any whiteners you use, for belts-and-suspenders assurance that you've compressed it sufficiently.) This is the central conceptual point of my paper. It is more important than any particular implementation. The point is that a Random Symbol Generator can be proved correct using fairly mild assumptions and premises. Based on a detailed model of the noise, grounded in physics. Yep. Have you seen RNGs based on arrival times of network packets, or disk accesses, etc.? I'd extrapolate that you'd not trust them much given their distance from physics. (And I'd agree that a soundcard (or RF card) is preferred and 'free') The turning point of the argument is statistical: if I have enough entropy at the input of the hash function, and if the hash function doesn't waste entropy (by having unnecessarily many hash collisions) then the statistics takes over and covers a multitude of sins. I don't think collision is the right word; you're not doing a search on hash values which might collide. For example, if I have 165 bits of entropy at the input of the hash function, the output will have 159.98 bits of entropy in a 160 bit word. I don't understand this. If you have 165 bits of entropy in, you should be able to generate 160 binary symbols with a bit of entropy each. (You are conserving total entropy, only concentrating it by reducing the number of symbols.) You can shift the threshold all you want. Shifting thresholds changes entropic content. You can add something to the input. DC doesn't matter, capacitors are cheap :-) If the alleged threshold shift is so large as to decrease the variability of the raw data, then all bets are off... but that wasn't the question that David asked. The rhetorical question suggested that if the threshold shifted at all I would have a big problem, and I loudly assert that I don't. Specifically: If you give me any halfway-reasonable upper bound on the magnitude of the shift, I can design the generator to accomodate that, producing industrial-strength randomness despite such a shift. This hinges on the definition of large and small... anyway generous margins monitoring work both for steel bridges and RNGs. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: building a true RNG (was: Quantum Computing ...)
At 08:39 AM 7/23/02 +0200, Eugen Leitl wrote: On Mon, 22 Jul 2002, David Honig wrote: Yes, it is a joke. However, it is also a viable if low-bandwidth entropy source. I disagree that you need to be able to model I've got a framegrabber with a 640x480 24 bit/pixel camera. It doesn't compress, is rather noisy, and since self-adjusting I get the maximum entropy at maximum darkness. Is there any point in compressing the video before running it through a cryptohash? How does e.g. SHA-1 fare with very sparse bitvectors? Good question. I'd say the answer depends on the computational requirements of compression vs. SHA, assuming you're trying to save CPU cycles. You can measure the entropy of your camera staring at a wall and use that to estimate how much you need to digest. Then add a generous engineering margin, of course. Here's the type of experiment I've done, which separates the bit-digestion from the crypto-hashing: Once you measure entropy in your raw data, you can put the data sample through various distillers. For instance, xor pairs of bits, reducing the sample size by 2. Measure the entropy of this. Keep doing this until your entropy-measure says you've maxxed out. Then, to truly mess with Mr. Adversary, put it through a crypto function (which here needn't be a digest, e.g., a block cipher). The latter step achieves the 'mixing' (avalanche) which is built into SHA. For a software implementation SHA seems like a good choice, though you don't get to measure the entropy distillation before whitening. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: building a true RNG (was: Quantum Computing ...)
At 10:59 PM 7/22/02 -0700, [EMAIL PROTECTED] wrote: Entropy is not quite a physical quantity -- rather it is on the slippery edge between being a physical thing and a philosophical thing. If you are not careful, you will slip into a deep epistemic bog and find yourself needing to ask how do we know what is knowable, and what is the whichness of why? To avoid such deep waters, know where your entropy is coming from. We agree on your substantive points re RNGs, I think, but you're interestingly wrong here. Entropy is a physical quantity, it even figures into chemistry. The physics-of-computation people (Bennett? Landaur? etc) have written about thermodynamics information. Modulo Chaitin-type mindgames about measuring it :-) Anyway we're cryptographers, not philosophers, so we should be safe.. Four wheeling through the epistemological bog with Shannon as copilot - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Computing Puts Encrypted Messages at Risk
At 02:40 PM 7/19/02 -0400, John S. Denker wrote: Amir Herzberg wrote: I don't even need quantum mechanics to generate industrial-strength random symbols. No one is saying you do. Specifically: The executive summary of the principles of operation of my generator is: -- use SHA-1, which is believed to be resistant to collisions, even under chosen-input attack. -- use it under conditions where the adversary cannot choose the input. -- the rest is just physics and statistics. Sure. There are many examples of this kind of generator, using physical sources from video'd lava lamps to radioactive decay (incl. semiconductor junctions, resistors, microphone, detuned FM radio cards). And there are many examples of output-whitening hash functions; SHA-1 is reasonable in this case. As an aside note, the uncertainty principle may be an example of physical theory which have withstood many years, but I doubt that it was really tested using crypto principles. Where is that coming from? I consider the uncertainty principle incomparably more well-established than the usual crypto principles. The thread here has split into QM True Randomness and what do you need to build a true RNG... 2) Vetting a generator by trying to detect patterns in the output is like kicking the tires on a used car ... go ahead and do it if you want, but it is far from sufficient for establishing any reasonable standard of correctness. You can't vet a RNG by looking at its output, which is likely whitened anyway, but you can gain confidence by looking at its design and measuring the entropy in the raw-physical-source derived bitstream. If the raw source has 1 bits/symbol (and it will), it'd be nice if a later stage distilled this to near 1 bit/symbol, before whitening. Of course, no one outside the box will know, since you're whitening, but it yields resistance to (albeit difficult) attacks (e.g., your hash turns out to be attackable). I also fail to see harm in measuring/monitoring entropy as the RNG operates. dh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: building a true RNG (was: Quantum Computing ...)
At 04:24 PM 7/22/02 -0400, John S. Denker wrote: For the humor-impaired, let me point out that the lava lamp is a joke. What it conspicuously lacks is a proof of correctness -- that is, a nonzero lower bound on the entropy rate of the raw data. Yes, it is a joke. However, it is also a viable if low-bandwidth entropy source. I disagree that you need to be able to model the lava (etc) well enough to give a lower bound on the entropy. (Though its nice if you have such a model). You should be able to use any source which you know is not a PRNG as the entropy-source in a true RNG. You should be able to use entropy (and stat tests) to measure the source entropy after digitization. The lava could turn out to have a not-very-complicated periodic pattern. Secondarily, the pattern changes so slowly that there must be rather strict upper bounds on the entropy rate, small out of all proportion to the cost of the contraption. Yes, thus the humor. A detuned FM card is a bad idea, because it is just begging the opponent to sit next door with an FM transmitter. So work in a Faraday cage... A microphone causes users to worry about privacy, and in any case doesn't add much beyond what you'd get with the same input circuitry open-circuited, i.e. everything except the microphone itself. The advantage of a microphone, I suppose, is that you can hear any jamming attempts.. Radioactive decay has a poor price/performance ratio, and isn't nearly as random as neophytes might think, when the data-acquisition hardware is taken into account. Its a joke/hack of the 'finesse' form.. which is likely whitened anyway, Depending on what whitening means; see below. You can imagine simple-hashing (irreversible compression) as distinct from whitening which is related to cryptographic strength, avalanche, mixing, etc. Source -- Digitizer -- Simple hash -- Whitener (e.g., DES) In this view, SHA combines the compression (aka digestion) function with the crypto-strength whitening That's the point where I would like some more detail. If measuring means applying statistical tests, then I've never seen such measurements done in a way that is really convincing. Constructive examples would be welcome. You collect some representative raw data, and run a number of entropy measurements on that sample. You find 1bit/baud. You run the data through an algorithm which produces fewer bits. You measure the entropy of the result. When successive (or 'stronger') runs measure at 1b/bd, you have distilled entropy from that sample. To use this in crypto, you'd put it through a whitener --feed blocks to DES-- for belts-and-suspenders assurance. And because you don't want someone looking through your simple-hashing logic back to your source. Once you put it through DES, anything (eg the integers) appears random. That's why you measure before whitening, if possible. If you use SHA you can only measure the input entropy and make sure you hash enough bits down to produce your output stream. Since utter crap coming in will look perfectly white coming out. I recommend _calculating_ the entropy from physics principles, rather than trying to measure the entropy using statistical tests. The calculation is based on a handful of macroscopic physical parameters, such as temperature, gain, and bandwidth. You measure because your model may have overlooked something. The output of a good distiller has virtually 100% entropy density, i.e. 8 bits per byte. I say virtually because perfection is impossible, but 159.98 bits in a 160 bit word ought to be good enough for most applications :-). I agree with the first statement (by definition), I think in crypto you have to be dubious (paranoid?) of the second. I see no point in whitening the output of such a distiller. So the adversary can't look back into your logic. A 'distiller' which produces quality entropy (after digesting an arbitrary number of bits) needn't be as opaque as a crypto-secure hash is. If whitening means encrypting the output of the distiller, I consider that just a more-complicated hash function ... just another few rounds. That's a fine implementation. Others may wish to separate the phases (e.g., hardware to do simple-hashing can be high-speed on the entropy-source-side, and feed slower crypto-hashing (whitening) logic on the other side). But using software to distill your entropy its easy enough to run a few more iters. And there are very few users of high bandwidth entropy. Of course, no one outside the box will know, since you're whitening, but it yields resistance to (albeit difficult) attacks (e.g., your hash turns out to be attackable). I assume that means know [that I'm using a distiller] No one outside the box can tell the difference between simply hashed 'noise' and crypto-hashed 'noise'. Or between those and a long-sequence PRNG. Now, if the adversary knows things about your simple-distiller, he may be able to use that. If a
Re: Palladium Eye Ear Implants
At 01:07 AM 7/1/02 +0200, Hadmut Danisch wrote: As a consequence, it is not enough to just encrypt the connection between the computer and the monitor or the keyboard. An encryption of the connection between the computer and the authorized person itself is needed. The solution would be to implant chips in one's head and to connect them to the eye and ear nervers, thus injecting the decrypted information directly into the brain. This also solves the problem that when a person who has paid reads an e-book, always other persons who didn't pay could watch too. I don't see how the last paragraph holds. What stops me from copying your neural feed, and remapping to my particular wet-wiring? This has to be solved to feed your neurons in the first place. Of course, blue screens become a much more intense experience once they can happen directly in your head and completely shut down your visual and acoustical perception. A head crash, so to speak.. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Commercial quantum crypto product - news article
At 05:55 PM 5/31/02 -0400, John S. Denker wrote: the thermodynamics of electrical circuits, costing next to nothing. A draft writeup can be found at: http://www.monmouth.com/~jsd/turbid/paper/turbid.htm You write: -- We check for common gross failures. We consider it unnecessary and infeasible to check for uncommon obscure failures. It isn't that hard to run eg the Diehard suite periodically; that checks for some fine nuances.. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Where's the smart money?
Old money is analogue, and therefore decays in a gradual fashion. The Treasury (via the banks) culls fading bills. An RFID would be digital and would fail catastrophically. This is an important difference. [Moderator's note: enough on the RFID now. It is far away from crypto. -Perry] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A risk with using MD5 for software package fingerprinting
At 02:27 AM 1/28/02 -0800, John Gilmore wrote: I have done enough years of chip testing AND architectural validation to know how few of the infinitely many combinations of instructions or bus cycles are actually tested to make sure that somebody didn't intentionally make *one* combination do something interesting. Even if you trust your processor, didn't the NSA pay the Taiwanese designer of your RAM chips to replace particular stored code sequences with other interesting ones, one time out of a hundred, when fetched? Nice piece. When I was writing Verilog for Blowfish and IDEA, we got interested in how to verify that the chip did what the code described. Esp. because you hand over your output to other internal groups who transform it into other forms (e.g., standard cell netlist, then GDSII masks, etc.) We were thinking about using reverse-engineering services who could strip, image, and reconstruct a netlist, to confirm that the logic did what it was supposed to (and in our case, nothing else). The equivalent of reverse-compiling from assembler --or microcode! We never got that far, though. dh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Steganography covert communications - Between Silk and Cyanide
At 02:59 PM 12/30/01 -0800, John Gilmore wrote: Along these lines I can't help but recommend reading one of the best crypto books of the last few years: Between Silk and Cyanide Leo Marks, 1999 This wonderful, funny, serious, and readable book was written by the chief cryptographer for the 'nefarious organization' in England which ran covert agents all over Europe during WW2 -- the Special Operations Executive. One of the more interesting conclusions of Marks is that different cognitive types require different kinds of instruction in crypto techniques ---some learned rote behavior, some needed reasons. One of the more poignant parts of his memoirs is that he knew that half his pupils would be dead soon after dropping. Another is his worries when trying to figure if someone behind the lines had been compromised (and their directions should not be followed) or they are merely forgetful or stressed. He would refer to their records during study, to see the kinds of errors they made, to help him decide. A very very good book. Unbeknown to the latter, Marks had already cracked General de Gaulle's private cypher in a spare moment on the lavatory. -from the obit of Leo Marks, cryptographer - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Stegdetect 0.4 released and results from USENET search available
At 02:47 PM 12/28/01 -0800, Bill Stewart wrote: At 01:59 PM 12/28/2001 -0800, David Honig wrote: A.A.M + PGP = covert radio transmitter which sends coded messages. Obviously interesting, so you direction-find to defeat the anonymity. And Perry replied: [Moderator's note: And how would you possibly do that? --Perry] Anonymity, like much of crypto or security, is an arms race. A radio TX would try bursty sending. So the DXer must keep his receivers going all the time. So the TXer has to move to a different place each time he sends. So the DXer needs a larger mesh of receiver stations and faster response; recording travel (license plate cams, requiring ID on busses) helps too. Ultimately the DXer can do a physical search on everyone. So the TXer has to embed the transmitter in his body. So the DXer has to X-ray everyone, etc. Faster foxes lead to faster rabbits which lead to faster foxes. Similarly with anonymous IP broadcast. Place enough surveillance cameras, subvert enough ISPs/remailers, deploy enough trojans, do enough traffic analysis, and strong anonymity takes much more effort. At that point the extra effort for stego might have been a good tradeoff. The point of stego, it seems to me, is to not attract such attention in the first place. Although *if* you're already on someone's Watch List there may be little point. Another example: You could have an encrypted, deniable filesystem with duress passphrases, etc. But you still have to deal with Mr. Happy-Fun Customs Agent who wants to know what kind of naughty bits you're importing. A collection of baby pictures requires no explanation, no special flag in the records that track you. So tracing a single transmission may be hard, but tracing an ongoing pattern is easier, Exactly. unless there's a trusted Usenet site in some country where you don't have jurisdiction problems. And is out of range of the guided missile which was accidentally mistargeted due to out of date maps. And which doesn't need to interact with the US financial tentacles. Which can maybe survive a physical embargo. Whose sysop is immune from coercion or bribery. That means that A.A.M + PGP is fine for an occasional Attack at Dawn message, but not necessarily for routine traffic. Yes --much like a covert radio transmitter. Love work, hate domination, and do not let your name come to the attention of the ruling powers. -Talmud/Sayings of the Fathers - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Stegdetect 0.4 released and results from USENET search available
At 02:40 PM 12/28/01 -0500, Trei, Peter wrote: Posting PGP to aam also avoids the bandwidth bloat imposed by stego, and the extra complication of having to stego and destego images, as well as generate the images used for cover. Why would anyone bother hide tiny messages in ebay images or alt.binaries.erotica.bestiality.hamster when they can just post to aam? Peter Trei A.A.M + PGP = covert radio transmitter which sends coded messages. Obviously interesting, so you direction-find to defeat the anonymity. [Moderator's note: And how would you possibly do that? --Perry] Stego = signalling via called-in requests to a commercial music radio station. Not interesting. Sure its extra work but high risk requires high effort. Strong-anonymous broadcasting takes work too. dh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Stegdetect 0.4 released and results from USENET search available
At 02:40 PM 12/28/01 -0500, Trei, Peter wrote: There's a much simpler reason why few or no stego'ed messages are present in usenet images: They form an inefficient and unneeded distribution mechanism. On the subject of stego, this showed up earlier this week: To: [EMAIL PROTECTED] Subject: P2P Stego Treasure Hunt We've put into Morpheus a song, Grayson_Shoot_The_Piano_Player.mp3 which has a stego'd message in it. The tool is mp3stego v 1.1.15 (source available; see http://www.cl.cam.ac.uk/~fapp2/steganography/mp3stego/ ) and the (3DES) passphrase is writecode Another file DrDidg_RaveOn.mp3 has another message under the same passphrase. We are curious how readily the Morpheus search engine can be used for transport purposes. In this instance we give unique names to files not otherwise found in the system. Another experiment in P2P percolation would be to add similar 'watermarks' (microdots) to files which are abundantly replicated. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Biometric identity cards
At 12:46 AM 9/23/01 -0400, R. A. Hettinga wrote: From: Steve Furlong [EMAIL PROTECTED] Malaysia is willing to share the technology with the US and other countries now worried about terrorism. Serbia was willing to send election advisors to help with the FLA presidential elections.. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [FYI] Did Encryption Empower These Terrorists?
At 11:50 AM 9/17/01 +0200, Hadmut Danisch wrote: Which politician would dare to ban hotels? Which politician would fail to support mandatory registration of motel occupants with local 'authorities'? [Moderator's note: Everyone who's got a copy of Netscape or IE has cryptographic software in their hands, and most of them have used it. --Perry] Which politicians would fail to support only govt-authorized SSL servers? And up til Tuesday, copy control tech law was top news. So that kind of crypto app is moving into entertainment-deployment as well as online-purchasing. But that's dedicated-use crypto. A politician who wants to license sysops who use SSH to administer securely and remotely? It could happen. And, beyond that, we have to keep in mind a certain detail: Air planes, telephones, hotel rooms, rental cars are civil equipment. In contrast to that, cryptography is a martial art. It's history shows that it has been used for military purposes for centuries, but far less than a century for private purposes. Wrong. Secret and hidden writing is almost as old as writing. See e.g., Singh's _Secret Codes_, or Kahn, etc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
No Subject
At 02:14 PM 9/17/01 -0400, Jim Windle wrote: Second, if we assume for a minute that the terrorist use public key systems Given their 1. quality opsec including 2. wise avoidance of wireless phones, etc, and their 3. dependence on long-time personal contacts, isn't it more likely that private keys on floppies (or CDs) would be used? 3. is hardest and most valuable. The fact that they are 4. ideologically motivated, (rather than financially or by ego) makes it even tougher. If a *utility knife* is a *skyscraper disassembly tool*, worrying about the code is irrelevent. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypto hardware
At 02:28 PM 7/10/01 -0700, Kent Crispin wrote: A couple of years ago at the RSA conference one of the vendors was exhibiting a tamperproof that would keep a secret key and perform encryptions/signatures using the key. Since the key never left the box, in theory security reduced to physical security around the box. The intended use of the box was as a master for a CA. I thought the vendor was GTE, but I didn't find anything definitive on their site. Does this description trigger any recollection? Are there similar devices on the market from other sources? Look up ibutton.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Sender and receiver non-repudiation
At 08:55 AM 7/3/01 -0700, [EMAIL PROTECTED] wrote: signing. With digital signatures it becomes murkier ... how does somebody know that what they are looking at is the same thing that the computer is calculating a digital signature for. Good point. There's no way without a trusted host somewhere. Imagine that you scanned the paper doc, inspected it visually, and digitally signed the image file. Even this is succeptible to a trojan that alters the display, alters what's printed, etc. If you do have a little trusted island, e.g., a java button on a ring you wear in the shower, or a PDA display you trust, you can often leverage this to make a trusted system. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: septillion operations per second
At 12:16 PM 6/20/01 +0200, Barry Wels wrote: Hi, In James Bamford's new book 'Body of Secrets' he claims the NSA is working on some FAST computers. http://www.randomhouse.com/features/bamford/book.html Fantastic book. I read the stuff about using Areceibo for moon-bounce surveillance of Soviet radars just after getting back from visiting the dish [1]. Re: fast computers. All crypto thinkers will assume that the Adversary has got each fundamental particle in the universe cranking away at insane speeds on your key until the Restaurant at the End of the Universe closes. You're obviously a newbie, but that's cool, you're here to learn, like the rest of us. [1] 800 stairs at noon near the solstice in the tropics. Fun fun fun [2]. Microwave ductwork you could stand in. As a bonus, the US decided to stop bombing a Puerto Rican tourist isle while we were visiting. [2] With a 30+++ pound infant that insists on being carried, no less. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Impact and purpose of IP/FP in DES
At 09:42 PM 4/24/01 +0200, Martin Olsson wrote: The initial permutation and the corresponding final permutation do not affect the security of DES. (As near as anyone can tell, its primary purpose is to make it easier to load plaintext and ciphertext data into a DES chip in byte sized pieces. Remember that DES predates 16-bit or 32-bit microprocessor busses.) ... many software implementations of DES leave out both the initial and the final permutations. ... While the new algorithm is no less secure than DES, it does not follow the DES standard and should not be called DES. /quote First; I do not exactly understand what Mr.Schneier means. How can it be easier to transfer 8-bits of data into a chip if one first rearranges the bits? In software, this is a necessary chore for being compliant with the Standard. However, cryptographically, it does nothing. Hint: In hardware, its free. dh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
