Re: 3G crypto algorithms
f8 and f9 are specified in 3G_20TS35.201, version 1.2 of September 5th, 2000. Jaap-Henk On Sat, 20 Jan 2001 13:26:13 +1100 Greg Rose [EMAIL PROTECTED] writes: You're missing the document that specifies f8 and f9, which is the glue between 33.102 and the Kasumi spec. Unfortunately I can't get to their server at the moment for some reason, so I can't give you it's number, but I think it is 33.2xx. thanks and regards, Greg. -- 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
Re: What's Wrong With Content Protection
On Sat, 20 Jan 2001 10:41:52 -0800 [EMAIL PROTECTED] writes: I will make a partial rebuttal to John Gilmore's article on the problems with content protection schemes. [..snip..] I understand that John and others worry that consumers will not actually be able to make choices and decisions, because all products available to them will have content protection built in. But this amounts to the belief that industry will form a cartel which seeks to sell products which make consumers unhappy, intentionally delivering devices which consumers dislike, smug in their belief that their cartel is 100% effective and that no competition is possible. Without the enforcement of laws like the DMCA, such a situation is highly unstable. There is a huge incentive to produce devices which don't observe the restrictions and which give consumers more power. These devices will be popular with consumers and the cartel will be broken. Not necessarily... The problem is that the CPSA (Content Protection System Architecture) proposes to encrypt all content (by the content producers). Player manufacturers will require a license on the decryption function, which they'll only get if they also implement copy protection. So devices without copy protection cannot legally decrypt the content, and therefore cannot play any of the popular content out there. These products will not sell on the market. 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
Re: The Shining Cryptographers Net
In the `traditional' DC Net, how is absence of a message detected? If this is a seperately distinguishable outcome of a round, each round may return three outcomes: `0', `1' and `none'. To represent these quantum mechanically, you need at least a 3-state quantum system (to make the outcomes perfectly distinguishable). In the proposals so far (for using quantum physics to protect the anonymity of the sender), the quarantee is not that the sender is always anonymous. It's merely that any eavesdropping will be detected. This is a weaker guarantee. Moreover, it is not clear how in the current proposal, eavesdropping is distinguished from collisions (ie two cryptographers trying to send simultaneously). Also, using a photon circulation scheme implies that _one_ cryptographer is made responsible for firing the photon. This gives him extra power (eg firing two photons simultaneously...). The idea to use quantum physics to get rid of the shared randomness is nice. I'm not sure that the approach outlined by Hal can be made to work. 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
Re: Fwd: from Edupage, December 22, 2000
On Thu, 04 Jan 2001 18:35:44 -0800 Bill Stewart [EMAIL PROTECTED] writes: Its just yet another 'secure' scheme that uses quantum theory (here, discrete photons; elsewhere, entangled photons) to detect or prevent leaking bits. More elegant than gas-pressurized, pressure-monitored 'secure' cables, but the same idea. Except that eavesdropping on the quantum key distribution channel is _always_ detected (by `laws of nature'), which is not true for these pressure-monitored cables. The theoretical difference _is_ there, but from a practical perspective, both are so inconvenient or expensive that even the very paranoid won't use them, and the moderately paranoid can use multiple encryption algorithms and overly-long keys. If you suppose that quantum crypto hardware becomes medium-cheap, people who are connecting RF-shielded cages together over distances of a hundred meters to a hundred kilometers (if the quantum crypto can go that far unamplified, otherwise ~2km) may find it more practical than pressurized cable. If you're going less than a hundred meters, stick to pressurized cable and armed guards :-) Actually, `classical' quantum key distribution by polarised or phase-shifted photons can be achieved up to distances of 100km. This appears to be the limit of what these systems can achieve. Using a different technique based on EPR pairs, this limit can be overcome using repeaters. I believe there is an application for these techniques. Perheps not to secure mass market e-commerce transactions. But if the hot line between Moskou and Washingtom was (supposedly) protected by a one-time pad, why not use quantum cryptography for such an application in the future? 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
Re: Fwd: from Edupage, December 22, 2000
On Tue, 02 Jan 2001 12:03:40 -0800 David Honig [EMAIL PROTECTED] writes: At 10:27 PM 1/1/01 +0530, Udhay Shankar N wrote: Did this slip between the cracks in holiday season or has it already been discussed here ? Udhay Its just yet another 'secure' scheme that uses quantum theory (here, discrete photons; elsewhere, entangled photons) to detect or prevent leaking bits. More elegant than gas-pressurized, pressure-monitored 'secure' cables, but the same idea. Except that eavesdropping on the quantum key distribution channel is _always_ detected (by `laws of nature'), which is not true for these pressure-monitored cables. 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
Re: UK Sunday Times: Steal the face right off your head
On Mon, 11 Dec 2000 15:28:23 + Ben Laurie [EMAIL PROTECTED] writes: "R. A. Hettinga" wrote: One of the main forms of security to combat such criminals will be biometrics: voice recognition and the scanning of fingerprints, irises and face shapes to secure property. Siemens is expected to launch a fingerprint phone within months. In South Africa, where fingerprint security has been introduced at some experimental prisons, inmates recently tried to cut off the hands of their guards to enter protected gates. What did I tell ya? Chris Charrington, a biometrics analyst at Frost Sullivan, a market consultancy, said new technology would mean dead fingers would no longer be able to activate the technology. Yeah, right. I urge (again) everyone to boycott all biometrics if they value their extremities. It's worth pointing out that there are biometrical experts who claim that fingerprinting is insecure for the following reasons: 1. people leave their fingerprints all over the place, and 2. a skilled person with the right equipment (for example a dental technician who makes fake teath) can make a fake copy of such fingerprint that will be accepted with all current devices According to these experts, any method for detecting gloves, dead fingers etc. cannot be made very reliable because the variation of the physical properties whose measurement these systems rely on is very large. Increasing the reliability would also increase the false rejection ratio, making the systems unusable. There's a paper on this in CARDIS '2000 of last September. Jaap-Henk -- Jaap-Henk Hoepman | Come sail your ships around me Dept. of Computer Science | And burn these 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
Re: Secrets Lies, a comment
On Fri, 1 Sep 2000 15:06:52 +0300 [EMAIL PROTECTED] writes: Ed says, The solution is to use a multifold of links, arranged in time and space such that rather than making the impossible assumption that "no part will fail at any time," we can design a system where up to M parts can fail at any time provided that not all M parts fail at the same time -- where M can be the entire number of parts. This sounds like `proactive security`, as defined in several cryptographic works. You may want to check it out at http://www.hrl.il.ibm.com/proactive Actually, this sounds more like applying fault tolerance (e.g. byzantine agreement) techniques to increase security and dependability of your system. Also related are secret sharing techniques and methods to securely compute a function on a partially trusted distributed system. Jaap-Henk -- Jaap-Henk Hoepman | Come sail your ships around me Dept. of Computer Science | And burn these 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
Re: reflecting on PGP, keyservers, and the Web of Trust
On Fri, 1 Sep 2000 23:14:06 -0400 (EDT) Russell Nelson [EMAIL PROTECTED] writes: Ed Gerck writes: Even though the web-of-trust seems to be a pretty good part of PGP, IMO it is actually it's Achilles heel. Nope. Usability is its Achilles heel. PGP needs to be wrapped in something, and yet it's not really designed to be wrapped. Even if it were, PGP, Inc. changed the interface! Doh! And then there's the whole encryption method problem. What's wrong with the PGP wrappers for Outlook or Eudora? They looked quite usable and user friendly to me - as far as any secure email product could ever be completely be user friendly... The user has to do more stuff than usual, and has to have some understanding of what is going on in order to judge whether his/her security requirements have been met. Jaap-Henk -- Jaap-Henk Hoepman | Come sail your ships around me Dept. of Computer Science | And burn these 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
Re: New hash function definitions
It seems that if you are only concerned about the length extension property, you could make the last compression function in the chain different from all other compression functions. For example, if sha() is the compression function for SHA1 and md() is the compression function for RIPEMD --- both compress 512 bit blocks into 160 bit blocks using a 160 bit IV ---, you could define SHA1-X (which is not length extending) as X | V IV - sha() - output for X 512 bits and block1 block2 last block 512 bit 512 bit 512 bit | | | V V V IV - md() - md() ... - sha() - output This way you do not need an extra compression step. It is of course necessary that md() and sha() are sufficiently different so that given md(x) you cannot compute sha(x) or vice versa (or that this at least as hard as inverting md(x) or sha(x)). Generalising the non-length-extension property, I would expect a `good' hash function to make it hard to compute h(a || b || c) given h(b), for bitstrings a,b,c where either a or b may be empty. Regards, Jaap-Henk On Mon, 10 Jul 2000 15:56:33 -0500 John Kelsey [EMAIL PROTECTED] writes: -BEGIN PGP SIGNED MESSAGE- I've been thinking about the requirements for hash functions. I've heard that NSA is currently designing a 256-bit wide SHA1 replacement, and I've been thinking about some things it would be nice to change from the way SHA1 and MD5 and such functions work. I really dislike the length-extension property of SHA1, MD5, RIPE-MD160, etc. That property is basically that if you are given hash(X), you can compute hash(X||Z), where Z is a bit string that has its first 512 or so bits specified based on the length of X, and can be allowed to take on any value desired after that. This is why the MAC proposal MAC_K(X) = hash(K||X) doesn't work. It's an extremely unintuitive property for a hash function to have. It looks to me like there's an extremely easy fix for this, though I may be missing something. If we define h'(X) = SHA1(X) and let f(IV,M) be the SHA1 compression function, we can eliminate the length-extension property by letting IV1 = the starting IV for SHA1. L = message length hash(X) = f(IV1,h'(X)||00...0||L) This costs one more compression function call for all messages, but apparently eliminates this length-extension property, since the attacker who doesn't know X doesn't learn h'(X) unless he can invert the hash compression function. My questions to the list are: a. Has anyone done analysis of this anywhere else? The construction is similar to the one used in HMAC, but I don't recall reading anything proposing that it be used in all hash functions. b. What effects would this have on hash functions if it were widely adopted? This can't make a hash function weaker against either inversion or collision-finding attack, unless I'm missing something big. Inversion attack: To invert this and recover X, you would have to be able to invert the existing hash function. Sketch of Proof: Suppose you give me an algorithm for inverting hash(X); given this algorith, I construct a new algorithm that inverts h'(X), which is the old hash function. To do this, I compute hash(X) = f(IV1,h'(X)||00..0||L) and then apply your algorithm for inverting hash(X). Collision attack: To find a pair of messages that collide, you must do one of two things: a. Find a pair of messages that collide for h'(X). If you've done this, you've found a collision for the original hash function. b. Find a pair h'(X),h'(X*) for which f(IV1,h'(X)||00..0||L) == f(IV1,h'(X*)||00..0||L). That means finding a hashing collision for the compression function using only the message block, from SHA1's starting IV. If you can do that, you have found a hash collision for SHA1: M0 = h'(X)||00..0||L, and M1 = h'(X*)||00..0||L. Comments? - --John Kelsey, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.1 Int. for non-commercial use http://www.pgpinternational.com Comment: foo iQCVAwUBOWo4MiZv+/Ry/LrBAQEHSgP/SlhRwfN5UCinaO/0gSkgTpWSvbeh6ard nRmImUfymn2fLh49qqjk/vMVtOjGc1UL2wWmWlCXUSdalsAcG4oaqJgUw1R2KQjq pxSKp494LtDVzIVy3FywxQ9LEtwh2ps5a3A4KYGstUUmOvvnkbVRFD4sxdx7ZFwk OtJlYpvlJAw= =/h6n -END PGP SIGNATURE- -- Jaap-Henk Hoepman | Come sail your ships around me Dept. of Computer Science | And burn these 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
Re: [FYI] NL: Intelligence agency authorized to scan satellite communications
On Tue, 11 Apr 2000 20:15:30 +0100 "Axel H Horns" [EMAIL PROTECTED] writes: http://www.heise.de/tp/english/inhalt/co/6731/1.html --- CUT - Echelon in Holland Jelle van Buuren 11.04.2000 Dutch intelligence agency authorized to scan satellite communications The Dutch Intelligence Agency BVD is getting new powers. Among other things, the powers to intercept communications will be extended. The agency is authorized, if the government gets its way, to intercept satellite communications at random and search the intercepted traffic by keywords. Also, the BVD gets a new intelligence task: the gathering of economical information. Holland goes Echelon, it seems. In fact, this task is not new at all As presented by Cees Wiebes on the NISA conference on the importance of SIGINT after the cold war (in Amsterdam last year), Dutch intelligence agencies (not necessarily the BVD, I can't remember off-hand) have been involved in regular economic espionage for Dutch industry for decades. This was done under orders of the Ministry of Internal Affairs, who would receive the relevant information. Jaap-Henk -- Jaap-Henk Hoepman | Come sail your ships around me Dept. of Computer Science | And burn these 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
Re: Ten Risks of PKI
On 13 Dec 1999 18:40:02 - lcs Mixmaster Remailer [EMAIL PROTECTED] writes:
While this is true, keep in mind that there is more to mounting
a successful cryptographic attack than adding root keys and fake
certificates. It is also necessary to intercept the messages which
might have gone to the legitimate recipient, and possibly decrypt and
re-encrypt them. All this implies an attacker who has at least temporary
write access to the victim's computer, and long term read/write control
over the communication channels he will use.
I do not believe this attack requires "long term read/write" access to
the victim's computer. If I want to get a forged certificate into a
clients Browser all I have to do is convince the user to browse my
secure server with Netscape (or another browser) that will prompt the
user to install my unrecognized root certificate.
That's a good point, most browsers are configured to make it easy to
install root certificates.
However this is just the first step in an effective compromise. Now you
need to get him to use a bogus certificate when he thinks he is using
a good one. He tries to connect to a secure site, and you need to step
in and play man in the middle. You must hijack his connection to, say,
www.amazon.com, and direct it to your own site. Then you can offer your
bogus cert for www.amazon.com and get it accepted.
Alternatively, the attacker could just register the domain anazon.com (if only
amazon.con were possible :-) or amazon.be ("Look, Amazon's just started a
Belgian branch!"), issue a certificate for that site, and start spreading
banner ads and URL's for this domain.
Jaap-Henk
--
Jaap-Henk Hoepman | Come sail your ships around me
Dept. of Computer Science | And burn these 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
Re: Digital Contracts: Lie in X.509, Go to Jail
On Tue, 19 Oct 1999 11:56:14 -0400 "Steven M. Bellovin" [EMAIL PROTECTED] writes: In message v0421012db4321dc2f55c@[204.167.101.62], Robert Hettinga writes: The solution to this madness, is, of course, bearer credentials, as Stephan Brands points out in his recently published doctoral dissertation "Rethinking Public Key Infrastructures and Digital Certificates -- Building in Privacy", now published by Ponsen and Looijen in the Netherlands, ISBN 90-901-3059-4. Do you know where to order this? None of the amazon.com sites has it, nor doe s barnesandnoble.com. Ponsen and Looijen is _not_ a publisher, just a printer printing a lot of PhD theses. I'm afraid the only way to get a copy is as explained on http://www.xs4all.nl/~brands/order.txt Regards, Jaap-Henk -- Jaap-Henk Hoepman | Come sail your ships around me Dept. of Computer Science | And burn these 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
