Re: REQ: Review of Nigel Smart's Introduction to Cryptography
Actually, there's the textbook Introduction to Cryptography by Delfs and Knebl that covers provably secure encryption and digital signatures as well. Published by Springer. Jaap-Henk On Fri, 7 Mar 2003 15:14:04 -0300 Mads Rasmussen [EMAIL PROTECTED] writes: Has anyone read Nigel Smart's book from late 2002, introduction to Cryptography The latest IACR newsletter brought an overview and TOC of the book, which I found interesting. It seems to me the first time provable security is mentioned in a textbook (see part IV, 17 and 18) As the newsletter said, more info is available at http://www.mcgraw-hill.co.uk/html/0077099877.html http://www.mcgraw-hill.co.uk/html/0077099877.html -- Jaap-Henk Hoepman | I've got sunshine in my pockets Dept. of Computer Science | Brought it back to spray the day University of Nijmegen |Gry Rocket (w) www.cs.kun.nl/~jhh | (m) [EMAIL PROTECTED] (t) +31 24 36 52710/531532 | (f) +31 24 3653137 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum computers inch closer?
On 3 Sep 2002 00:15:54 GMT [EMAIL PROTECTED] (David Wagner) writes: And, for the example given by the poster -- exhaustive keysearch -- there is no way known to set up a superposition of the desired form with O(1) basic quantum operations. In fact, there is not even a shred of reason to believe such a quantum algorithm might exist; all available evidence points to the contrary. But note that there _is_ Grover's search that gives quadratic speedup. Jaap-Henk -- Jaap-Henk Hoepman | Come sail your ships around me Dept. of Computer Science | And burn your bridges down University of Nijmegen| Nick Cave - Ship Song Email: [EMAIL PROTECTED] === WWW: www.cs.kun.nl/~jhh Phone: +31 24 3652713 === Secr: +31 24 3653132 === Fax: +31 24 3653137 PGP ID: F280B29C | Print: C798 7420 F6A3 0B3D 1A0B BC53 1F12 C84E F280 B29C - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fwd: Re: Quantum Computing Puts Encrypted Messages at Risk
On Sun, 14 Jul 2002 15:24:48 +0200 Amir Herzberg [EMAIL PROTECTED] writes: 1. Quantum key encryption seems to require huge amounts of truly random bits at both sender and receiver. This seems impractical as (almost) truly random bits are hard to produce (especially at high speeds). Is there a fix? All practical proposals for QKD are photon based. The biggest practical problem so far with these systems is the generation of a single photon at high enough rates. It's this problem that makes the bitrate of QKD so low. The number of random bits required is proportional to the length of the key to be established, but depends on the amount of eavesdropping taking place. From memory, without eavesdropping, you need ~4 random bits for each bit of shared key established. This is not much more than the number of random bits required for a one-time pad of the same length. 2. After the transmission, the receiver is supposed to tell the sender how it set its polarization; how is this authenticated? If it isn't we are obviously susceptible to man in the middle attack. Yes. QKD does not solve the authentication problem. It merely establishes a shared key between two parties. 3. It seems the quantum link must connect directly from sender to receiver. How can this help provide end to end security on the Internet? Or are we back to private networks? Yes, photon polarisation based QKD systems by definition require a direct link between sender and receiver (a repeater would be an all-catching eavesdropper ;-). I do believe that QKD systems based on entanglement and teleportation allow for repeaters; but i havent studied these systems so far. 4. As to quantum computation signalling the end of `crypto as we know it`... Is it fair to say this may end only the mechanisms built on discrete log and/or factoring, but not shared key algorithms like AES and some of the other public key algorithms? Grover's search techniques will reduce the effective bit-length of symmetric key systems by a factor 2. All known quantum computing algorithms that are truly more efficient (giving exponential or subexponential speedup) than known classical solutions for the same problem appear to be based on being able to do fast fourier transforms efficiently. Factoring and discrete log can be solved faster using this. It is unclear whether other systems will ever be affected. The interesting question to me is whether quantum computing can be used to _construct_ efficient yet more secure public key cryptosystems. In particular I'm considering whether I should and can cover this area in my book. In my opinion, it would be a valuable addition if you did (although to do this subject justice, you would have to include a substantial amount of background material concerning physics and quantum computing basics). Regards, Jaap-Henk -- Jaap-Henk Hoepman | Come sail your ships around me Dept. of Computer Science | And burn your bridges down University of Twente | Nick Cave - Ship Song Email: [EMAIL PROTECTED] === WWW: www.cs.utwente.nl/~hoepman Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590 PGP ID: 0xF52E26DD Fingerprint: 1AED DDEB C7F1 DBB3 0556 4732 4217 ABEF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Welome to the Internet, here's your private key
I think there _are_ good business reasons for them not wanting the users to generate the keys all by themselves. Weak keys, and subsequent compromises, may give the CA really bad press and resulting loss of reputation (and this business is built on reputation anyway). So: there are good reasons not to let the CA generate the private key, but also good reasons to not let the user generate the keys all by himself. So the question is: are there key generation protocols for mutually distrustful parties, that would give the CA the assurance that the key is generated using some good randomness (coming from the CA) and would give the user the guarantee that his private key is truly private. Also, the CA should be able to verify later that the random data he supplied was actually used, but this should not give him (too much) advantage to find the private key. A smartcard based system might be useful here (as suggested by other subscribers here). But a software only solution is preferred because it would maker the application area much broader (because the user does not have to be supplied with special hardware - terminals + smartcards). Jaap-Henk On Wed, 6 Feb 2002 15:37:06 +0100 Arnold G. Reinhold [EMAIL PROTECTED] writes: And creates a potential legal liability for the smart card manufacturer. This gets to the original question of this thread. I wonder why the CA's lawyers let them generate private keys themselves. If it ever came out that private keys were misused by CA employees or even someone who penetrated their security, they would be legally defenseless, all the gobbledygook in their practice statements not withstanding. There is no good business reason for a CA to generate private keys and very powerful business reasons for them not to. -- Jaap-Henk Hoepman | Come sail your ships around me Dept. of Computer Science | And burn your bridges down University of Twente | Nick Cave - Ship Song Email: [EMAIL PROTECTED] === WWW: www.cs.utwente.nl/~hoepman Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590 PGP ID: 0xF52E26DD Fingerprint: 1AED DDEB C7F1 DBB3 0556 4732 4217 ABEF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Welome to the Internet, here's your private key
It's worse: it's even accepted practice among certain security specialists. One of them involved in the development of a CA service once told me that they intended the CA to generate the key pair. After regaining consciousness I asked him why he thought violating one of the main principles of public key cryptography was a good idea. His answer basically ran as follows: if the CA is going to be liable, they want to be sure the key is strong and not compromised. He said that the PC platform of an ordinary user simply wasn't secure/trusted enough to generate keys on. The system might not generate `good enough' randomness, or might have been compromised by a trojan. Jaap-Henk On Sun, 3 Feb 2002 15:09:57 +0100 [EMAIL PROTECTED] writes: It is accepted practice among security people that you generate your own private key. It is also, unfortunately, accepted practice among non-security people that your CA generates your private key for you and then mails it to you as a PKCS #12 file (for bonus points the password is often included in the same or another email). Requests to have the client generate the key themselves and submit the public portion for certification are met with bafflement, outright refusal, or at best grudging acceptance if they're big enough to have some clout. This isn't a one-off exception, this is more or less the norm for private industry working with established (rather than internal, roll-your-own) CAs. This isn't the outcome of pressure from shadowy government agencies, this is just how things are done. Be afraid. -- Jaap-Henk Hoepman | Come sail your ships around me Dept. of Computer Science | And burn your bridges down University of Twente | Nick Cave - Ship Song Email: [EMAIL PROTECTED] === WWW: www.cs.utwente.nl/~hoepman Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590 PGP ID: 0xF52E26DD Fingerprint: 1AED DDEB C7F1 DBB3 0556 4732 4217 ABEF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: biometrics
As much as i have my doubts about biometric systems i cannot let the below pass. On Wed, 23 Jan 2002 21:11:23 +0100 Perry E. Metzger [EMAIL PROTECTED] writes: However, as soon as you lose physical control over the device doing the measurements or their communications path biometrics become worse than useless. As one example, they're useless for authenticating over-the-net bank account access -- the device on your desk that your bank helpfully provides to scan your eye might not even be attached when the cracker's software helpfully provides forged information down the line. Liveness tests are not useful if you don't even know if the biometric hardware at the other end is intact. Anything in a user's location is by definition untrustworthy in this sense. Of course (and i think Dorothy mentioned this too), the measuring device and it's connection to the veryfying system must be properly protected. In case of the system Perry describes, a secure and fresh (ie fresh session key) link should be setup between the measuring device and the bank, so that eavesdropping _and_ replay/forgery is impossible. Even though most biometric systems may not implement this (i simply don't know), this is not a weakness of biometric systems per se. [Moderator's note: er, HUH? How does the link being realtime assure that the remote side isn't simply generating iris images and sending them to you? It doesn't. Biometrics are worthless except when the entire system is completely physically secure. --Perry] Jaap-Henk -- Jaap-Henk Hoepman | Come sail your ships around me Dept. of Computer Science | And burn your bridges down University of Twente | Nick Cave - Ship Song Email: [EMAIL PROTECTED] === WWW: www.cs.utwente.nl/~hoepman Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590 PGP ID: 0xF52E26DD Fingerprint: 1AED DDEB C7F1 DBB3 0556 4732 4217 ABEF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
