Re: Creativity and security
Unfortunately, they haven't. In Europe I get receipts with different crossing-out patterns almost every week. And, with "they" I mean the builders of point-of-sale terminals: I don't think individual store owners are given a choice. Though I believe I have noticed a good trend in that I get receipts where *all but four* digits are crossed out more and more often nowadays. /Olle On Mar 20, 2006, at 21:51, [EMAIL PROTECTED] wrote: I was tearing up some old credit card receipts recently - after all these years, enough vendors continue to print full CC numbers on receipts that I'm hesitant to just toss them as is, though I doubt there are many dumpster divers looking for this stuff any more - when I found a great example of why you don't want people applying their "creativity" to security problems, at least not without a great deal of review. You see, most vendors these days replace all but the last 4 digits of the CC number on a receipt with X's. But it must be boring to do the same as everyone else, so some bright person at one vendor(*) decided they were going to do it differently: They X'd out *just the last four digits*. After all, who could guess the number from the 10,000 possibilities? Ahem. -- Jerry (*) It was Build-A-Bear. The receipt was at least a year old, so for all I know they've long since fixed this. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Java: Helping the world build bigger idiots
On Sep 21, 2005, at 23:27, Steve Furlong wrote: If by that you mean, "Program dumb: avoid tricky code, avoid odd usage, stick to the basics", I agree. Save your clever tricks for hobby code and the snippets you use to score hot chicks. Critical code, potentially dangerous code, and professional code should be written simply and with the idioms standard to the language. Peter's example is "standard to the language". It's just not used much by those influenced by other idioms prior to learning Java. I guess another way of saying this is: the people on this list are getting old. :-) /Olle - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Bluetooth cracked further
On Jun 4, 2005, at 14:12, Thomas Lakofski wrote: Finally, the PIN length ranges from 8 to 128 bits. Most manufacturers use a 4 digit PIN and supply it with the device. Obviously, customers should demand the ability to use longer PINs. Correction: Most manufacturers hardcode the 4-digit PIN to . It has been known for some time that those "gadgets" need to be paired in an Faradayic environment: if I recall correctly, a paper being presented on this at the RSA conference ~2001 or so. The forced re-pairing vulnerability is news to me. It makes me very concerned about Bluetooth keyboards... /O - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Colliding X.509 Certificates
Seems to me that a CA can nullify this attack by choosing a serial number or RDN component (after all, a CA should vet the DN and not simply sign what's in the PKCS#10 request), such that the public key does not end up at an "appropriate" DER-encoded offset in the certificate. Or am I completely lost? /Olle On Mar 4, 2005, at 13:44, Joerg Schneider wrote: Benne, One could e.g. construct the to-be-signed parts of the certificates, and get the one certificate signed by a CA. Then a valid signature for the other certificate is obtained, while the CA has not seen proof of possession of the private key of this second certificate. From the paper I understand that this results in two certificates, which are identical except for the public key and that the attacker knows the private keys for both. Do you think it would be possible to modify the attack, to get different Subject DNs or SubjectAltNames under the control of the attacker? This would scare me more. On a different note: In a real life scenario a CA would accept PKCS#10 requests, create the TBS using parts of the requests, providing other parts like notBefore/notAfter and the serialNumber, and finally sign the result. This would make the attack more difficult, as the attacker would have to guess, what the CA makes out of the request, including time of issuance and serialNumber. Do you think choosing the serialNumber in a way that it cannot be guessed by the attacker would be an effective way to counter collsion based attacks on CAs? Best regards, Jörg - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Code breakers crack GSM cellphone encryption
DCMA comes to mind: it could potentially make it a little harder to get your hands on any mass market eavesdropping tool. If you are terribly concerned about this, there are end-to-end encryption phones on the market that are used by military and others already today. Such systems come with a price tag though: As for me, the ordinary end user, I just have be as careful with what I say or trust when communicating over the phone as when I'm using email. But that should have already been the case, had I thought things through, and shouldn't come as a shock. /Olle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Honig Sent: den 8 september 2003 02:18 To: R. A. Hettinga; Clippable Cc: [EMAIL PROTECTED] Subject: Re: Code breakers crack GSM cellphone encryption >A copy of the research was sent to GSM authorities in order to correct the >problem, and the method is being patented so that in future it can be used >by the law enforcement agencies. "Laughing my ass off." Since when do governments care about patents? How would this help/harm them from exploiting it? Not that high-end LEOs haven't already had this capacity ---Biham et al are only the first *open* researchers to reveal this. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
