Re: [Cryptography] XORing plaintext with ciphertext
* Dave Horsfall: Take the plaintext and the ciphertext, and XOR them together. Does the result reveal anything about the key or the painttext? Yes, their length. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Snowden fabricated digital keys to get access to NSA servers?
* John Gilmore: [John here. Let's try some speculation about what this phrase, fabricating digital keys, might mean.] Most likely, as part of his job at the contractor, he had administrator access to a system which was used for key management, perhaps to apply security updates, manage backups or fix the occasional glitch. This is precisely the kind of low-level grunt work that I expect is outsourced to contractors. It's also possible that he was directly charged with key management. I can image that someone thought that as long as some agency committee made the actual decisions, it was fine to hire an external data typist who entered the committee decision in to the key management system. It's really funny that NSA-level security has now turned pejorative. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: ciphers with keys modifying control flow?
* Steven Bellovin: Does anyone know of any ciphers where bits of keys modify the control path, rather than just data operations? AES. See François Koeune, Jean-Jacques Quisqater, A timing attack aganst Rijndael. Université catholique de Louvain, Technicl Report CG-1999. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Obama administration revives Draconian communications intercept plans
Essentially, officials want Congress to require all services that enable communications — including encrypted e-mail transmitters like BlackBerry, social networking Web sites like Facebook and software that allows direct “peer to peer” messaging like Skype — to be technically capable of complying if served with a wiretap order. The mandate would include being able to intercept and unscramble encrypted messages. Isn't this just a clarification of existing CALEA practice? In most jurisdictions, if a communications services provider is served an order to make available communications, it is required by law to provide it in the clear. Anything else doesn't make sense, does it? Service providers generally acknowledge this (including Research In Motion, so I don't get why they are singled out in the article). There are indications that governments have access to Skype these days Here's a blog post mentioning it: http://www.lawblog.de/index.php/archives/2010/08/17/skype-staat-hort-mit/ (Udo Vetter is sometimes a bit sensationalist, though.) Another indicator is that German law enforcement no longer calls for new laws granting them access to Skype traffic. In any case, the cleartext requirement for lawful intercept has always been very public. Oddly enough, it has not been perceived as some sort of crypto regulation, although it puts some constraints on key management. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Haystack redux
* Adam Fields: I find it hard to believe that even the most uninformed dissidents would be using an untested, unaudited, _beta_, __foreign__ new service for anything. Is there any reason to believe otherwise? I wouldn't be surprised if there are plenty such tools in circulation which are used by various dissident groups. It's a cost-effective way to infiltrate them. The problem with such tools is that you can't really know how is listening in on the proxies. Even if the software itself contains no backdoors, the service as a whole might still be compromised. Even if the proxies are trustworthy, your usage of the tool can very likely be discovered by traffic analysis (and usage patterns as well, if you're unlucky, and increasingly so if the service has low latency). There is no technical solution to oppressive governments (or non-trustworthy ISPs, for that matter). After all, if you're anonymous and oppressed, you're still oppressed. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: towards https everywhere and strict transport security
* James A. Donald: Every time you layer one communication protocol on top of another, you get another round trip. In this generality, this is not true at all. You're confusing handshakes with protocol layering. You can do the latter without the former. For example, DNS uses UDP without introducing additional round trips because there is no explicit handshake. Lack of handshake generally makes error recovery quite complex once there are multiple protocol versions you need to support, but handshaking is *not* a consequence of layering. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MITM attack against WPA2-Enterprise?
* Donald Eastlake: It's always possible to make protocols more secure at higher cost. On the other hand, group key vulnerabilities are nothing new. It's just that many protocol designers seem to not understand them. Back when Cisco proposed XAUTH for IPsec, there was a heated discussion about password strength and other irrelevancies, but as far as I could later reconstruct the discussion, no one objected to the group key concept as such. It was only much later, when people used XAUTH in large deployments for providing general Internet access over insecure media, that the group key was recognized as a vulnerability. It's amazing that people still fail for this group key thing. There is quite a simple rule: If you choose the secret bits without constraints (except length and formatting), and proceed to share those bits, there can be no protection from those with whom you share, no matter what cryptographic algorithms you use. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Encryption and authentication modes
* David McGrew: can I ask what your interest in AEAD is? Is there a particular application that you have in mind? I just want to create a generic API which takes a key (most of the time, a randomly generated session key) and can encrypt and decrypt small blobs. Application code should not need to worry about details (except getting key management right, which is difficult enough). More popular modes such as CBC lack this property, it's too easy to misuse them. I suppose a superficially similar primitive is contained in Bernstein's NaCl library. I was intrigued by its simplicity, but the cryptographic algorithms it uses are a bit non-standard. Right now, I would probably use it to forward session state through browser URLs in areas which are not actually security-relevant. Somewhat more sensitive applications are possible in the future. In no case I expect adversaries to actually have access to ciphertext. To some degree, it's about being able to say yes, we use encryption for X, and it's algorithm Y, and I want to do it right without using CMS or modern OpenPGP, with all the complexities that come with that. When I said that CCM wasn't widely implemented, I was referring to the fact that none of the cryptographic libraries on my system supports it directly. This is a pity because once you fix the parameters, it's much simpler to use safely than pure encryption modes. There seems to be one downside with the CCM instance specified towards the end of the NIST standard, though: If you on an architecture where sizeof(size_t) == 8, then your encryption function isn't total because it can't accept the full range of possible input lengths---or you end up with just 64 bit for the tag, which seems to be a bit on the small side. I'm not sure if this is a compelling reason to use EAX or GCM, though---especially since we're strictly limited to 31 bit array length in some places by software and not hardware (so this limitation will be in place for a long time). A mode which does not rely as much on proper randomness for the IV would be somewhat nice to have, but it seems that the only choice there is SIV, which has received less scrutiny than other modes. OCB is very attractive in software, but GCM is more efficient in hardware because it can be implemented without pipeline stalls. GCM can perform well in software, though it can't be as compact as CCM, and it excells with SIMD (http://eprint.iacr.org/2009/129) or modest hardware support like Intel's new PCLMULQDQ instruction (http://www.drdobbs.com/security/218102294;jsessionid=GMTY4RCFLHBMRQE1GHOSKHWATMY32JVN?pgno=3 ). Interesting. But it will take about five years until our crypto code would make use of a new hardware instruction, assuming that we'd implement all the necessary pieces right now (thanks to desynchronized software release cycles at several layers of the software stack). Speed is of no particular concern anyway. Increase in message size is somewhat relevant (think about the URL case I mentioned), but only to up to a degree. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Encryption and authentication modes
What's the current state of affairs regarding combined encryption and authentication modes? I've implemented draft-mcgrew-aead-aes-cbc-hmac-sha1-01 (I think, I couldn't find test vectors), but I later came across CCM and EAX. CCM has the advantage of being NIST-reviewed. EAX can do streaming (but that's less useful when doing authentication). Neither seems to be widely implemented. But both offer a considerable reduction in per-message overhead when compared to the HMAC-SHA1/AES combination. Are there any other alternatives to consider? Are there any traps I should be aware of when implementing CCM? -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: What's the state of the art in factorization?
* Thierry Moreau: For which purpose(s) is the DNS root signature key an attractive target? You might be able to make it to CNN if your spin is really good. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: What's the state of the art in factorization?
* Thierry Moreau: Florian Weimer wrote: * Thierry Moreau: For which purpose(s) is the DNS root signature key an attractive target? You might be able to make it to CNN if your spin is really good. But even without this self-restraint, there would be no spin for a CNN story. Dedication to good cryptographic key management is squarely dull and boring for a typical person. I was referring to news of a breach (whether through factoring or otherwise), not the key management procedures as such. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
* John Levine: At a meeting a few weeks ago I was talking to a guy from BITS, the e-commerce part of the Financial Services Roundtable, about the way that malware infected PCs break all banks' fancy multi-password logins since no matter how complex the login process, a botted PC can wait until you login, then send fake transactions during your legitimate session. This is apparently a big problem in Europe. There are some countries which use per-transactions one-time passwords. These methods has been broken as well. So before I send it off, if people have a moment could you look at it and tell me if I'm missing something egregiously obvious? Tnx. There are already some commercial implementations (e.g. those following ZKA's Secoder standard). IBM apparently has something in the works called ZTIC. There used to be the FINREAD standard. Attacks which would break these authentication schemes have already been observed in the wild. There are various means to trick people into providing authorization for fraudulent transactions. Tell them that they have the opportunity to buy an expensive car at a fraction of the price, or offer them a very attractive financial investment, for instance. $50 per device doesn't seem to be much, but you actually need a huge amount of fraud that's actually prevented until it's cost-effective to roll this out. I don't think banks which offer real electronic banking (that is, something pretty much like Paypal, but with consumer rights) can legally tell high-risk from low-risk customers, so you're basically stuck with general rollout. While $50 per device may seem a bit on the high side, I think it's not unrealistic if you consider costs associated with personalization, branding, etc. There's also the issue that a large amount of online banking happens from work during the lunch hour. USB dongles with software installation requirements are problematic for those users. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Possibly questionable security decisions in DNS root management
* Jack Lloyd: On Sat, Oct 17, 2009 at 02:23:25AM -0700, John Gilmore wrote: DSA was (designed to be) full of covert channels. True, but TCP and UDP are also full of covert channels. And you better randomize some bits covered by RRSIGs on DS RRsets. Directly signing data supplied by non-trusted source is quite risky. (It turns out that the current signing schemes have not been designed for this type of application, but the general crypto community is very slow at realizing this discrepancy.) -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Possibly questionable security decisions in DNS root management
* Victor Duchovni: The optimization is for DDoS conditions, especially amplification via forged source IP DNS requests for . IN NS?. The request is tiny, and the response is multiple KB with DNSSEC. There's only one required signature in a . IN NS response, so it isn't as large as you suggest. (And the priming response is already larger than 600 bytes due to IPv6 records.) DNSKEY RRsets are more interesting. But in the end, this is not a DNS problem, it's a lack of regulation of the IP layer. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Possibly questionable security decisions in DNS root management
* John Gilmore: So the standard got sent back to the beginning and redone to deal with the complications of deployed servers and records with varying algorithm availability (and to make DSA the officially mandatory algorithm). Which took another 5 or 10 years. And it's still not clear that it works. No additional suite of algorithms has been approved for DNSSEC yet. Even the upcoming SHA-256 change is, from an implementors perspective, a minor addition to NSEC3 support because it has been tied to that pervasive protocol change for political reasons. forcibly paid by every domain owner Not really, most ccTLDs only pay out of generosity, if they pay at all (and if you make enough fuss at your favorite TLD operator's annual general meeting, they are likely to cease to pay, too). So the total extra data transfer for RSA (versus other) keys won't be either huge or frequent. Crap queries are one problem. DNS is only efficient for regular DNS resolution. Caching breaks down if you use non-compliant or compliant-to-broken-standards software. There's also the annoying little twist that about half of the client (resolver) population unconditionally requests DNSSEC data, even if they are incapable of processing it in any meaningful way (which means, in essence, no incremental deployment on the authoritative server side). There are some aspects of response sizes for which no full impact analysis is publicly available. I don't know if the 1024 bit decision is guided by private analysis. (It is somewhat at odds with my own conclusions.) -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: brute force physics Was: cleversafe...
* David Wagner: (Do note that factoring is not NP-complete.) It's also possible to factor an n-bit number in O(n^k) integer additions, substractions, multiplications, divisions and comparisons to zero, for some smallish fixed value of k (an observations which is due to Schönhage, IIRC). So you have to look very closely at your model of computation. It turns out integer arithmetic isn't the relevant one. Until scalable quantum computers are available, it will be difficult to forecast what the correct model will be. There might be practical limits not immediately apparent, similar to our lack of means to build machine registers which can store integers in the mathematical sense. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Judge orders defendant to decrypt PGP-protected laptop
* Stephan Somogyi: At 13:08 -0500 03.03.2009, Adam Fields wrote: When compelled to give out your password Unless I'm misunderstanding the ruling, Boucher is not being compelled to produce his passphrase (like he could under RIPA Section 49 in the UK), but he is being told to produce the unencrypted contents of the drive. Assuming I'm interpreting the ruling correctly, this seems little different than a judge approving a search warrant for a residence, whose execution could produce incriminating evidence that is usable in court. The difference is that having your residence searched does not require active cooperation from you. You don't even have to disclose all your residences which should be searched. Forcing a suspect to decrypt data is rather questionable because it is difficult to draw a line between decrypting, decompressing, selecting, and producing relevant data. FWIW, the case which sparked this thread is rather special because when the laptop was searched at the border, the files were visible to a border guard. I guess this constellation is highly unusual. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Property RIghts in Keys
[Moderator's note: I've been clamping down on the IP discussion since not much more really new was being said, but I'm allowing this through because it brings up an interesting side point -- I will reply to it to move to that discussion. --Perry] * Perry E. Metzger: However, a cert seems almost certainly *not* to be IP. 1) It can't be a trade secret, it is published. 2) It can't be patented. 3) It can't be copyrighted, it contains no creativity. 4) It can't be trademarked because the company named in the DN is long gone (It's quite strange that so many of the browser root certs use DNs which aren't correct anymore.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: What risk is being defended against here?
* Jerry Leichter: Any speculations (beyond bureaucracy at its finest)? I wild guess would be fraudulent testing organizations which claim to have been subject to fraud themselves, and the testing standards body answered with some sort of regulation. (For certain German language test instances at certain sites, there used to me impossibly high participation numbers. The alleged certificates of the results were probably simply forged, but that's where I got the idea from.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
* Jerry Leichter: I got in touch with the company and actually received intelligent responses both at their 800 number - I placed my order that way - and in a response from their customer service people. Most remarkable - almost all organizations ignore such communication. It's ironic that those who appear to be trying the hardest are being screwed over by the system that's currently in place - and will inadvertently be involved in training users to simply bypass yet another kind of bad cert warning. This is also why I don't want browser vendors to remove CAs for which they haven't got enough documentation, at least at this stage. After a few rounds of competitors attacking each other (and themselves as well, because who knows who controls some of the older private keys these days), the only CAs left are those where initiating RA procedures is sufficiently difficult for law-abiding citizens--and cost is a very likely discriminator in this area. And for most sites, those extra $$$ are better spent on hosting with some sort of security monitoring. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Raw RSA binary string and public key 'detection'
* Dirk-Willem van Gulik: Been looking at the Telnic (dev.telnic.org) effort. In essence; NAPTR dns records which contain private details such as a phone number. These are encrypted against the public keys of your friends (so if you have 20 friends and 3 phone numbers visible to all friends - you need 20 subdomains x 3 NAPTR entries under your master'). Aside from the practicality of this - given a raw RSA encrypted block and a list of public keys - is there any risk that someone could establish which of those public keys may have been used to create that block ? If the padding scheme is decent, this should not be possible without breaking RSA. However, the proposal limits keys to about 250*6 bits, which seems rather restrictive for RSA keys. I'm also concerned about reflective attacks were you ask someone who's trusted by the data owner to decrypt the data for you, possibly in an automated fashion. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: voting by m of n digital signature?
* James A. Donald: Is there a way of constructing a digital signature so that the signature proves that at least m possessors of secret keys corresponding to n public keys signed, for n a dozen or less, without revealing how many more than m, or which ones signed? What about this? Christian Cachin, Asad Samar Secure Distributed DNS http://www.zurich.ibm.com/security/dti/#dnsrepl Or do you require that potential signers must not be able to prove that they signed? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More US bank silliness
* Peter Gutmann: On a semi-related topic, it'd be interesting to get some discussion about FF3 removing the FF2 SSL indicators of the padlock and (more visibly) the background colour-change for the URL bar when SSL is active and replacing it with a spoof-friendly indicator that's part of the favicon, i.e. part of the attacker-controlled content. To keep this in perspective, note that you could disable the location bar altogether in FF2 (and that default changed in FF3), so the FF3 approach is actually an improvement. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OpenID/Debian PRNG/DNS Cache poisoning advisory
* Eric Rescorla: Why do you say a couple of megabytes? 99% of the value would be 1024-bit RSA keys. There are ~32,000 such keys. There are three sets of keys, for big-endian 32-bit, little-endian 32-bit and little-endian 64-bit. On top of that, openssl genrsa generates different keys depending on the existence of $HOME/.rnd (and -3 creates yet another set of keys, but this is more in the league of different key length). If the library is used for key generation (instead of the command line tool), different keys might result. On the other hand, the on-disk size would be comparable to the phishing filter database. Part of the problem of the CRL approach is that CAs usually have policies against obtaining private keys and therefore can't prove to the customer that their keys are compromised. And adding a CRL entry when the customer isn't convinced that they've got a problem is probably not a good idea, either. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Looking through a modulo operation
I've got a function f : S - X x S where S = (Z/2Z)**96 and X = (Z/2Z)**32. Suppose that s_0 is fixed and (x_i, s_i) = f(s_{i-1}). (f implements a PRNG. The s_i are subsequent internal states and the x_i are results.) Now f happens to be linear. I know the values of x_i, x_{i+1}, ..., x_{i+k} module N, for a fixed, known N. N is odd (but divisible by 9). Is it possible to recover s_i with reasonable effort (better than brute force, and k should be in the hundreds, not thousands)? And if yes, how? Prediction of candidates for x_{i+k+1} with high probability would be helpful, too. (Obviously, using f as an unpredictable PRNG is not a good idea. But if there's a real attack I can present, convincing the authors to replace it would be so much easier.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: “A Practical Attack on the MIFARE Classic”
* Karsten Nohl: The benefits clearly outweigh the risks since half a year after announcing the vulnerabilities, Mifare Classic is hopefully not used in any high security application anymore. Isn't this a bit of wishful thinking? The dynamics are probably very involved because you usually don't buy from NXP, but an integrated product from a reseller. An upgrade isn't a free patch, either, so it needs some sort of budgeting and planning. That being said, the chip should have been phased out years ago. But within half a year? No way. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
* Jack Lloyd: Perhaps there is something subtle here that is more dangerous than the well known problems, and all these source port randomization and transaction id randomization fixes are just a smokescreen of sorts for a fix for something Dan found. It's not a smokescreen, it's a statistical workaround. CERT/CC mentions this: | It is important to note that without changes to the DNS protocol, such | as those that the DNS Security Extensions (DNSSEC) introduce, these | mitigations cannot completely prevent cache poisoning. http://www.kb.cert.org/vuls/id/800113 A statement from the MaraDNS author [3]: MaraDNS is immune to the new cache poisoning attack. I think the CERT/CC statement is more approriate. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
* John Levine: CERT/CC mentions this: | It is important to note that without changes to the DNS protocol, such | as those that the DNS Security Extensions (DNSSEC) introduce, these | mitigations cannot completely prevent cache poisoning. Why wouldn't switching to TCP lookups solve the problem? It requires code changes on both types of servers, in order to make them more scalable. It's arguably more traffic than DNSSEC, but it has the large practical advantage that they actually work with deployed servers today. Implementors say that in many cases, their software as it's currently implemented can't take the load. It's not much worse than web traffic, that's why I think it can be made to work (perhaps easier with kernel support, who knows). But code changes are apparently required. And once you need code changes, you can roll out DNSSEC--or some extended query ID with 64 additional bits of entropy. On top of that, some operators decided not to offer TCP service at all. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
* Paul Hoffman: The take-away here is not that Dan didn't discover the problem, but Dan got it fixed. I haven't seen credible claims that the underlying issue can actually be fixed in the classic DNS protocol. There are workarounds on top of workarounds. A real fix requires more or less incompatible protocol changes, and at that point, it might be easier to deploy DNSSEC instead. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Secure voice?
* Allen: Interesting tidbit: http://www.epaynews.com/index.cgi?survey=ref=browsef=viewid=121516308313743148197block= Nick Ogden, a Briton who launched one of the world's first e-commerce processors in 1994, has developed a system for voice-signed financial transactions. The Voice Transact platform was developed by Ogden's Voice Commerce Group in partnership with U.S. speech software firm Nuance Communications. Looks a bit fishy because Nuance Communications hasn't issued a similar press release about their cooperation. There's also a total lack of technical content. And calling voice recordings biometrics is a bit of a stretch--you could ask your customer about color preferences and label it biometrics, too. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
* Arshad Noor: I may be a little naive, but can a protocol itself enforce proper key-management? I can certainly see it facilitating the required discipline, but I can't see how a protocol alone can enforce it. Any examples you can cite where this has been done, would be very helpful. As far as I understand it, you don't actually change protocols, which means that there's likely no way around this problem. The design paradigm we chose for EKMI was to have: 1) the centralized server be the focal point for defining policy; 2) the protocol carry the payload with its corresponding policy; 3) and the client library enforce the policy on client devices; In some form or another, don't all cryptographic systems follow a similar paradigm? No, there are things like digital cash and mental poker which do not work with a trusted third party. I think it's even possible to compute RSA signatures from a split private key in a way that is secure against byzantine failure (IOW, a certain number of key holders needs to cooperate to forge a signature or recover the private key). There's also quite a bit of research on operations on encrypted databases. Of course, you cannot actually run an ordinary web shop on top of such protocols because interfaces to the public and to the processors are essentially fixed. Cryptographically securing the middle end seems rather pointless to me because the public-facing front end is the component that causes most of the trouble. (And I'm not fully convinced that more encryption is the answer to that.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: German banks liable for phishing (really: keylogging) attacks
* Stephan Neuhaus: This article: http://www.spiegel.de/wirtschaft/0,1518,563606,00.html (sorry, German only) describes a judgment made by a German district court which says that banks are liable for damages due to phishing attacks. District court may be a bit misleading, it's the entry-level court for this particular type of dispute, at the lowest place in the hierarchy. In the case in question, a customer was the victim of a keylogger even though he had the latest anti-virus software installed, The latest part is not clear. I'm also puzzled that forensics could not recover the actual malware. (A keylogger alone is not quite good enough--you need to disrupt transmission of the one-time password to the bank's server if you want to to use the password later on. OTOH, the disruption component does not necessarily appear in AV descriptions.) and lost 4000 Euro. The court ruled that the bank was liable because the remittance in question had demonstrably not been made by the customer and therefore the bank had to take the risk. Well, the open question is not whether the bank has to take the risk (after all, the transaction has been successfully disputed, even before the case went to court), but if the customer was negligent and needs to share some of the damage. For instance, if a computer takes 15 minutes to boot, constantly displays pop-up ads, and sporadically shows error messages during browsing, I would hope that it's reasonable to assume that the machine is not safe for on-line banking--no matter what the anti-virus says about the state of the machine. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ITU-T recommendations for X.509v3 certificates
* Peter Gutmann: Or is it unreasonable to expect that the specs match what is actually needed for interoperability with existing implementations (mostly in the TLS, S/MIME area)? There is very little correspondence between PKI specs and reality. I should have written that my main goal was to extract the public key material, and perhaps the validity period. I want to use the certificates as interoperable public key containers, mainly in order to be able to rely on proven TLS implementations for encryption and authentication. The brokenness in X.509 implementations creates a self-sustaining cycle in which applications that accept certs are more or less oblivious to anything that's in the cert (beyond basic stuff like correct formatting and encoding, and so on), so you can get away with almost anything (and then in turn because apps will accept anything, cert creators can create arbitrarily broken certs without being caught out by it, so the cycle is self-sustaining). I guess parsing X.509 certs to derive further semantic content is comparable to mail header parsing. That is a futile exercise, too, but sometimes unavoidable (for finding spam injection points, for instance). But to be honest, I really don't see the point of extracting further data from the certificates. I can't reach OCSP servers and CRL distribution points anyway because they are firewalled off. I still need to map a DN to some application-specific entity, and I need to grant specific capabilities to it because I don't want to grant blanket permission to the CAs involved--but this means I can directly bind this metadata to the certificate, using the DN instead does not really simplify set-up. The lack of indirection makes key rollover more difficult, granted, but you don't have to deal with broken random number generators every other day, so I'm not sure if this is such a bad trade-off. If you want to be really lazy, use an X.509v1 cert where you don't even need to bother with extensions. A downside (?) of this is that some applications will treat it as a CA root cert. I've got a couple of X.509v1 certs with extensions in production use, which are a bit difficult to phase out. 8-( Turns out that this is not so interoperable after all. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
* Peter Gutmann: [1] Show of hands, how many people here not directly involved with X.509 work knew that the spec required that all extensions in CA root certificates (trust anchors in recent X.509 jargon) be ignored by an implementation? So if you put in name constraints, key usage constraints, a policy identifier, etc, then a conforming implementation is supposed to look at them, throw them away, and proceed as if they weren't there? Are you sure that the constraints are not supposed to be applied when the root certificate is actually processed, after its signature has been verified by the trust anchor? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
* Arshad Noor: The author of an article that appeared in InformationWeek this week (June 30, 2008) on Enterprise Key Management Infrastructure (EKMI): http://www.informationweek.com/shared/printableArticle.jhtml?articleID=208800937 states the following: There are, of course, obstacles that must still be overcome by EKMI proponents. For example, the proposed components are somewhat simple by design, which concerns some encryption purists who prefer more complex protocols, on the logic that they're more difficult to break into. First of all, a simple SKSML request for a symmetric key is a whopping 77 lines of SOAPWSS/whatever XML; the server response is 62 lines even without the container. If this is not enough to make every complexity fanboy happy, I don't know what can do the trick. On a more serious note, I think the criticism probably refers to the fact that SKSML does not cryptopgrahically enforce proper key management. If a participant turns bad (for instance, by storing key material longer than permitted by the protocol), there's nothing in the protocol that stops them. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
* Peter Gutmann: Florian Weimer [EMAIL PROTECTED] writes: * Peter Gutmann: [1] Show of hands, how many people here not directly involved with X.509 work knew that the spec required that all extensions in CA root certificates (trust anchors in recent X.509 jargon) be ignored by an implementation? So if you put in name constraints, key usage constraints, a policy identifier, etc, then a conforming implementation is supposed to look at them, throw them away, and proceed as if they weren't there? Are you sure that the constraints are not supposed to be applied when the root certificate is actually processed, after its signature has been verified by the trust anchor? Yup. The app is supposed to read the cert, parse and process the extensions, and then throw them away. The text from the spec is: 3.3.60 trust anchor: A trust anchor is a set of the following information in addition to the public key: algorithm identifier, public key parameters (if applicable), distinguished name of the holder of the associated private key (i.e., the subject CA) and optionally a validity period. The trust anchor may be provided in the form of a self-signed certificate. A trust anchor is trusted by a certificate using system and used for validating certificates in certification paths. Rendered into English, that says take the pubic key, owner name, and validity period, and ignore everything else in the cert. Let me rephrase my remark: The trust anchor is conceptually separate from a root CA certificate. It is only used to validate it the CA certificate. Nothing in that section gives you permission to ignore extensions on the CA certificate (skipping the first entry in the certification path). In addition, the trust anchor cannot be used directly to verify certificates issued by the CA because the subject DN does not match. Ergo, the extensions on the CA certificate are still in force. Luckily no sane implementation pays any attention to this nonsense :-). I think your interpretation actually leads to a non-compliant implementation. Obviously, wording of that section could be less confusing. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: skype claims they have no technical means to assist wiretapping
* Perry E. Metzger: Excerpt: Jennifer Caukin, Skype's director of corporate communications replied to us: We have not received any subpoenas or court orders asking us to perform a live interception or wiretap of Skype-to-Skype communications. In any event, because of Skype's peer-to-peer architecture and encryption techniques, Skype would not be able to comply with such a request. http://news.cnet.com/8301-13578_3-9963028-38.html?part=rsstag=feedsubj=TheIconoclast It's sort-of industry practice to wiretap peer-to-peer voice-over-IP environments by asking the naming service not to signal the availability of a direct, end-to-end, but to fall back to some media gateway (which is there for interoperability with the phone network anyway). I'm surprised that is compliant with regulatory requirements, but apparently, it is. So, at that point, it wouldn't be Skype-to-Skype anymore. It also solves the problem of getting access to the media stream (which is the difficult part for traditional VoIP systems, which are encrypted only in the marketing brochures). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RIM to give in to GAK in India
* Dave Korn: In a major change of stance, Canada-based Research In Motion (RIM) may allow the Indian government to intercept non-corporate emails sent over BlackBerrys. Research In Motion (RIM), the Canadian company behind the BlackBerry handheld, has refused to give the Indian government special access to ** its encrypted email services. [ ... ] According to the Times of India, the company said in a statement: The BlackBerry security architecture for enterprise customers is purposefully designed to exclude the capability for RIM or any third party to read encrypted information under any circumstances. We regret [ Hmm, two contradictory stories, whoever woulda thunk it? There's probably some politicking going on, mixed up with marketeering and FUD-spinning. ] If you look closely, there's no contradiction. Non-enterprise customers don't run their own gateway, so RIM just acts as a telco, which naturally has got access to all the data. The Indian government doesn't need special access, either, because Lawful Intercept services etc. aren't that special anymore. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [ROS] The perils of security tools
* Peter Gutmann: Debian seem to be particularly bad for not reporting changes to maintainers, This shouldn't be the case. There's a clear policy that non-packaging changes (basically, anything beyond trivial build fixes and pathname changes for FHS compliance) should be submitted upstream. I've got a few packages that are contained in a number of distros and I notice via occasional Google searches for semi-related items that I'm getting hits to CVS change logs for my code where someone is repeatedly re-applying some patch to every new version I release. If you name names, we can certainly fix that. I couldn't figure out what packages are affected on Debian's side. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [ROS] The perils of security tools
* Ben Laurie: Jonathan S. Shapiro wrote: Ben: I'm idly curious. Was this exceptionally unusual case where use of uninitialized memory was valid properly commented in the code? It's mentioned in the manpage for a function that eventually calls the function that was (correctly) patched--through a function pointer. The incorrectly patched function looks somewhat parallel, but it's not. There is no local comment in the source code for this particular case of uninitialized memory access. Well. Kinda. It didn't really explain why: i=fread(buf,1,n,in); if (i = 0) break; /* even if n != i, use the full array */ RAND_add(buf,n,(double)i); There is in theory a second place where it might used an uninitialised buffer, but I think in practice that never happens. AFAIK, this piece of code is not really related and rarely used outside OpenSSL itself. And in the OpenSSL case, the fread call always overwrites the whole buffer, it seems. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [ROS] The perils of security tools
* Ben Laurie: I must confess that I said that because I did not have the energy to figure out the other routes to adding entropy, such as adding an int (e.g. a PID, which I'm told still makes it in there). The PID dependency is there because of the need for fork support--obviously, the PRNG must return a different key stream in the parent and child process, but the two cannot communicate with each other. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OpenSparc -- the open source chip (except for the crypto parts)
* Perry E. Metzger: Marcos el Ruptor [EMAIL PROTECTED] writes: Nonsense. Total nonsense. A half-decent reverse engineer does not need the source code and can easily determine the exact operation of all the security-related components from the compiled executables, extracted ROM/EPROM code or reversed FPGA/ASIC layout I'm glad to know that you have managed to disprove Rice's Theorem. Call me a speciest, but it's not clear if Rice's Theorem applies to humans. While Marcos' approach is somewhat off the mark (source-code equivalent that works for me vs. conformance of potentially malicious code to a harmless spec), keep in mind that object code validation has been performed for safety-critical code for quite a while. The idea is that code for which some soundness property cannot be shown simply fails validation. It doesn't matter if the validator is not clever enough, or if the code is actually bogus. (And for most (all?) non-trivial software, source code acquisition costs are way below validiation costs, so public availability of source code is indeed a red herring.) -- Florian Weimer[EMAIL PROTECTED] BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How is DNSSEC
* James A. Donald: From time to time I hear that DNSSEC is working fine, and on examining the matter I find it is working fine except that Seems to me that if DNSSEC is actually working fine, I should be able to provide an authoritative public key for any domain name I control, and should be able to obtain such keys for other domain names, and use such keys for any purpose, not just those purposes envisaged in the DNSSEC specification. Can I? It is not apparent to me that I can. DNS is hierarchical. Nobody wants the DoD (who are traditionally quite good at keeping secret data) or any other institution to keep keys at important positions in the hierarchy. And nobody wants to be the keep irreplaceable keys, either, which makes introduction at levels below the DNS root difficult. This is not a problem with the browser PKI because it's possible to replace root certificates with a software update (which can be automated in many cases). And as Bill pointed out, it's not possible to use the DNS keys directly. However, you can bootstrap another key based on data from DNS. This even works without DNSSEC. DKIM does that, for instance. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL/TLS and port 587
* Ed Gerck: The often expressed idea that SSL/TLS and port 587 are somehow able to prevent warrantless wiretapping and so on, or protect any private communications, is IMO simply not supported by facts. Huh? Have you got a source for that? This is he first time I've heard of such claims. Message submission over 587/TCP gives the receiver more leeway regarding adjusting message contents to police (add a message ID, check the Date and From headers, and so on). The abuse management contract is also different: once you accept a message over 587/TCP, it's your fault (and your fault alone) if this message turns out to be spam. There's nothing related to confidentiality that I know of. -- Florian Weimer[EMAIL PROTECTED] BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: patent of the day
* Saqib Ali: can anyone please shed more light on this patent. It seems like a patent on the simple process of cryptographic erase.. Exactly. Niels Provos, Encrypting Virtual Memory, USENIX Security 2000, looks like something pretty close to prior art: | We investigate several alternative solutions to prevent confidential | data from remaining on backing store, e.g. erasing data physically | from the backing store after pages on it become unreferenced. | However, we find that encryption of data on the backing store with | volatile random keys has several advantages over other approaches: | | * The content of a page disappears when its respective encryption key | is deleted, a very fast operation. [...] AFAICS, the patent does not reference the paper. -- Florian Weimer[EMAIL PROTECTED] BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Question on export issues
* Ivan Krstić: We've recently had to jump through the BIS crypto export hoops at OLPC. Our systems both ship with crypto built-in and, due to their Fedora underpinnings, allow end-user installation of various crypto libraries -- all open-source -- through our servers. It was a nightmare; the regulations and paperwork appear to be designed for the use case of individual applications that utilize a handful of primitives and attempt to keep the user from examining or modifying the utilized crypto. Trying to fit a Linux distribution into this model proved, er, challenging. Debian has been filing notices for crypto export for years (at BXA for some time; nowadays, it's likely BIS). So far, nobody there has complained that what is being done is insufficient. Here are some details: http://www.debian.org/legal/cryptoinmain The actual process may have changed a bit over the years. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PlayStation 3 predicts next US president
* William Allen Simpson: Assuming, Dp := any electronic document submitted by some person, converted to its canonical form Cp := a electronic certificate irrefutably identifying the other person submitting the document Cn := certificate of the notary Tn := timestamp of the notary S() := signature of the notary S( MD5(Tn || Dp || Cp || Cn) ). Of course, I'm sure the formula could be improved, and there are traditionally fields identifying the algorithms used, etc. -- or something else I've forgotten off the top of my head -- but please argue about the actual topic of this thread, instead of incessant strawmen. The problem is not the outer MD5 (explicitly mentioned in your description), but that Dp is typically (well, to the extent such services have been deployed) some kind of hash. This has got the advantage that the timestamping service does not need to know the contents of the document. On the other hand, if the timestamping service archives Dp and can reveal it in a dispute, evil twins can be identified and analyzed -- which undermine the submitting party's claim that it submitted the second document instead of the first. Of course, this is actually cheating by substituting proven protocols for fragile cryptography. And the result is still open to interpretation, but all evidence is. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Seagate announces hardware FDE for laptop and desktop machines
* Ivan Krstić: On Oct 3, 2007, at 4:39 AM, Florian Weimer wrote: But this exhibits an issue with disk-based encryption: you can't really know what they are doing, and if they are doing it right. (Given countless examples of badly-deployed cryptography, this isn't just paranoia, but a real concern.) Precisely. If you're keeping secrets from your nosy siblings and coworkers, hardware FDE is more than adequate. If you have reason to believe someone skilled and resourceful might really want your data, you almost certainly have no business using a blackbox encryption system operating in a way that's not publicly documented -- even if the system is buzzword-compliant -- and implemented by a company (hard disk vendor) where crypto is about as far from their core competency as you can get. I think the really interesting question is what happens when you lose a FDE-ed hard drive. Do you still need to publish the incident and contact potentially affected individuals? If the answer is no, I'm sure this technology will be quickly adopted, independently of its actual implementation. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Seagate announces hardware FDE for laptop and desktop machines
* Simon Josefsson: One would assume that if you disable the password, the data would NOT be accessible. Making it accessible should require a read+decrypt+write of the entire disk, which would be quite time consuming. It may be that this is happening in the background, although it isn't clear. Perhaps this section wasn't updated? A password-based lock method is present in most laptop drives today. But this exhibits an issue with disk-based encryption: you can't really know what they are doing, and if they are doing it right. (Given countless examples of badly-deployed cryptography, this isn't just paranoia, but a real concern.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: interesting paper on the economics of security
* Hal Finney: Information on the quality of AV and other security products is widely available on the net, in magazines and other places that consumers might look for reviews and comparisons. This is completely unlike the situation with individual used cars. I don't see this analogy as particularly accurate. I don't, either, but for a different reason. The tests I've seen are mostly worthless because they do not weigh their results based on the actual threats a typical user faces. After all, these days, the goal is not to avoid the embarrassments caused by a virus infection or a spam bot operating from your network, but to avoid actual loss due to fraud (or perceived fraud). Mere detection rates do not reflect that.[1] So there is certainly a lack of information. But in contrast to the used care market, the seller doesn't really know how useful their products are to the buyer, either. Some vendors (those offering spam filtering as a service, for instance) might have a better idea than their customer what's happening, but for the broader market, return on security investment is a completely imaginary figure for both buyers and sellers. Only if you look at things like pro-forma regulatory compliance, it's possible to obtain hard facts. [1] This might sound like marketing gibberish from some of the big-name vendors, but I think it's true. It does not mean that a product which looks bad in a synthetic test gives adequate results in the real world, though. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How the Greek cellphone network was tapped.
* John Ioannidis: Florian Weimer wrote: It's also an open question whether network operators subject to interception requirements can legally offer built-in E2E encryption capabilities without backdoors. You probably meant device vendors, not network operators. The whole *point* of E2E security is that network operators are not involved. If they were, it wouldn't be end-to-end! Uh-oh, no. The protocol characteristics don't change depending on who is selling you the device. Many telcos have an aversion to end-to-end protocols. Building reliable networks for ill-behaving end systems has been a pretty recent idea (and we are still far away from a complete solution). There aren't any interception requirements for device vendors, either, at least not any I'm aware of. They aren't telcos. Projects like OpenMoko should not be affected. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How the Greek cellphone network was tapped.
* Ian Farquhar: Crypto has been an IP minefield for some years. With the expiry of certain patents, and the availability of other unencumbered crypto primitives (eg. AES), we may see this change. But John's other points are well made, and still valid. Downloadable MP3 ring tones are a selling point. E2E security isn't (although I've got to wonder about certain teenage demographics... :) It's also an open question whether network operators subject to interception requirements can legally offer built-in E2E encryption capabilities without backdoors. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: UK RIPA Pt 3
* Peter Fairbrother: I forgot to mention that Pt.3 also includes coercive demands for access keys - so for instance if Mr Bill Gates came to the UK, and if there was some existing question about Microsoft's behaviour in some perhaps current EU legal matter, Mr Gates could be required to give up the keys to the Microsoft internal US servers. Or go to jail. Well, if Mr Gates is a witness and not a suspect, such coercive measures are well within the legal framework of most countries. As a witness, you must testify. It simply does not matter if the information you are asked to provide is encrypted, or is stored in a database and needs significant preprocessing to obtain. It would be quite surprising if this was any different in the UK. So it's purely the self-incrimination part that is questionable from a legal POV. I think this bears repeating because we face a similar discussion in Germany regarding covert data seizure using technological measures, and the discussion focuses almost entirely on the technological measures. But the legal obstacle is just the covertness. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Hackers target C-level execs and their families
* Udhay Shankar N.: Hasn't this already been going on a while? I'm only surprised there hasn't been a big public incident yet. Doesn't this one count? | According to Chief Superintendent Arye Edelman, head of the Tel Aviv | fraud squad, which ran the investigation, Haephrati used two methods | to plant his malicious software (or malware) in the target | computers. One was to send it via e-mail. The other was to send a disk | to the target company that purported to contain a business proposal | from a well-known company that would arouse no suspicions. Then, when | an employee loaded the disk to view the proposal, the Trojan horse | would infect his computer. http://www.haaretz.co.il/hasen/pages/ShArt.jhtml?itemNo=581790contrassID=Cd=1 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
* Ian G.: Banks are the larger and more informed party. But not as far as client-side fraudulent activity is concerned. After all, the attacked systems are not under their administrative control. They need to provide systems that are reasonable given the situation (anglo courts generally take this line, when pushed, I'm unsure what continental courts would do with that logic). We have courts that are traditionally bank-friendly, and courts that aren't. While we do not heavily rely on case law, it's a bit of luck which one sets the precedent (which will eventually help to shape legislation). And what's worse, the situation is so unstable that a case that gets decided in favor of one party might actually end up shifting the risks to the other party in the long run because the environment keeps changing rapidly. Customers aren't in any position to dictate security requirements to banks. And vice versa. It might even happen that we see competion from foreign, EU-based banks that offer transactions without the safeguards German banks have agreed to among each other. We'll see if this increase in convenience turns out to be a major selling point. Unfortunately for the banks, there is a vast body of evidence that we knew and they knew or should have known that the PC was insecure [1]. I think the extent to which end users, hardware and software manufacturers, and ISPs don't care about compromised machines was a real surprise. If there's malware on the PC, it's not just banking that is affected. You'd expect people to do something about it, but no one does without significant external pressure. And if you look closely at which attacks security experts predict (and not just self-proclaimed ones!), and which actually materialize, there are significant differences. These differences are usually mulled over by ambiguous terminology, but the gap is there. So, by fielding a system -- online commerce -- with a known weakness, they took responsibility for the fraud (from all places). They didn't build the Internet, they didn't provide the PC and its software, they don't even run the most-frequented online commerce applications. But in a moment of weakness, they started to take responsibility. And the real difficulties began. For a rare security success story, look at how ISPs manage to sell a completely insecure product which puts their customers at significant risk, and take virtually no blame for it. And technologically, banks are not that different from mail providers. They just pass around messages. Why should they be responsible for their content, if ISPs aren't? Now they are in the dilemma. The customer can't provide evidence of the fraud, because the system fielded doesn't support it (it's login authentication not transaction authorisation). Non-digital crime faces the same problem. You haven't got a cryptographically secured audit trail, either. But clues can still be found. [1] To my knowledge, continental banks knew of the risks and acted in the 90s, then scaled it down because the risks proved overstated. Brit banks knew of the risks and didn't care. American banks didn't care. The American banking system is mainly protected by its obsolescence. It's not an end-to-end transaction system, unlike the European ones. [2] Again, continental banks are shifting to SMS authorisation (dual-channel) ... Brit banks are unsure what to do ... The new APACS standard should be a huge leap forward for the UK. AFAIK, it includes the limited form of transaction signing that is possible within the constraints. Of course, it's still not foolproof, but the non-fools can actually detect a compromised terminal. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
* Anne Lynn Wheeler: In the mid-90s, financial institutions looking at the internet for online, commercial banking and cash management (i.e. business equivalent to consumer online banking) were extremely conflicted ... they frequently were almost insisting on their own appliance at the business (and low-end of SOHO at least overlaps high-end of consumer online banking). Well, in 1994, German Postbank already had 300,000 online banking customers. (To put this into perspective, there are somewhere around 3 million online customers today, and this was well before the Internet took off in Germany.) On top of that, there were other forms of digital banking that were mainly used by business customers, such as transactions submitted on floppy disks. Various of the PC-based dedicated financial applications go to quite some lengths to compensate for kind of vulnerabilities typically associated with browser activity. For instance, instead of relying on a trusted third party to certify that some remote location really has a valid digital certificate, they have a trusted repository of valid financial institutions. Oh really? In Germany, early digital banking had no cryptographic protection at all. Integrity and confidentiality were inherited from the underlying phone system. There were no end-to-end digital signatures. Nothing. Just a one-time password for each transaction, but the password was not tied to the transaction in any way. This has the added benefit of eliminating the horribly complex and vulnerable PKI-type of operation Except that there aren't any attacks on the browser PKI. That's part of the reason why the certificate prices plummeted. 8-/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
* Jerry Leichter: OK, I could live with that as stated. But: The code also adds: We reserve the right to request access to your computer or device in order to verify that you have taken all reasonable steps to protect your computer or device and safeguard your secure information in accordance with this code. If you refuse our request for access then we may refuse your claim. The delay between when you were defrauded and when they request access is unspecified. But if you don't do this, customers can repudiate *any* transaction, even those they have actually issued. In other words, you run into tons of secondary fraud, where people claim they are victims, but they actually aren't. Customers need to provide some evidence that they are actually victims. Just claiming the virus did it can't be sufficient. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: IBM Lost Tape(s)
* John Ioannidis: I wonder how much it cost them to find current addresses for everybody so we could be notified. I guess it's pretty easy because your personal information is available to so many organizations, without any safeguards. Obviously, they had your social security number (it's only the backup that was lost), so they could work from that. And more data is being collected: If you participate in their monitoring program, Kroll can associate an email address with your SSN, which is probably something that wasn't possible before. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
* Victor Duchovni: But no one is issuing certificates which are suitable for use with SMTP (in the sense that the CA provides a security benefit). As far as I know, there isn't even a way to store mail routing information in X.509 certificates. There is no need to store routing information: http://www.postfix.org/TLS_README.html#client_tls_limits http://www.postfix.org/TLS_README.html#client_tls_levels http://www.postfix.org/TLS_README.html#client_tls_verify http://www.postfix.org/TLS_README.html#client_tls_secure The short summary is that full security is only available when the receiving MX hosts have certs that match the recipient domain, Which runs into the same problem as HTTP because the set of recipient domain names is not known at the time the TLS handshake occurs. or the sender is willing to manually (in his MTA configuration) bind the recipient domain to the subject names (or in 2.5 fingerprints) of the appropriate MX hosts. And if you use fingerprints, there is no need for PKI. And in my experience, PKI doesn't buy you that much if you need to configure per-client privileges and things like that. Using the DN instead of a fingerprint doesn't seem to be worth the trouble. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
* Victor Duchovni: That's good of you not to expect it, given that zero of the major CAs seem to support ECC certs today, and even if they did, those certs would not work in IE on XP. We are not talking about this year or next of course. My estimate is that Postfix releases designed this year, ship next year, are picked up by some O/S vendors the year after and shipped perhaps a year after that, then customers take a few years to upgrade, ... So for some users Postfix 2.5 will be their MTA upgrade in 2011 or later. So we need to anticipate future demand by a few years to be current at the time that users begin to use the software. But no one is issuing certificates which are suitable for use with SMTP (in the sense that the CA provides a security benefit). As far as I know, there isn't even a way to store mail routing information in X.509 certificates. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: no surprise - Sun fails to open source the crypto part of Java
* Ian G.: My worry was that they hadn't open sourced the architecture component, the part that wasn't meant to be replaceable. However even if open sourced, Sun may still wield a stick over the providers by insisting that they manage the signing process for the providers. The signing provider PKI is a joke, it's sole purpose is to ensure that Sun has got a fax allegedly from you in which you promise that you will comply with applicable export regulations. The root CA list shipped in OpenJDK should be empty at this stage (at least this is mentioned somewhere on the OpenJDK web page) because it is not clear what the criteria are to populate it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: no surprise - Sun fails to open source the crypto part of Java
* Ian G.: Does anyone know what Sun failed to opensource in the crypto part of Java? The Sun JCE provider appears to be missing, which means that few cryptographic algorithms are actually implemented in the source drop. All the symmetric encryption algorithms are missing, for instance. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Public key encrypt-then-sign or sign-then-encrypt?
* Travis H.: Also there's a semantic issue; am I attesting to the plaintext, or the ciphertext? It's possible the difference could be important. With sign, then encrypt, it's also possible that the receiver decrypts the message, and then leaks it, potentially giving the impression that the signer authorized the disclosure. There has been a fair bit of buzz about this confusion. But the lesson from that seems to be that signature semantics are very hard to agree upon, and most marginally successful standards sidestep the issue anyway, acting as a mere transport protocol. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Was a mistake made in the design of AACS?
* Perry E. Metzger: This seems to me to be, yet again, an instance where failure to consider threat models is a major cause of security failure. Sorry, but where's the security failure? Where can you buy hardware devices that can copy HD disks? Or download software that does, with a readily usable interface? In that sense, even CSS hasn't really been broken. Even the flurry of DMCA takedown notices isn't necessarily a bad move. It might help to shape the future of how access to content is regulated in some very particular way. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
* Peter Gutmann: Dave Korn [EMAIL PROTECTED] writes: Surely if this goes ahead, it will mean that DNSSEC is doomed to widespread non-acceptance. I realise this is a bit of a cheap shot, but: How will this be any different from the current situation? You can see that the keys change and draw your conclusions. Right now, you need to watch the actual data, which is a bit unwieldy (2.5% daily change rate for .COM/.NET and things like that). By the way, who else has expressed willingness to hold the key, under reasonable conditions? Would it be preferable if some non-governmental organization held the keys, after receiving an indemnification guarantee from Congress? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
* Simon Josefsson: However, in practice I don't believe many will trust the root key alone -- for example, I believe most if not all Swedish ISPs would configure in trust of the .se key as well. There are some examples that such static configuration is extremely bad. Look at the problems with bogon filters, or how long decommissioned root server IP addresses continue to receive queries. It's not a problem if you do this for .SE as a Swedish ISP because you notice quickly that something is amiss. But if too many people do this for most TLDs, it will become practically impossible to change keys. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Failure of PKI in messaging
* James A. Donald: Obviously financial institutions should sign their messages to their customers, to prevent phishing. The only such signatures I have ever seen use gpg and come from niche players. Deutsche Postbank uses S/MIME, and they are anything but a niche player. It doesn't help against phishing in the sense that deters the attackers and reduces the PR impact. I have heard that the reason no one signs using PKI is that lots of email clients throw up panic dialogs when they get such a message, and at best they present an opaque, incomprehensible, and useless interface. Has anyone done marketing studies to see why banks and massively phished organizations do not sign their messages to their customers? Why bother, when it's been shown it doesn't make a difference? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free WiFi man-in-the-middle scam seen in the wild.
* Perry E. Metzger: If you go over to, say, www.fidelity.com, you will find that you can't even get to the http: version of the page any more -- you are always redirected to the https: version. Of course, this only helps if users visit the site using bookmarks that were created after the switch. If they enter fidelity.com (or even just fidelity) into their browsers to access it, switch to HTTPS won't help at all. Perhaps this explains why someone might think that serving the login page over HTTPS is just security theater. In the same we use use HTTPS and are still vulnerable to MITM attacks department, there's the really old issue of authenticating cookies which are not restricted to HTTPS, but will be happily sent over HTTP as well. *sigh* Apart from that, the article you linked to does not even mention actual attacks with an identity theft motive. What's worse, the suggested countermeasures don't protect you at all. Ad-hoc networks are insecure, and those with an access point are secure? Yeah, right. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fwd: [FDE] Largest Ever Single FDE implementation
* Saqib Ali: You can read about the competition, which will come to a close in the next 90 days at: http://www.fbo.gov/spg/USAF/AFMC/ESC/FA8771-07-R-0001/Attachments.html In the process, the following document has been published: http://www.herbb.hanscom.af.mil/download.asp?rfp=R1450FileName=2006_12_20_DAR_Vendor_Day_List__2_.xls Is it standard practice to publish so many contact details of those who are involved in the bidding process? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ATM vulnerability
I hesitate to use the syllable crypto in describing this paper, but those who have not seen it may find it interesting. http://www.arx.com/documents/The_Unbearable_Lightness_of_PIN_Cracking.pdf Or profitable. In a weired sense, yes. If I understand the paper correctly, the authors show that given the current protocol requirements, spending money on HSMs is a total waste. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Hamiltonian path as protection against DOS.
* James A. Donald: DOS is now a major problem - every business, online games, money movers, banks, porno sites, casinos, now comes under DOS attack from extortionists. How do Hamiltonian paths protect against the H.R.4411 attack? (Part of the DoS problem online casinos face is that due to their activity, which was illegal before, they are extremely reluctant to approach law enforcement about this matter.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Circle Bank plays with two-factor authentication
* Steven M. Bellovin: Again -- the scheme isn't foolproof, but it's probably *good enough*. I agree that if you consider this scheme in isolation, it's better than plain user names and passwords. But I wonder if it significantly increases customer confusion because banks told their customer that they won't *ask* for credentials via email, but now a bank is *sending* them by email. As for keystroke loggers -- the bad guy would have to capture enough table entries that they'd have a reasonable probability of seeing challenges they'd already received. If this technology enters the attacker's radar screen, the keystroke logger would be changed to scan mail folders for the message sent by the bank. Or it would alter the login page to display an empty matrix, without any further explanations. 8-/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Locating private keys in RAM?
* Douglas F. Calvert: I remember seeing a paper about identifying private keys in RAM. I thought it was by Rivest but I can not locate it for the life of me. Does anyone remember reading something like this? The basic operation was to identify areas in RAM that had certain characteristics such as random bits and identifiable key headers... Any help would be greatly appreciated... From findkey.c in The Coroner's Toolkit: /* A. Shamir and N. van Someren, Playing Hide and Seek With Stored /* Keys, 1998. /* http://www.ncipher.com/products/files/papers/anguilla/keyhide2.pdf. (The web page no longer exists, though.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Recovering data from encrypted disks, broken CD's
* Steven M. Bellovin: I wonder how accurate this is. It's certainly true that some drives have vendor passwords to unlock them. It's hard to see how they could break through (good) software encryption, A lot of software tends to create temporary files in random places. If you don't encrypt the whole disk (including swap space and the suspend-to-disk area), plaintext might be written to the disk and can be recovered even though the actual cryptography is sound. This assumes that transparent decryption is used--the situation is worse if you need to create a temporary plaintext copy on disk before you can actually process the data. (Now I only need to figure out why sequential disk I/O takes such a significant hit when using dm-crypt. *sigh*) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NIST hash function design competition
* Travis H.: On 7/11/06, Hal Finney [EMAIL PROTECTED] wrote: : So what went wrong? Answer: NIST failed to recognize that table lookups : do not take constant time. âTable lookup: not vulnerable to timing : attacks, NIST stated in [19, Section 3.6.2]. NIST's statement was, : and is, incorrect. That's interesting, since it is in line with conventional reasoning about algorithms. I've skimmed his paper, and I've taken a class on computer architecture and I haven't the foggiest idea where the variable timing comes from. Does anyone know if any of the following account for the phenomenon? 1) cache fills as we ascend through memory 2) additions (base+index) taking non-constant time (could be fixed with pointers if we're going sequentially) 3) virtual memory considerations (e.g. fetching new a page for a higher address) 4) TLB misses Is this about Colin Percival's work? IIRC, it's mainly about shared associative caches which leak information about what addresses are being cached across trust boundaries. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Greek cellular wiretapping scandal
* Steven M. Bellovin: I have more than a passing aquaintance with the complexity of phone switch software; doing that was *hard* for anyone, especially anyone not a switch developer. Isn't Ericsson's switching software written in Erlang, is highly modular and officially supports run-time code replacement (like many COBOL systems, but unlike, say, traditional IOS)? This means that at least no rootkit is needed. You just replace the parts of the system you are interested in using the standard system interfaces intended for this purpose. Of course, the complexity of the attack is still significant. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
* Anne Lynn Wheeler: Florian Weimer wrote: FINREAD is really interesting. I've finally managed to browse the specs, and it looks as if this platform can be used to build something that is secure against compromised hosts. However, I fear that the support costs are too high, and that's why it hasn't caught on in retail online banking. if they can build a $100 PC ... you think that they could build a finread terminal for a couple bucks. sometimes there are issues with volume pricing ... you price high because there isn't a volume and there isn't a volume because you price high. The problem is not hardware costs, but support costs. You really don't want to outsource this to the cheapest call center in the world. Even relatively simple changes like the indexed TAN rollout are rather expensive as a result. there is one issue missing from the actual FINREAD specification. when we were doing X9.59 financial standard ... we allowed for a digital signature for authentication as well as for a digital signature from the environment that the transaction was performed in. the issue from a relying party standpoint ... is what assurances do they have as to the actual environment that a transaction was executed in. consumers could claim they were using a FINREAD terminal when they weren't. counterfeit FINREAD terminals could be out in the wild. You mean something like remote attestation? I find it hard to believe that this capability is available today in a relatively open environment, on a platform supporting multiple applications developed by different applications. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
* Ka-Ping Yee: Passpet's strategy is to customize a button that you click. We are used to recognizing toolbar buttons by their appearance, so it seems plausible that if the button has a custom per-user icon, users are unlikely to click on a spoofed button with the wrong icon. Unlike other schemes, such as special-looking windows or a custom image shown with the login form, this strategy requires the user to directly interact with the customized UI element. I'm not sure if this can't be defeated by something like a Choose a new funny icon for your security button! offer. 8-( However, this points to a more general problem: We have no real-world studies how users make their day-to-day trust decisions when using the Internet. For example, if I need to judge the trustworthyness of a web page, a large factor is the way I got there. If it was a link from an email message that looks like spam, or something that was returned by a search engine, I'm rather sceptical. This is why those 80% can't tell a phishing page apart from the real one web-base studies are quite worthless. They simply do not present enough context. | The field for entering your master password isn't labelled Enter | your password: - instead, it's labelled Enter Betty's secret:. | Since the persona differs from user to user, it's hard to even ask | for the password because the spoofer doesn't know what to call it. I suppose this can be circumvented if you you use email to lure the victim to the fake web page and have obtained names matching the email addresses. Even if you want to present the full address to the victim, you can buy this data from direct marketing companies, I think. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
* Anne Lynn Wheeler: Florian Weimer wrote: If you've deployed two-factor authentication (like German banks did in the late 80s/early 90s), the relevant attacks do involve compromised customer PCs. 8-( Just because you can't solve it with your technology doesn't mean you can pretend the attacks don't happen. EU finread terminal was countermeasure to (widely held impression that) PCs are extremely vulnerable to compromise. You say that as if that assumption were unrealistic. Transaction-rewriting malware is out in the wild. 8-( FINREAD is really interesting. I've finally managed to browse the specs, and it looks as if this platform can be used to build something that is secure against compromised hosts. However, I fear that the support costs are too high, and that's why it hasn't caught on in retail online banking. card authentication required pin entry to work ... and finread terminal had its own PIN-pad distinct the vulnerable PC keyboard. orientation was towards transaction authentication ... with the finread terminal also having its own display of what was being authentication. The interesting part is that it's possible to create an application that runs exclusively on the trustworthy component and presents the actual transaction data to the user before it is signed. Previous card readers/smart card combinations relied on host software to provide the display contents, without any way to check that it matches the blob that was to be signed. Of course, it's still possible to develop a FINREAD application that behaves that way, perhaps in order to cut down development costs. As usual, just because it's FINREAD, it's not automatically secure (and a transparent mode exists as well). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
* James A. Donald: The obvious solution to the phishing crisis is the widespread deployment of SRP, but this does not seem to happening. SASL-SRP was recently dropped. What is the problem? There is no way to force an end user to enter a password only over SRP. That's why SRP is not effective against phishing (even the mimicry variant). In that regard, the password input field was a huge mistake. Fortunately, it doesn't matter because today, we must assume that the client is thoroughly compromised, which means that entering passwords over SRP isn't safe, either. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of opportunistic encryption
* Sandy Harris: Recent news stories seem to me to make it obvious that anyone with privacy concerns (i.e. more-or-less everyone) should be encrypting as much of their communication as possible. Implementing opportunistic encryption is the best way I know of to do that for the Internet. I'm somewhat out of touch, though, so I do not know to what extent people are using it now. That is my question here. It seems to me opportunistic encryption has moved to the application layer, at least as far as Internet mail is concerned. Many MTAs use TLS automatically with whatever certificates they can get. Of course, this only guards against active attacks, but it seems to me that this is a reasonable threat model. At least it's like to hide your important GnuPG-encrypted messages from the casual traffic analyst. 8- and that both of FreeS/WAN's successor projects (openswan.org and strongswan.org) mention it in their docs. However, I don't know if it actually being used. Didn't Openswan announce that opportunistic encryption is deprecated? My impression was that, according to its creators, Freeswan was mainly about OE, but people used it as a regular IPsec implementation on Linux. Openswan tried to bridge that gap, even while the Freeswan project itself was still active. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: picking a hash function to be encrypted
* Travis H.: IIUC, protocol design _should_ be easy, you just perform some finite-state analysis and verify that, assuming your primitives are ideal, no protocol-level operations break it. Is this still true if you don't know your actual requirements? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: History and definition of the term 'principal'?
* Hadmut Danisch: The only precise definition I found is in a law dictionary where it is defined as a legal term. The OED might also be helpful: B. [...] 2. a. A chief actor or doer; the chief person engaged in some transaction or function, esp. in relation to one employed by or acting for him (deputy, agent, etc.); the person for whom and by whose authority another acts. [...] 1962 H.O. Beecheno Introd. Business Stud. xiii. 117 Whereas an agent is not normally allowed to relend his principal's money at interest .. a bank is allowed to do this. 1976 Times 22 Par. (Baltic Exchange Suppl.) p. i/9 The Baltic is unusual in being open both to middle men and principals. I think this is a strong indication that the term is used in one of its original meanings. It also explained why nobody thinks it's necessary to define it properly. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
* Bill Stewart: Or you could try using the Google Keyserver - just because there isn't one doesn't mean you can't type in 9E94 4513 3983 5F70 or 9383DE06 or [EMAIL PROTECTED] PGP Key and see what's in Google's cache. What a peculiar advice. We know for sure that Google logs these requests and stores them indefinitely. 8-( - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
* Werner Koch: On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said: 1) It invoke exit, as you have noticed. While this only happen in extreme and fatal situations, and not during runtime, it is not that serious. Yet, I agree it is poor design to do this in a library. I disagree strongly here. Any code which detects an impossible state or an error clearly due to a programming error by the caller should die as soon as possible. If you try to resolve the problem by working around it will increase code complexity and thus error won't be detected. (Some systems might provide a failsafe mechanism at a top layer; e.g. by voting between independed developed code). _exit in libraries is fine if you don't service multiple clients from a single process. However, with the advent of heavy VMs and stuff like that, there is a trend towards serving multiple clients from a single process (which is quite a bad idea in almost all cases, but this view is rather unpopular). There are also libraries which require proper cleanup procedures, otherwise the next program start can be quite costly (think of databases, where you want to avoid log replay). Some services have even been implemented following a single-process model for more than a decade (IRC servers, for example). A user-defined fatal error function (which must not return) would be a compromise, I think. Of course, such a function should never be called if you just see wrong or unsual input. But with a bit of optimism, the process could recover from an error which is not locally recoverable (throw an exception, terminate the offending thread, and leak the allocated resources). Now if the library maintains global, per-process state, this is a real problem. You can't know for sure if this state is consistent after a fatal error, unless you program carefully to avoid this situation. Yet another reason to move this functionality to a separate process. 8-) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AW: [Clips] Banks Seek Better Online-Security Tools
* Ulrich Kuehn: In 2000 someone here in Germany already demonstrated how to attack smart card based HBCI transactions. Those transactions are authorized by an RSA signature done by the card. Here's a link: http://www.heise.de/newsticker/meldung/9349 The attack relyed on the card reader not having a separate keyboard for PIN entry. In this particular implementation, yes. There are other attacks if you control the end user system: You can display a dialog box requesting that the user enters the PIN on the host, and not on the PIN pad. Typical smartcard work in various card readers (with and without PIN pads), so you can later use the PIN to create additional transactions. It turns out that you need not do this, though: once the end user has entered the PIN, you can create as many signatures as you like. In this sense, the PIN/TAN approach is more secure than smartcards. Interestingly, I wonder what would happen if a reader with display and keyboard is used in an online attack, i.e. the adversary sneaks in a fraudulent transaction when the hash for the signature is computed. I do not know from the top of my head what is supposed to be displayed in the reader's display, so I do not know what impact such an attempt would have. The display contents is supplied by the end user computer, not the smartcard, so it's still possible to break this scheme just by attacking the computer. Any suggestions? Postbank's mTAN is promising because uses a separate channel which is currently not very easy to attack, but the activation procedure is fundamentally flawed. Costs are probably too high to introduce this as a general countermeasure, though. In the long term, we need a standardized device which generates TANs which depend on the transaction contents (target account and amount). Standardization is important because you don't want to carry around such a device for each plastic card you own. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Clips] Banks Seek Better Online-Security Tools
* Nicholas Bohm: [EMAIL PROTECTED] wrote: You know, I'd wonder how many people on this list use or have used online banking. To start the ball rolling, I have not and won't. --dan I do. My bank provides an RSA SecureId, so I feel reasonably safe against anyone other than the bank. But it's just a token measure. You should be afraid of your own computer, your own network. SecureID does not authenticate the server you're going to send your data to. It does not detect if your computer is compromised. Sure, right now, it might help you personally, but once these simple tokens gain market share, attackers will adjust. It's not a general solution. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Clips] Banks Seek Better Online-Security Tools
You know, I'd wonder how many people on this list use or have used online banking. To start the ball rolling, I have not and won't. Why? Repudiating transactions is easier than ever. As a consumer, I fear technology which is completely secure according to experts, but which can be broken nevertheless. The current situation is very different. Everybody agrees that online banking is insecure, and in most markets, it's the banks who swallow the losses, not the consumer (even those who were very stupid). For those of you who haven't rolled out a national ID scheme in time, there's still the general identity theft problem, but this affects you even if you don't use online banking. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Clips] Banks Seek Better Online-Security Tools
* Eugen Leitl: The German PIN/TAN system is reasonably secure, being an effective one-time pad distributed through out of band channel (mailed dead tree in a tamperproof envelope). Some banks have optimized away the special envelope. 8-( It is of course not immune to phishing (PIN/TAN harvesting), which has become quite rampant recently. And we face quite advanced attack technology, mainly compromised end systems. We are well beyond the point where simple tokens (like RSA SecureID) would help. I do have a HBCI smartcard setup with my private account but don't use it since it's locked in a proprietary software jail. The way the current attacks are carried out, smartcard-based HBCI is less secure than the PIN/TAN model because with HBCI, you don't need to authorize each transaction separately. At this stage, few people recognize this problem, and German banks put high hopes on smartcard-based online banking, despite its high costs in terms of consumer devices and support calls. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Clips] Banks Seek Better Online-Security Tools
* Jonathan Thornburg: Ahh, but how do you know that the transaction actually sent to the bank is the same as the one you thought you authorized with that OTP? If your computer (or web browser) has been cracked, you can't trust _anything_ it displays. There are already viruses in the wild attacking German online banking this way: http://www.bsi.bund.de/av/vb/pwsteal_e.htm Of course you don't. In some sense, the next-generation security technology which U.S. banks plan to roll out (either voluntarily, or due to regulation) has already been broken in Germany. If you bring the topic up in discussions, the usual answer is don't MITM me! (meaning: Don't mention man-in-the-middle attacks, including compromised customer systems, because you know we can't defend against them! This is not fair!). But this is not a valid response when experience shows that the relevant attacks *are* MITM attacks. I also don't trust RSAsafe or other such 2-factor authentication gadgets, for the same reason. I'm always glad to read someone who agrees with me on this matter. 8-) I don't understand why almost everyone is in a frenzy to deploy them. If you can somehow weasel through the next 6 months or so, it will be completely non-repudiatable that transactions covered by two-factor authentication are fully repudiatable. You can save a lot of money (including your customers' money) if you manage to skip this technology cycle. The only problem could be that the media and security experts smack you if you don't deploy the same, broken countermeasures everyone else does. By the way, one interesting aspect of the online banking problem is its implications for threat modelling, attack trees, and similar approaches. It would be interesting to compare a few models and why they fail to adequately describe the situation. My hunch is that these models do not take two factors into account: Attacks aren't targeted by the cost/revenue alone, tradition plays a major role, too, as does sheer luck. And you are caught in a feedback loop; the attacks change as you deploy new countermeasures, and the changes are mostly unpredictable. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
* Peter Gutmann: I haven't been following the IPSec mailing lists of late -- can anyone who knows details explain what the issue is? These bugs have been uncovered by a PROTOS-style test suite. Such test suites can only reveal missing checks for boundary conditions, leading to out- of-bounds array accesses and things like that. In other words, trivial implementation errors which can be easily avoided using proper programming tools. I feel a need to comment on statements like this... at several times in the past I've seen people make sweeping generalisation like this, Everyone knows about this security weakness, this { paper | article | security alert } isn't { novel | interesting | worth publishing }, Touché. or some variant thereof (in this case these trivial errors are easily avoided). Of course, the relevance of a bug and how easily it could have been avoided are completely different matters. I mainly wanted to point out that there is no new cryptography involved. What makes these statements rather unconvincing is that the majority of all implementations out there all make these trivial easily-avoided errors They have chosen different trade-offs, focusing on performance, time-to-market and things like that. It's hard enough to create an ISAKMP implementation that works at all. In this particular case if the problem is so trivial and easily avoided, why does almost every implementation (according to the security advisory) get it wrong? How many completely independent implementations are there? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
* William Allen Simpson: Quoting Photuris: Design Criteria, LNCS, Springer-Verlag, 1999: The hallmark of successful Internet protocols is that they are relatively simple. This aids in analysis of the protocol design, improves implementation interoperability, and reduces operational considerations. Compare with Photuris [RFC-2522], where undergraduate (Keromytis) and graduate (Spatscheck, Provos) students independently were able to complete interoperable implementations (in their spare time) in a month or so Photuris uses a baroque variable-length integer encoding similar to that of OpenPGP, a clear warning sign. 8-/ The protocol also contains nested containers which may specify conflicting lengths. This is one common source of parser bugs. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
* William Allen Simpson: Florian Weimer wrote: Photuris uses a baroque variable-length integer encoding similar to that of OpenPGP, a clear warning sign. 8-/ On the contrary: + a VERY SIMPLE variable-length integer encoding, where every number has EXACTLY ONE possible representation (unlike ASN.1 which even the spell-checker wants to replace with assinine). + similar to that of OpenPGP, the most common Open Source security software of the era, where the code could be easily reused (as it was in the initial implementation). Even back then, the integer encoding was considered to be a mistake. | I concur completely. I once got so fed up with this habit that I | tromped around the office singing, Every bit is sacred / Every bit | is great / When a bit is wasted / Phil gets quite irate. | | Consider this to be one of the prime things to correct. Personally, | I think that numbers should never (well, hardly ever) be smaller | than 32 bits. (Jon Callas, 1997-08-08) The protocol also contains nested containers which may specify conflicting lengths. This is one common source of parser bugs. On the contrary, where are internal nested containers in the protocol? Variable-length integers within other fields, for example. You can't avoid this phenomenon in its entirety, of course, without sacrificing some of the advantages of a binary encoding. Again, the ISAKMP flaws were foreseeable and avoidable. And Photuris was written before the existence of ISAKMP. I like ISAKMP as much as the next guy, but somehow I doubt that simpler protocols necessarily lead to more robust software. Sure, less effort is needed to implement them, but writing robust code still comes at an extra cost. *sigh* - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
* Perry E. Metzger: I haven't been following the IPSec mailing lists of late -- can anyone who knows details explain what the issue is? These bugs have been uncovered by a PROTOS-style test suite. Such test suites can only reveal missing checks for boundary conditions, leading to out-of-bounds array accesses and things like that. In other words, trivial implementation errors which can be easily avoided using proper programming tools. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: FW: Fermat's primality test vs. Miller-Rabin
* Charlie Kaufman: The probability of a single run of Miller-Rabin or Fermat not detecting that a randomly chosen number is composite is almost vanishingly small. How do you chose a random integer, that this, based on which probability distribution? 8-) Anyway, one can show that for some fixed number, the probability that one run of the Miller-Rabin algorithm fails (i.e. reports potentially prime for a composite) does not exceed 1/4. Knuth gives a proof in an exercise in Volume 2 of The Art of Computer Programming, including an example that the 1/4 bound is pretty good. However, this answers a slightly different question. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How broad is the SPEKE patent.
* James A. Donald: I figured that the obvious solution to all this was to deploy zero knowledge technologies, where both parties prove knowledge of the shared secret without revealing the shared secret. Keep in mind that one party runs the required software on a computed infected with spyware and other kinds of Trojan horses. This puts the effectiveness of zero-knowledge proofs into question. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cisco VPN password recovery program
* Perry E. Metzger: Via cryptome: http://evilscientists.de/blog/?page_id=343 The Cisco VPN Client uses weak encryption to store user and group passwords in your local profile file. I coded a little tool to reveal the saved passwords from a given profile file. If this is true, it doesn't sound like Cisco used a particularly smart design for this. Why? In essence, this is the PSK that is used to authenticate the VPN gateway. It must be available in cleartext on the client. (Later versions offer asymmetric encryption as well.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cisco VPN password recovery program
http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_configuration_guide_chapter09186a00803ee1f0.html#wp2477015 - - - Cisco Client Parameters Allow Password Storage on Client - Check this box to allow IPSec clients to store their login passwords on their local client systems. If you do not allow password storage (the default), IPSec users must enter their password each time they seek access to the VPN. For maximum security, we recommend that you not allow password storage. - - - I really doubt that this affects group password (PSK). In some cases, network administrators used the password obfuscation to force their users to use Cisco's VPN client. Competing products, such as vpnc, do not enforce client-side policies. However, there's been a website where you can upload the obfuscated password, and it returns the password in clear text for quite some time now. It is implemented by running the Cisco client under a debugging tool, intercepting a memcpy call that copies the password. In the end, the publication of the algorithm doesn't change the security of the system (there wasn't much to start with). But it's certainly easier to write interoperable software using this information. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Clips] RSA Security Sees Hope in Online Fraud
* R. A. Hettinga quotes: Today RSA is perhaps best known for staging a prestigious annual security conference and for selling 20 million little devices that display a six-digit code computer users must type to gain access to computer networks. The code, which changes every minute as determined by an RSA-created algorithm, is unique to each SecureID token, making it useless to a snoop. Of course, SecureID tokens do not prevent man-in-the-middle attacks carried out in real-time. For example, it's probably not too hard to write a Browser Helper Object which automatically rewrites financial transactions submitted using Internet Explorer. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: no visas for Chinese cryptologists
* Udhay Shankar N.: http://nytimes.com/2005/08/17/business/worldbusiness/17code.html Chinese Cryptologists Get Invitations to a U.S. Conference, but No Visas Didn't something similar happen at the FIRST conference in Hawaii a couple of years ago? It's sad that it's going to happen again next year. 8-( - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]