Re: Maybe It's Snake Oil All the Way Down
I thought the 3G (UMTS) cellphones at least were going to use reasonably good crypto; don't know about the overall security architecture though. Jaap-Henk On Fri, 06 Jun 2003 14:30:04 -0400 Ian Grigg [EMAIL PROTECTED] writes: John Kelsey wrote: So, what can I do about it, as an individual? Make the cellphone companies build good crypto into their systems? Any ideas how to do that? Nope. Cellphone companies are big slow moving targets. They get their franchise from the government. If the NSA wants weak crypto, they do weak crypto. -- Jaap-Henk Hoepman | I've got sunshine in my pockets Dept. of Computer Science | Brought it back to spray the day University of Nijmegen |Gry Rocket (w) www.cs.kun.nl/~jhh | (m) [EMAIL PROTECTED] (t) +31 24 36 52710/531532 | (f) +31 24 3653137 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Nullsoft's WASTE communication system
On Thu, 5 Jun 2003 19:52:28 -0700, Kevin Elliott said: Out of curiosity, how does the performance of AES compare to Blowfish (seeing as how performance would be the obvious advantage of Blowfish Encrypt/decrypt time for Libgcrypt: Algo ECB CBC CFB CTR -- --- --- --- --- 3DES1120ms 1130ms 1140ms 1170ms 1200ms 1190ms 1410ms 1400ms BLOWFISH 350ms 340ms 370ms 380ms 430ms 430ms 630ms 630ms AES 290ms 310ms 340ms 360ms 410ms 410ms 620ms 620ms AES256 400ms 410ms 440ms 470ms 510ms 510ms 730ms 720ms over 3DES)? Also are there any patent/license constraints on AES (the There are no constraints on AES usage. Shalom-Salam, Werner -- Werner Koch [EMAIL PROTECTED] The GnuPG Expertshttp://g10code.com Free Software Foundation Europe http://fsfeurope.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: An attack on paypal
At 02:55 PM 6/8/2003, James A. Donald wrote: Attached is a spam mail that constitutes an attack on paypal similar in effect and method to man in the middle. The bottom line is that https just is not working. Its broken. The fact that people keep using shared secrets is a symptom of https not working. The flaw in https is that you cannot operate the business and trust model using https that you can with shared secrets. I don't think it's https that's broken, since https wasn't intended to solve the customer authentication / authorization problem (you could try to use SSL's client certificates for that, but no one ever intended client certificate authentication to be a generalized transaction problem). When I responded to this before, I thought you were talking about the server auth problem, not the password problem. I continue to feel that the server authentication problem is a very hard problem to solve, since there's few hints to the browser as to what the user's intent is. The password problem does need to be solved, but complaining that HTTPS or SSL doesn't solve it isn't any more relevant than complaining that it's not solved by HTML, HTTP, and/or browser or server implementations, since any and all of these are needed in producing a new solution which can function with real businesses and real users. Let's face it, passwords are so deeply ingrained into people's lives that nothing which is more complex in any way than passwords is going to have broad acceptance, and any consumer-driven company is going to consider easy to be more important that secure. Right now, my best idea for solving this problem is to: - Standardize an HTML input method for FORM which does an SPEKE (or similar) mutual authentication. - Get browser makers to design better ways to communicate to users that UI elements can be trusted. For example, a proposal I saw recently which would have the OS decorate the borders of trusted windows with facts or images that an attacker wouldn't be able to predict: the name of your dog, or whatever. (Sorry, can't locate a link right now, but I'd appreciate one.) - Combine the two to allow sites to provide a user-trustable UI to enter a password which cannot be sucked down. - Evangelize to users that this is better and that they should be suspicious of any situation where they used such interface once, but now it's gone. I agree that the overall architecture is broken; the problem is that it's broken in more ways than can just be fixed with any change to TLS/SSL or HTTPS. - Tim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: An attack on paypal
At 11:43 PM 6/8/2003 +0100, Dave Howe wrote: HTTPS works just fine. The problem is - people are broken. At the very least, verisign should say ok so '..go1d..' is a valid server address, but doesn't it look suspiously similar to this '..gold..' site over here? for https://pseudo-gold-site/ - but really, if users are going to fill in random webforms sent by email, they aren't going to be safe under any circumstances; the thing could send by unsecured http to any site on the planet, then redirect to the real gold site for a generic transaction completed or even failed screen A world where a random paypal hack like this one doesn't work is the same as the world where there is no point sending out a Nigerian as you will never make a penny on it - and yet, Nigerian is still profitable for the con artists. in a world where there are repeated human mistakes/failures at some point it is recognized that people aren't perfect and the design is changed to accommodate peoples foibles. in some respects that is what helmets, seat belts, and air bags have been about. in the past systems have designed long, complicated passwords that are hard to remember and must be changed every month. that almost worked when i person had to deal with a single shared-secret. when it became a fact of life that a person might have tens of such different interfaces it became impossible. It wasn't the fault of any specific institution, it was a failure of humans being able to deal with large numbers of extremely complex, frequently changing passwords. Because of known human foibles, it might be a good idea to start shifting from an infrastructure with large numbers of shared-secrets to a non-shared-secret paradigm. at a recent cybersecurity conference, somebody made the statement that (of the current outsider, internet exploits, approximately 1/3rd are buffer overflows, 1/3rd are network traffic containing virus that infects a machine because of automatic scripting, and 1/3 are social engineering (convince somebody to divulge information). As far as I know, evesdropping on network traffic doesn't even show as a blip on the radar screen. In the following thread on a financial authentication white paper: http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper http://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper http://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper there is point made that X9.59 standard doesn't directly address the Privacy aspect of security (i.e. no encryption or hiding of data). However, the point is made that it changes the paradigm so that the financial account number no longer represents a shared-secret and that it can be supported with two-factor authentication i.e. something you have token and something you know PIN. The something you know PIN is used to enable the token, but is not a shared secret. Furthermore, strong authentication can be justification for eliminating the need for name or other identification information in the transaction. However, if X9.59 strong authentication is used with two-factor authentication and no identification information is necessary then it would make people more suspicious if privacy information was requested. Also, since privacy information is no longer sufficient for performing a fraudulent transaction, it might mitigate that kind of social engineering attack. The types of social engineering attacks then become convincing people to insert their hardware token and do really questionable things or mailing somebody their existing hardware token along with the valid pin (possibly as part of an exchange for replacement). The cost/benefit ratio does start to change since there is now much more work on the crooks part for the same or less gain. One could also claim that such activities are just part of child-proofing the environment (even for adults). On the other hand, it could be taken as analogous to designing systems to handle observed failure modes (even when the failures are human and not hardware or software). Misc. identify theft and credit card fraud reference: http://www.consumer.gov/idtheft/cases.htm http://www.usdoj.gov/criminal/fraud/idtheft.html http://www.garlic.com/~lynn/aadsm14.htm#22 Identity Theft Losses Expect to hit $2 trillion http://www.garlic.com/~lynn/subpubkey.html#fraud Slightly related in recent thread that brought up buffer overflow exploits http://www.garlic.com/~lynn/2003j.html#4 A Dark Day and the report that multics hasn't ever had a buffer overflow exploit http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation somebody (else) commented (in the thread) that anybody that currently (still) writes
Re: An attack on paypal
in a world where there are repeated human mistakes/failures at some point it is recognized that people aren't perfect and the design is changed to accommodate peoples foibles. in some respects that is what helmets, seat belts, and air bags have been about. The problem is here, we are blaming the protective device for not being able to protect against the deliberate use of an attack that bypasses, not challenges it - by exploiting the gullibility or tendency to take the path of least resistance of the user. The real weakness in HTTPS is the tendency of certificates signed by Big Name CAs to be automagically trusted - even if you have never visited that site before. yes, you can fix this almost immediately by untrusting the root certificate - but then you have to manually verify each and every site at least once, and possibly every time if you don't mark the cert as trusted for future reference. To blame HTTPS for an attack where the user fills in a web form received via html-rendering email (no https involved at all) is more than a little unfair though. in the past systems have designed long, complicated passwords that are hard to remember and must be changed every month. that almost worked when a person had to deal with a single shared-secret. when it became a fact of life that a person might have tens of such different interfaces it became impossible. It wasn't the fault of any specific institution, it was a failure of humans being able to deal with large numbers of extremely complex, frequently changing passwords. Because of known human foibles, it might be a good idea to start shifting from an infrastructure with large numbers of shared-secrets to a non-shared-secret paradigm. I am not aware of one (not that that means much, given I am a novice in this field) Even PKI relies on something close to a shared secret - a *trustworthy* copy of the public key, matching a secret copy of the private key. In x509, this trustworthyness is established by an Ultimately Trusted CA; in pgp, by the Web Of Trust, in a chain leading back to your own key; in SSH, by your placing of the public key into your home dir manually (using some other form of authentication to presumably gain access) in each of these cases, the private key will almost invariably be protected by a passphrase; at best, you can have a single passphrase (or even single private key) to cover all bases.. but that just makes that secret all the more valuable. at a recent cybersecurity conference, somebody made the statement that (of the current outsider, internet exploits, approximately 1/3rd are buffer overflows, 1/3rd are network traffic containing virus that infects a machine because of automatic scripting, and 1/3 are social engineering (convince somebody to divulge information). As far as I know, evesdropping on network traffic doesn't even show as a blip on the radar screen. That is pretty much because defence occupies the position of the interior - attackers will almost invariably attack weak points, not strong ones. It is easy to log and calculate how many attacks happen on weak points, but impossible to calculate how many attacks *would* have happened had the system not been in place to protect against such attacks, so the attackers moved onto easier targets. It makes little sense to try and break one https connection (even at 40 bit) if by breaking into the server you get that information, hundreds of others (until discovered) and possibly thousands of others inadvisedly stored unprotected in a database. snip The types of social engineering attacks then become convincing people to insert their hardware token and do really questionable things or mailing somebody their existing hardware token along with the valid pin (possibly as part of an exchange for replacement). The cost/benefit ratio does start to change since there is now much more work on the crooks part for the same or less gain. One could also claim that such activities are just part of child-proofing the environment (even for adults). On the other hand, it could be taken as analogous to designing systems to handle observed failure modes (even when the failures are human and not hardware or software). Misc. identify theft and credit card fraud reference: Which again matches well to the Nigerian analogy. Everyone *knows* that handing over your bank details is a Bad Thing - yet they still do it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
