Apparently one can spell Snake Oil in Capital Letters, too (Re: CRYPTO-GRAM, August 15, 2004)
At 11:26 PM -0500 8/14/04, Bruce Schneier wrote: From: Ken Lavender [EMAIL PROTECTED] Subject: ICS Atlanta I am APPAULED at your comments that you had made on your website: http://www.schneier.com/crypto-gram-0407.html#9 You have statements are nothing but slander defamation. They shall be dealt with accordingly. Lie #1: How do they demonstrate Tree's security? 'Over 100 professionals in mathematics in computer science at Massachusetts Institute of Technology at Georgia Tech, had sample encoded messages submitted to them. Not a single person could break this code!' That is not the ONLY way we prove it. We have examples offer to allow people to submit their OWN messages to have encoded to SEE how good the code is. So there are THREE methods, NOT just ONE as you IMPLY. Lie #2: These guys sent unsolicited e-mails... HOW do you KNOW that this was the case? Have any PROOF of such? NO! Lie #3: And if all that isn't enough to make you run screaming from these guys, their website proudly proclaims: 'Tree Encoded Files Can Be Zipped.' Because they can be zipped does NOT mean that it is bad encoding. The code talkers of ww2 used LANGUAGE to code the messages, and THOSE COULD BE ZIPPED!!! And that code was NEVER BROKEN!!! Lie #4: That's right; their encryption is so lousy that the ciphertext doesn't even look random. AGAIN, HOW would you KNOW??? Did you break it? NO! And what is random??? random : without definite aim, direction, rule, or method So lousy? HOW WOULD YOU KNOW??? You would have to KNOW how we encode BEFORE you can make such a statement, YOU DO NOT KNOW HOW!!! If it is SO LOUSY, how come NOBODY HAS BROKEN IT YET??? And we have people ALL THE TIME trying to, with ZERO SUCCESS. I do not like you slandering something that you do not understand. ATALL!!! The ONLY question you asked was how long is the key AND THAT WAS IT! HOW long was the key that the 'code talkers' used? ZERO!!! JUST AS OUR IS. The encoding routine was created, tested, verified on PAPER PENCIL WITHOUT COMPUTERS! A child could encode data using our routine. The computer is merely used to speed-up the process, NOT TO CREATE IT. Our routine is based on LANGUAGE, NOT MATH. So all of you comments are just false, misleading just plain ole lies! SHOW PROVE that it is NOT random. What is the PATTERN THEN??? I am DEMANDING A FULL RETRACTION OF YOUR COMMENTS A FULL, COMPLETE APOLOGY TO THESE AND ALL STATEMENTS. I am a person who tries to work with people as a man w/o having to drag others into the mess. Others? THE COURTS. You have violated Calf law by your statements. [Text of California Civil Code Section 46 deleted.] Your LIES have damaged my respect in my job has damaged any sales of this routine. You have ZERO proof of your comments, ANY OF THEM!!! I beseech of you, do the RIGHT THING and comply. I DO NOT wish to escalate this matter any higher. And remember this, Tree is based on LANGUAGE, NOT MATH! [Phone number deleted out of mercy.] -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
Apparently one can spell Snake Oil in Capital Letters, too (Re: CRYPTO-GRAM, August 15, 2004)
At 11:26 PM -0500 8/14/04, Bruce Schneier wrote: From: Ken Lavender [EMAIL PROTECTED] Subject: ICS Atlanta I am APPAULED at your comments that you had made on your website: http://www.schneier.com/crypto-gram-0407.html#9 You have statements are nothing but slander defamation. They shall be dealt with accordingly. Lie #1: How do they demonstrate Tree's security? 'Over 100 professionals in mathematics in computer science at Massachusetts Institute of Technology at Georgia Tech, had sample encoded messages submitted to them. Not a single person could break this code!' That is not the ONLY way we prove it. We have examples offer to allow people to submit their OWN messages to have encoded to SEE how good the code is. So there are THREE methods, NOT just ONE as you IMPLY. Lie #2: These guys sent unsolicited e-mails... HOW do you KNOW that this was the case? Have any PROOF of such? NO! Lie #3: And if all that isn't enough to make you run screaming from these guys, their website proudly proclaims: 'Tree Encoded Files Can Be Zipped.' Because they can be zipped does NOT mean that it is bad encoding. The code talkers of ww2 used LANGUAGE to code the messages, and THOSE COULD BE ZIPPED!!! And that code was NEVER BROKEN!!! Lie #4: That's right; their encryption is so lousy that the ciphertext doesn't even look random. AGAIN, HOW would you KNOW??? Did you break it? NO! And what is random??? random : without definite aim, direction, rule, or method So lousy? HOW WOULD YOU KNOW??? You would have to KNOW how we encode BEFORE you can make such a statement, YOU DO NOT KNOW HOW!!! If it is SO LOUSY, how come NOBODY HAS BROKEN IT YET??? And we have people ALL THE TIME trying to, with ZERO SUCCESS. I do not like you slandering something that you do not understand. ATALL!!! The ONLY question you asked was how long is the key AND THAT WAS IT! HOW long was the key that the 'code talkers' used? ZERO!!! JUST AS OUR IS. The encoding routine was created, tested, verified on PAPER PENCIL WITHOUT COMPUTERS! A child could encode data using our routine. The computer is merely used to speed-up the process, NOT TO CREATE IT. Our routine is based on LANGUAGE, NOT MATH. So all of you comments are just false, misleading just plain ole lies! SHOW PROVE that it is NOT random. What is the PATTERN THEN??? I am DEMANDING A FULL RETRACTION OF YOUR COMMENTS A FULL, COMPLETE APOLOGY TO THESE AND ALL STATEMENTS. I am a person who tries to work with people as a man w/o having to drag others into the mess. Others? THE COURTS. You have violated Calf law by your statements. [Text of California Civil Code Section 46 deleted.] Your LIES have damaged my respect in my job has damaged any sales of this routine. You have ZERO proof of your comments, ANY OF THEM!!! I beseech of you, do the RIGHT THING and comply. I DO NOT wish to escalate this matter any higher. And remember this, Tree is based on LANGUAGE, NOT MATH! [Phone number deleted out of mercy.] -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
Snake oil?
http://www.topsecretcrypto.com/ Snake oil? Regards, Matt-
Re: Snake oil?
[EMAIL PROTECTED] wrote: http://www.topsecretcrypto.com/ Snake oil? I am not entirely sure. on the plus side - it apparently uses Sha-1 for a signing algo, RSA with a max keysize of 16Kbits (overkill, but better than enforcing something stupidly small), built in NTP synch for timestamps (probably spoofable, but at least a valiant attempt to keep timestamps accurate by default) and supports a range of file, folder, email and chat crypto with a onscreen keyboard for password entry (again, not unbeatable but a valiant attempt) next step is the symmetric component though - which shows more than slight traces of oil. First is a randomly generated session key, protected by the RSA component - on the face of it fine (its how pgp and smime do it, after all) but no details are given on *how* the random key is obtained (the code apparently contains a true random number generator which seems doubtful) and the symmetric component is a proprietary algo (for which source is provided, but even so...) Second is pretty much pgp's conventional mode - but with a user supplied key. no mention of hashing, and again, the proprietary algo is in use. Third is True One Time Pad - yes well duh! I could write one in eight lines or so of VBScript, for free. Nobody needs to pay for a OTP application, certainly not per-seat. An announcement of the software (and subsequent discussion) took place in Sci.Crypt some months ago - dejagoogle link here: http://makeashorterlink.com/?M138249F6 - if anyone wants to read it.
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
Re: Maybe It's Snake Oil All the Way Down
Rich Salz wrote: Perhaps a few best practices papers are in order. They might help the secure (distributed) computing field a great deal. /r$ -- The new book, Practical Cryptography, by Niels Ferguson and Bruce Schneier is useful. regards, Frederick
Re: Maybe It's Snake Oil All the Way Down
James A. Donald writes: Suppose the e-gold, to prevent this sea of spam trying to get people to login to fake e-gold sites, wanted people to use public keys instead of shared secrets, making your secret key the instrument that controls the account instead of your shared password. They could not do this using the standard IE webbrowser. They would have to get users to download a custom client, or at least, like hushmail, a custom control inside IE. Why do you say that? You were already given pointers to how they could configure their web servers to use certificate based client authentication. These techniques work with standard browsers. I have used Netscape to access corporate-internal sites which required me to have a client certificate. HTTPS assumes that the certificate shall be blessed by the administrator out of band, and has no mechanism for using a private key to establish that a user is simply the same user as last time. HTTPS is just HTTP over SSL/TLS. It says nothing about the trust model for the certificates; it merely specifies how each side can deliver its cert(s) to the other side. Deciding which ones to trust is out of scope for TLS or HTTPS. E-Gold could set things up to allow its customers to authenticate with certs issued by Verisign, or with considerably more work it could even issue certs itself that could be used for customer authentication. Why doesn't it do so? Well, it's a lot of work, and it would have some disadvantages - for one thing, customers would have difficulty accessing their accounts from multiple sites, like at home and at work. Further, it would require customers to use some features of their browser that most of them have never seen, which is going to be difficult and error-prone for most users.
Re: Maybe It's Snake Oil All the Way Down
Derek Atkins [EMAIL PROTECTED] writes: Actually, the ASN.1 part is a major factor in the X.509 interoperability problems. Different cert vendors include different extensions, or different encodings. They put different information into different parts of the certificate (or indeed the same information into different parts). Does the FQDN for a server cert belong in the DN or some extension? What about the email address for a user cert? That doesn't really have anything to do with ASN.1 though. You can make just as big a mess with XML (actually even bigger, in my experience), or EDIFACT, or whatever. The problem isn't the bit-bagging format, it's that it's accumulated such a mass of cruft that no two people can agree on what to put in there. Whether the resulting mess is wrapped in ASN.1 or XML or EDIFACT or plastic pooper scooper bags doesn't really make any difference. Peter.
Re: Maybe It's Snake Oil All the Way Down
-- On 7 Jun 2003 at 19:05, Dave Howe wrote: issuing certs to someone is trivial from both a server and a user endpoint - the user just gets a click here to request your key and hits ok on a few dialog boxes; the server simply hosts some pretty off-the-shelf cgi. [...] its surprisingly reliable and easy - particuarly if your end users are just using the MS keystore, which requires them to do no more than double-click the pkcs file and hit next a few times. This sounds more like what I was looking for. Probably someone has already pointed out the url to this, but if they did, I when I looked at it I was snowed under by verisign oriented shit, which assumes a large budget and ample administrator time for face to face contact with certified people, a very small number of clients, some hours of work by each client, a manual, user training, etc, and failed to grasp it. Could you point me somewhere that illustates server issued certs, certification with zero administrator overhead and small end user overhead? Also, I have many times heard that public key operations were surprisingly easy, and have been key administrator for several companies, and have unfailingly found that I was the only person capable of doing these operations at that company. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG v6gZFuZoUgyGH55ME+JoilJSfw5LrufrbWWB454U 4FhiB65yyXwp1RgeJrLADfEYBoqz0YAch8fJ0Fisp
Re: Maybe It's Snake Oil All the Way Down
my site has one. ca0.net ..tom -- On 7 Jun 2003 at 19:05, Dave Howe wrote: issuing certs to someone is trivial from both a server and a user endpoint - the user just gets a click here to request your key and hits ok on a few dialog boxes; the server simply hosts some pretty off-the-shelf cgi. [...] its surprisingly reliable and easy - particuarly if your end users are just using the MS keystore, which requires them to do no more than double-click the pkcs file and hit next a few times. This sounds more like what I was looking for. Probably someone has already pointed out the url to this, but if they did, I when I looked at it I was snowed under by verisign oriented shit, which assumes a large budget and ample administrator time for face to face contact with certified people, a very small number of clients, some hours of work by each client, a manual, user training, etc, and failed to grasp it. Could you point me somewhere that illustates server issued certs, certification with zero administrator overhead and small end user overhead? Also, I have many times heard that public key operations were surprisingly easy, and have been key administrator for several companies, and have unfailingly found that I was the only person capable of doing these operations at that company. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG v6gZFuZoUgyGH55ME+JoilJSfw5LrufrbWWB454U 4FhiB65yyXwp1RgeJrLADfEYBoqz0YAch8fJ0Fisp - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
James A. Donald wrote: Could you point me somewhere that illustates server issued certs, certification with zero administrator overhead and small end user overhead? Been a while since I played with it, but IIRC OpenCA (www.openca.org) is a full implimentation of a CA, in perl cgi, with no admin intervention required. Obviously, that involves browser-based key generation. If you want server-based key generation, then take a look at http://symlabs.com/Net_SSLeay/smime.html If you are iis/asp rather than perl, then there are activex components that will give you access to x509 certificates - EBCrypt is probably the easiest, but there is a activex wrapper for cryptlib too, iirc.
Re: Maybe It's Snake Oil All the Way Down
At 03:50 PM 6/3/03 -0700, Eric Blossom wrote: ... GSM and CDMA phones come with the crypto enabled. The crypto's good enough to keep out your neighbor (unless he's one of us) but if you're that paranoid, you should opt for the end-to-end solution. The CDMA stuff (IS-95) is pretty broken: *linear* crypto function, takes 1 second worst case to gather data sufficient to solve 42 equations in 42 unknowns, but again, what's your threat model? Big brother and company are going to get you at the base station... Big brother has a limited budget, just like the rest of us. If he has to produce a warrant or tap a wire somewhere to listen in on me, he probably won't bother. The only thing protecting my cellphone calls right now is trivially-broken encryption, the need for some moderately expensive equipment, and some laws prohibiting cellphone eavesdropping. That means that some bad guys may be eavesdropping now, and there's no telling how many bad guys will be doing so tomorrow. Nobody here knows how much eavesdropping is being done, because communications intercepts can be done without leaving any record anywhere. Do the police in some cities troll for interesting cellphone calls? Does the NSA do that in the US, quietly? Do Russian or French intelligence agencies? How would we know? 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? The only way I can see getting decent security on my cellphone is to do something that doesn't require the rest of the world's permission or assistance. The simplest version of that is to have a box at my house that's connected to two phone lines, and have all calls to and from my cellphone go through that box. Calls to other secure cellphones can be encrypted end-to-end. Calls to everyone else get encrypted between my phone and my box at home. I spend a little extra for extra security, nobody else has to pay anything, and I can call friends on my cellphone without being susceptible to trivial eavesdropping. Can the bad guys defeat this? Sure, they can tap my landline, or bug my car, or do all sorts of other things. But none of those are cheap enough to do to everyone, and probably none are cheap enough to do to me. Tapping my landline either means interacting with the phone company, or paying someone to go install a tap, each of which implies a risk of getting caught, practical limits on how often it can be done, etc. This also bypasses the network effect of encrypting phones, where you get approximately zero benefit from having one until they're widespread. I have an old Comsec 3DES phone at home. It's nice technology. I think I've used it twice. If you're not a cryptographer or a cocaine smuggler, you probably don't know anyone who owns an encrypting phone or would particularly want to. Even if you'd like to improve your own privacy, you can't buy an end-to-end encrypting phone and improve it much. That's what I'd like to see change. ... Eric --John Kelsey, [EMAIL PROTECTED] PGP: FA48 3237 9AD5 30AC EEDD BBC8 2A80 6948 4CAA F259
Re: Maybe It's Snake Oil All the Way Down
Ian Grigg wrote: (Similar to GSM's. That is hard to attack, there is AFAIR no 'trival' attack, [...] Just wait a little while. By the way, one can already buy fake base stations that mount man-in-the-middle attacks on GSM as a way to eavesdrop on GSM calls. It's off the shelf, but it costs ridiculous amounts of money. Now, it seems that the US standards didn't get even that. Right. The major barrier is the need for a digital scanner (which indeed is a major barrier against certain threat models, but not a barrier for other threat models). And, market forces and all that, one would think that this would happen in due course. I'm less optimistic. Market forces being what they are, one would expect that one would quickly get cellphones that are *claimed* and *perceived* to be more secure, regardless of their true merits or demerits. Oh wait, that already happened.
Re: Maybe It's Snake Oil All the Way Down
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. There is literally no point in hoping the cell phone company - or any large franchise holder - will help you in your fight against big brother. OTOH, what you can do is argue for reasonable crypto. (Similar to GSM's. That is hard to attack, there is AFAIR no 'trival' attack, you have to get access to the SIM or you have to probe the phone with another phone over a period of hours. I.e., the attacker leaves tracks, and he does so in a way that will move him on to another mode of tapping, such as purchasing a straight listening device.) Now, it seems that the US standards didn't get even that. There's definately a case for arguing for better crypto in the US. And, market forces and all that, one would think that this would happen in due course. But arguing for strong crypto end-to-end - save your breath. John Kelsey (paraphrased): The only way I can see getting decent security [in any application] is to do something that doesn't require the rest of the world's permission or assistance. (I edited the above to broaden the assert!) Opportunistic crypto - that which uses the tools immediately available and delivers crypto that is the best available right now - is the only crypto that will work for *you* the user in any application. Anything that defers security off to some external party has a result of slowing or killing the application, or delivering less or no security than if you'd gone ahead in the first place. This isn't saying anything new. It's the Internet, after all. On the Internet, one doesn't ask for permission to participate. That's no accident, it's a core reason for its arisal. Any protocol that has a step of now ask for permission is, IMHO, breaking one of the major principles of the Internet. ... I have an old Comsec 3DES phone at home. It's nice technology. I think I've used it twice. If you're not a cryptographer or a cocaine smuggler, you probably don't know anyone who owns an encrypting phone or would particularly want to. Even if you'd like to improve your own privacy, you can't buy an end-to-end encrypting phone and improve it much. That's what I'd like to see change. I guess there's no reason why you couldn't load up speakfreely on a custom Unix box with a flashed OS, put in the USB headset, and sell it as an end to end encrypting phone. The software's all free, a cheap machine is $300 at Walmart, some enterprising crypto guy could ship out a network appliance for $500. (Or, put it in a PDA that's got the right hooks?) Half the price of your old Comsec, wasn't it selling for $1000? -- iang
Re: Maybe It's Snake Oil All the Way Down
At 10:09 PM 6/4/2003, James A. Donald wrote: Eric Rescorla Nonsense. One can simply cache the certificate, exactly as one does with SSH. In fact, Mozilla at least does exactly this if you tell it to. The reason that this is uncommon is because the environments where HTTPS is used are generally spontaneous and therefore certificate caching is less useful. Certificate caching is not the problem that needs solving. The problem is all this spam attempting to fool people into logging in to fake BofA websites and fake e-gold websites, to steal their passwords or credit card numbers I don't think this problem is easier to solve (or at least I sure don't know how to solve it). It seems to me that you could tell a user every time they go to a new site that it's a new site, and hope that users would recognize that e-g0ld.com shouldn't be new, since they've been there before. However, people go to a large enough number of sites that they'd be seeing the new alert all the time, which leads me to believe that it wouldn't be taken seriously. Fundamentally, making sure that people's perception of the identity of a web site matches the true identity of the web site has a technical component that is, at most, a small fraction of the problem and solution. Most of it is the social question of what it means for the identity to match and the UI problem of determining the user's intent (hard one, that), and/or allowing the user to easily and reliably match their intent against the reality of the true identity. Any problem that has as a component the fact that the glyphs for lower-case L and one look pretty similar isn't going to be easy to solve technologically. - Tim
Re: Maybe It's Snake Oil All the Way Down
At 04:42 PM 6/4/2003 -0700, Eric Rescorla wrote: Nonsense. One can simply cache the certificate, exactly as one does with SSH. In fact, Mozilla at least does exactly this if you tell it to. The reason that this is uncommon is because the environments where HTTPS is used are generally spontaneous and therefore certificate caching is less useful. there are actually two scenarios one is to pre-cache it (so that its transmission never actually has to happen) and the other is to compress it to zero bytes. detailed discussion of certificate pre-caching and certificate zero byte compression: http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 the typical use for HTTPS for e-commerce is to hide the account number on its way to the financial institution. for the most part the merchant is primarily interested in the response from the consumer's financial institution on whether or not the merchant gets paid. If it weren't for the associated business processes, the merchant could get by with never knowing anything at all about the consumer (the merchant just passes the account number on ... and gets back what they are really interested in the notification from the bank that they will get paid). So a HTTPS type solution is that the consumer pre-caches their bank's certificate (when they establish a bank account). and they transmit the account number hidden using the bank's public key. This happens to pass thru the merchants processing but for purposes of the authorization, the merchant never really has to see it. The protocol would require minor issues of replay attacks and be able to be done in a single round trip w/o all the SSL protocol chatter. Actually, is isn't so much pre-caching their bank's certificate as loading their bank's public key into a table analogous to the way CA public keys are loading into tables (aka using out-of-band processing the convention that they may be self-signed and encoded in a certificate format is an anomoly of available software and in no way implies a PKI). The primary purpose of HTTPS hasn't been to have a secure channel with the merchant, the primary purpose of the HTTPS is to try and hide the consumer's account number as it makes its way to the consumer's financial institution. The other solution is the X9.59 standard (preserve the integrity of the financial infrastructure for all electronic retail payments, not just internet, not just POS, not just credit, ALL; credit, debit, stored value, etc) that creates authenticated transactions and account numbers that can only be used in authenticated transaction. The consumer's public key is registered in their bank account (out of band process, again no PKI). X9.59 transactions are signed and transmitted. Since the account number can only be used in authenticated transactions it changes from needing encryption to hide the value as part of a shared-secret paradigm to purely a paradigm that supports integrity and authentication. As in the above, scenario, the merchant passes the value thru on its way to the consumer's financial institution; and is focused on getting the approved/disapproved answer back about whether they will be paid. As in the bank HTTPS scenario where the bank's pubilc key is pre-cached at the consumer, the pre-caching of the consumer's public key is pre-cached at the bank involves no PKI business processes (although their may be some similarities that the transport of the public key involves encoding in a certificate defined format). misc. x9.59 refs: http://www.garlic.com/~lynn/index.html#x959 Both pre-caching solutions are between the business entities that are directly involved; the consumer and the consumer's financial institution based on having an established business relationship. The invention of PKI was primarily to address the issue of an event between two parties that had no prior business relationship and possibly weren't going to have any future business relationship and that they would conclude their business relying on some mutual trust in the integrity of a 3rd party w/o actually having to resort to an online environment. The e-commerce scenario is that there is real-time, online transaction with the trusted 3rd party (the consumer's financial institution) involving prior business relationship. This negates the basic original assumptions about the environment that PKIs are targeted at addressing. -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Re: Maybe It's Snake Oil All the Way Down
[EMAIL PROTECTED] (Peter Gutmann) writes: Bodo Moeller [EMAIL PROTECTED] writes: Using an explicit state machine helps to get code suitable for multiplexing within a single thread various connections using non-blocking I/O. Is there some specific advantage here, or is it an academic exercise? Some quirk of supporting certain types of hardware like nCipher boxes that do async crypto/scatter-gather? I've had to do this on environments where threads weren't a viable option. See, for instance, my paper from USENIX Security 2002. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/
Re: Maybe It's Snake Oil All the Way Down
Derik asks the pertinant question: The question is: how do we convince M$ and Netscape to include something else in their software? If it's not supported in IE, then it wont be available to the vast majority of users out there. My view, again, IMHO: ignore Microsoft. Concentrate on the open source solutions: KDE, Mozilla, Apache. These groups will always lead in security, because they are not twisted by institutional conflicts; they can examine historical security model from the point of view of interested professionals, rather than commercial actors trying to preserve this or that revenue stream. The trick is to understand whether HTTPS as it currently is can be improved. If it can, then those above guys can do it. Once the improvements are shown to work, Microsoft will follow along. They are a follower company, not an innovator, and they need to see it work in practice before doing anything. As Derik suggests, the vast majority of users will have to wait. Along those lines, there's one piece of excellent news: Eric Rescorla wrote: One can simply cache the certificate, exactly as one does with SSH. In fact, Mozilla at least does exactly this if you tell it to. That's fantastic! I never knew that. How does one set that option on Mozilla? (I'm using 5.0 / 1.3.1.) -- iang
Re: Maybe It's Snake Oil All the Way Down
-- On 4 Jun 2003 at 20:58, Anne Lynn Wheeler wrote: it is relatively trivial to demonstrate that public keys can be registered in every business process that currently registers shared- secrets (pins, passwords, radius, kerberos, etc, etc) I don't think so. Suppose the e-gold, to prevent this sea of spam trying to get people to login to fake e-gold sites, wanted people to use public keys instead of shared secrets, making your secret key the instrument that controls the account instead of your shared password. They could not do this using the standard IE webbrowser. They would have to get users to download a custom client, or at least, like hushmail, a custom control inside IE. HTTPS assumes that the certificate shall be blessed by the administrator out of band, and has no mechanism for using a private key to establish that a user is simply the same user as last time. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG q1a1Whb1YeRws7qoDm6h15qfDstFHciUyP2I4fte 42lCFXf0IqXfh5Mz2mFtznxv6N40EuqpKvQJhLBgS
Re: Maybe It's Snake Oil All the Way Down
At 04:24 PM 6/6/2003 -0700, James A. Donald wrote: I don't think so. ??? public key registered in place of shared-secret? NACHA debit trials using digitally signed transactions did it with both software keys as well as hardware tokens. http://internetcouncil.nacha.org/News/news.html in the above scroll down to July 23, 2001 ... has pointer to detailed report? X9.59 straight forward establishes it as standard with some activity moving on to ISO http://www.garlic.com/~lynn/index.html#x959 pk-init draft for kerberos specifies that public key can be registered in place of shared secret. following has demo of it with radius with public keys registered in place of shared-secret. http://www.asuretee.com/ the radius implementation has been done be a number of people. in all of these cases, there is change in the business process and/or business relationship doesn't introduce totally unrelated parties to the business activities. the is digital signing on the senders side (actually a subset of existing PKI technology) and digital signature verification on the receivers side (again a subset of existing PKI technology). To the extent that there is impact on existing business process ... it is like in the case of introducing x9.59 authentication for credit transactions that have relatively little authentication currently and as a result would eliminate major portion of the existing credit card transaction related fraud. The big issue isn't the availability of the technology ... although there is a slight nit in the asuretee case being FIPS186-2, ecdsa and having support in CAPI and related infrastructures. It not working (easily) is like when my wife and I were doing the original payment gateway with this little client/server startup in menlo park (later moved to mountain view and have since been bought by AOL) and people saying that SSL didn't exist ... misc ref from the past http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Re: Maybe It's Snake Oil All the Way Down
-- James A. Donald: Certificate caching is not the problem that needs solving. The problem is all this spam attempting to fool people into logging in to fake BofA websites and fake e-gold websites, to steal their passwords or credit card numbers On 6 Jun 2003 at 15:04, Tim Dierks wrote: I don't think this problem is easier to solve (or at least I sure don't know how to solve it). It is a hard problem with many well known solutions, none of which have to my knowledge been implemented in HTTPS. For example one can use SPEKE, in which case setting up the account involves sharing (or issuing) a password, but logging in to the account does not require one to reveal the password to the site where one is logging in. In this case the fake website would gain no useful information by luring the user to login to it. The most HTTPS like solution would be to generate a keyfile containing a self signed private key on one's computer, and whenever one hit the website, it would do the HTTPS handshake to log you in to that website's account for the public key corresponding to your private key, however HTTPS does not seem to directly support this model. In this case the bogus web site could log you in, but this would not leak any information that would enable the operators of the bogus web site to login to the real web site. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG /JhekrYM+sQCMQKXhiWzhB3RnOv6PZROgxYwprXj 4LHJfuGlcn7fO4tcfo20/t0cdEy/HyK++XiBVvMFy
Re: Maybe It's Snake Oil All the Way Down
Eric Murray [EMAIL PROTECTED] writes: Too often people see something like Peter's statement above and say oh, it's that nasty ASN.1 in X.509 that is the problem, so we'll just do it in XML instead and then it'll work fine which is simply not true. The formatting of the certificates is such a minor issue that it is lost in the noise of the real problems. And Peter publishes a fine tool for printing ASN.1, so the human readable argument is moot. Actually, the ASN.1 part is a major factor in the X.509 interoperability problems. Different cert vendors include different extensions, or different encodings. They put different information into different parts of the certificate (or indeed the same information into different parts). Does the FQDN for a server cert belong in the DN or some extension? What about the email address for a user cert? Note that there isn't a real running global PKI using SPKI or PGP either. That's a different problem (namely that the big guys like RSA Security, Microsoft, and Verisign don't sell PGP-enabled software or PGP certificates). PGP's problem is an integration problem, making it easy to use for non-techies. That has been the barrier to entry for PGP. The largest problem with X.509 is that various market/political forces have allowed Verisign to dominate the cert market and charge way too much for them. There is software operable by non-cryptographers that will generate reasonable cert reqs (it's not standard Openssl) but individuals and corporations alike balk at paying $300-700 for each cert. (yes I know about the free individual certs, the failure of S/MIME is a topic for another rant). This is only part of the problem... It is not all of it. Indeed the cost (both in money, time, and headache) has always been a barrier to entry. I don't believe that market or political forces are the largest problem with X.509 I will certainly agree that the cost is a major impediment. The question is: how do we convince M$ and Netscape to include something else in their software? If it's not supported in IE, then it wont be available to the vast majority of users out there. -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com
Re: Maybe It's Snake Oil All the Way Down
Derek Atkins [EMAIL PROTECTED] writes: Eric Murray [EMAIL PROTECTED] writes: Too often people see something like Peter's statement above and say oh, it's that nasty ASN.1 in X.509 that is the problem, so we'll just do it in XML instead and then it'll work fine which is simply not true. The formatting of the certificates is such a minor issue that it is lost in the noise of the real problems. And Peter publishes a fine tool for printing ASN.1, so the human readable argument is moot. Actually, the ASN.1 part is a major factor in the X.509 interoperability problems. Different cert vendors include different extensions, or different encodings. They put different information into different parts of the certificate (or indeed the same information into different parts). Does the FQDN for a server cert belong in the DN or some extension? What about the email address for a user cert? This isn't really true in the SSL case: To a first order, everyone ignores any extensions (except sometimes the constraints) and uses the CN for the DNS name of the server. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/
Re: Maybe It's Snake Oil All the Way Down
Eric Rescorla [EMAIL PROTECTED] writes: This isn't really true in the SSL case: To a first order, everyone ignores any extensions (except sometimes the constraints) and uses the CN for the DNS name of the server. Except some CAs make certs that can only work as an SSL server and not an SSL client, or don't work with certain verifiers, or can't be parsed right, or have the commit-bit set on some extensions. It's been a major pain in a problem that I'm working on -- not all vendor's certs work properly. -Ekr -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com
Re: CDR: Re: Maybe It's Snake Oil All the Way Down
On Fri, 06 Jun 2003, James A. Donald wrote: Suppose the e-gold, to prevent this sea of spam trying to get people to login to fake e-gold sites, wanted people to use public keys instead of shared secrets, making your secret key the instrument that controls the account instead of your shared password. Why does e-gold have any interest in what people do on other sites? HTTPS assumes that the certificate shall be blessed by the administrator out of band, and has no mechanism for using a private key to establish that a user is simply the same user as last time. Yes. There's a virtue there. Knowing a secure channel exists is frequently more important than who is on the other line. For example, What's my favorite brand of lighter? You live in a Bob's cold, dark cave, where you hate life. Insert water dripping and scabs until you're amused. You have the chance to contact, and maybe move to, Alice's bright, warm cave. Sounds good to you. How to authenticate the offer? Replay various notions of various fiction writers, here. The problem is interesting. Solved, but interesting. Very few folks have reason to help you authenticate them. Deal. Even if people don't understand what https (and ssl) do, they still serve a purpose. Even if it isn't the one you wanted solved. And if there were a problem worth solving, would it be unsolved? I'll refrain from asking how many people use digsigs, and what that solves. Only because that's rude. None of this solves life for average banking customers, but I think this is something that they are willing to ignore. Most people seem to trust one another. What do you do? -j -- Jamie Lawrence[EMAIL PROTECTED] The sign that points to Boston doesn't have to go there. - Max Scheler
Re: CDR: Re: Maybe It's Snake Oil All the Way Down
Sampo Syreeni wrote: Rather it's the fact that the Big Brother doesn't have the necessary total funds, and so doesn't listen into a considerable proportion of calls as a whole. Yet. As far as we know. :-) I agree it's an economic issue, and law enforcement doesn't seem to listen in on a considerable proportion of calls as a whole at the moment. But what happens to costs in the future? Remember, it takes 10 years to get any change to the cellphone/telecommunications infrastructure deployed, so it pays to think ahead. By the way, what's the story with those SIGINT planes supposedly advertised as being able to fly over a city and capture communications from the whole metropolitan area? John Young had a pointer on his web site at one point. Do you suppose they might snarf up all the cellphone traffic they can find, en masse? What proportion of calls would that be, as a fraction of the whole? One wonders whether your confidence in the security of cellphone traffic is well-founded.
[eb@comsec.com: Re: Maybe It's Snake Oil All the Way Down]
- Forwarded message from Eric Blossom [EMAIL PROTECTED] - Date: Tue, 3 Jun 2003 13:25:50 -0700 From: Eric Blossom [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Orig-To: John Kelsey [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], EKR [EMAIL PROTECTED], Scott Guthery [EMAIL PROTECTED], Rich Salz [EMAIL PROTECTED], Bill Stewart [EMAIL PROTECTED], cypherpunks [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Maybe It's Snake Oil All the Way Down In-Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.4i On Tue, Jun 03, 2003 at 10:42:01AM -0400, John Kelsey wrote: At 10:09 AM 6/2/03 -0400, Ian Grigg wrote: ... (One doesn't hear much about crypto phones these days. Was this really a need?) Yes, I believe there is a need. In my view, there are two factors in the way of wide spread adoption: cost and ease of use. Having spent many years messing with these things, I've come to the conclusion that what I personally want is a cell phone that implements good end-to-end crypto. This way, I've always got my secure communication device with me, there's no bag on the side, and it can be made almost completely transparent. And for cellphones, I keep thinking we need a way to sell a secure cellphone service that doesn't involve trying to make huge changes to the infrastructure, ... Agreed. Given a suitably powerful enough Java or whatever equipped cell phone / pda and an API that provides access to a data pipe and the speaker and mic, you can do this without any cooperation from the folks in the middle. I think that this platform will be common within a couple of years. The Xscale / StrongARM platform certainly has enough mips to handle both the vocoding and the crypto. Also on the horizon are advances in software radio that will enable the creation of ad hoc self organizing networks with no centralized control. There is a diverse collection of people supporting this revolution in wireless communications. They range from technologists, to economists, lawyers, and policy wonks. For background on spectrum policy issues see http://www.reed.com/openspectrum, http://cyberlaw.stanford.edu/spectrum or http://www.law.nyu.edu/benklery Free software for building software radios can be found at the GNU Radio web site http://www.gnu.org/software/gnuradio Eric - End forwarded message -
[eay@pobox.com: Re: Maybe It's Snake Oil All the Way Down]
- Forwarded message from Eric Young [EMAIL PROTECTED] - Date: Wed, 04 Jun 2003 01:05:24 +1000 From: Eric Young [EMAIL PROTECTED] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en To: [EMAIL PROTECTED] X-Orig-To: [EMAIL PROTECTED] CC: EKR [EMAIL PROTECTED], Eric Murray [EMAIL PROTECTED], Scott Guthery [EMAIL PROTECTED], Rich Salz [EMAIL PROTECTED], Bill Stewart [EMAIL PROTECTED], cypherpunks [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Maybe It's Snake Oil All the Way Down In-Reply-To: [EMAIL PROTECTED] Ian Grigg wrote: It's like the GSM story, whereby 8 years down the track, Lucky Green cracked the crypto by probing the SIMs to extract the secret algorithm over a period of many months (which algorithm then fell to Ian Goldberg and Dave Wagner in a few hours). In that case, some GSM guy said that, it was good because it worked for 8 years, that shows the design was good, doesn't it? And Lucky said, now you've got to replace hundreds of millions of SIMs, that's got to be a bad design, no? Well the point here is that the data encryption in GSM is not relevant to the people running the network. The authentication is secure, so there is no fraud, so they still get the money from network usage. Privacy was never really there since the traffic is not encrypted once it hit the base station, so the relevant government agencies can be kept happy. The encryption was only relevant to protect the consumers from each other. eric (hopefully remembering things correctly) - End forwarded message -
[eb@comsec.com: Re: Maybe It's Snake Oil All the Way Down]
- Forwarded message from Eric Blossom [EMAIL PROTECTED] - Date: Tue, 3 Jun 2003 15:50:37 -0700 From: Eric Blossom [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Orig-To: John Kelsey [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], EKR [EMAIL PROTECTED], Scott Guthery [EMAIL PROTECTED], Rich Salz [EMAIL PROTECTED], Bill Stewart [EMAIL PROTECTED], cypherpunks [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Maybe It's Snake Oil All the Way Down In-Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.4i On Tue, Jun 03, 2003 at 06:17:12PM -0400, John Kelsey wrote: At 01:25 PM 6/3/03 -0700, Eric Blossom wrote: ... I agree end-to-end encryption is worthwhile if it's available, but even when someone's calling my cellphone from a normal landline phone, I'd like it if at least the over-the-air part of the call was encrypted. That's a much bigger vulnerability than someone tapping the call at the base station or at the phone company. GSM and CDMA phones come with the crypto enabled. The crypto's good enough to keep out your neighbor (unless he's one of us) but if you're that paranoid, you should opt for the end-to-end solution. The CDMA stuff (IS-95) is pretty broken: *linear* crypto function, takes 1 second worst case to gather data sufficient to solve 42 equations in 42 unknowns, but again, what's your threat model? Big brother and company are going to get you at the base station... At our house we've pretty much given up on wired phone lines. We use cell phones as our primary means of communication. Turns out that with the bundled roaming and long distance, it works out cheaper than what we used to pay for long distance service. There is that pesky location transponder problem though. ...which will basically never be secured end-to-end if this requires each of those people to buy a special new phone, or do some tinkering with configuring secure phone software for their PDA. Hmmm, which key size do I need? Is 1024 bits long enough? Why do I have to move the mouse around, again, anyway? It doesn't have to be hard. No requirement for PKI. Just start with an unauthenticated 2k-bit Diffie-Hellman and be done with it. Eric - End forwarded message -
Re: Maybe It's Snake Oil All the Way Down
The White House Communications Agency is also working hard to secure presidential communications, with legacy systems needing ever-increasing maintenance and upgrades, the market continuing to outpace the big-ticket legacy clunker equipment, too expensive to chuck outright, yet having flaws begging for discovery, patches galore (most relying upon obscurity and secrecy), and the operators from the four military branches which run the system turning over regularly and each new wave needing special training to work the patchwork klutz, with retiring old salts who are the only ones who know how the hybrids work and whether they are truly secure, and not least, NSA doing it damndest to get new systems installed in all the prez's habitats and vehicles and layovers around the world, deploying crypto tools partly off the shelf, partly purpose-built at Ft Meade -- and the whole precarious mess subject to a 20-year-old pulling a thumb out of the dike and letting flow proof that the leader of the free world is up to what you'd expect despite the multi-million rig to hide the obvious. Rumor is that 98% of what is handled top secretly is trivial fluff, as with most mil comm, SIGINT, cellphone, microwave, fiber-optic, so that snake oil is apt protection. If all telecomm was shut down no more would change than pulling the plug on television. The other 2% is what the billions and billions is trying to find among the EM cataract of plaintext and speak smoke and whine -- by whoever may be plotting a world of pure bugfuck. But that could also be discovered by thoughtful analysis of any singular mania, whether religion, higher-ed, sport, stock market, politics, or mil-biz. Here's a recent account from Army Communicator of what's up at ever busier and harried and thumbplugging WHCA: http://cryptome.org/whca2003.pdg (680KB) WHCA itself is recruiting thumbs: http://www.disa.mil/whca
Re: Maybe It's Snake Oil All the Way Down
On Monday, June 2, 2003, at 07:09 AM, Ian Grigg wrote: PGP was also mildly successful, and was done by one guy, PRZ. The vision was very clear. All others had to do was to fix the bugs... Sadly, free versions never quite made the jump into GUI mail clients, so widespread success was denied to it. I would've characterized PGP version 2, 1992, as the first usable version. And it was done by about half a dozen people. The first version was not, to my knowledge, actually used by anyone. It might have done better had creaping featuritus and the integration with mailers and other programs and the better GUI distractions not dissipated so much energy. Also, the Clipper chip politics and the belief that PRZ was about to be arrested gave PGP a certain kind of notoriety...it became cool (bad, def) to use PGP. These days, that's _so_ 90s. --Tim May
Re: Maybe It's Snake Oil All the Way Down
At 08:32 PM 5/31/03 -0400, Scott Guthery wrote: Hello, Rich ... When I drill down on the many pontifications made by computer security and cryptography experts all I find is given wisdom. Maybe the reason that folks roll their own is because as far as they can see that's what everyone does. Roll your own then whip out your dick and start swinging around just like the experts. Are you trying to confirm that either the WASTE folks are homosexual, or puerile, as one might guess from the names of some of their projects? (Not that either impugns their code.) On the other hand, both AES and 3DES are US gov't approved. Which is sufficient reason to use Blowfish. Some of the other critiques of WASTE methods are substantial, however, in particular the SSL recommendations are useful tidbits to remember.
Snake Oil That Will Not Die
Oh look, it's a brand new fluff piece on Meganet and their Virtual Matrix Encryption, deconstructed years ago in various forums, including this one. http://www.inet-one.com/cypherpunks/dir.1998.01.01-1998.01.07/msg00047.html Why on earth is the Department of Labor giving them money? Meganet now claims that all other encryption methods have been compromised - except for theirs, of course. Titter. http://www.israel21c.org/bin/en.jsp?enPage=BlankPageenDisplay=viewenDispWhat=objectenDispWho=Articles%5El306enZone=TechnologyenVersion=0; - Company develops unbreakable data encryption code By Nicky Blackburn February 09, 2003 Meganet has won a $4 million tender to supply the U.S. Department of Labor with information encryption and digital signatures for its 18,000 employees. Meganet, an Israeli-U.S. data security company, has developed an encryption technology that appears to be unbreakable, enabling governments and corporations, to keep their data safely out of the hands of competitors, thieves and saboteurs. Among the clients that believe in their ability to protect sensitive information is the U.S. government ... Meganet Corporation's founder, Saul Backal, claims that its solution can put an end to these problems. Meganet offers a patented non-linear data mapping technology, called VME (Virtual Matrix Encryption), that creates exceptionally random cipher text and combines it with a one million-bit key, which is unheard of in today's data security markets. Competing solutions offer a maximum of 256 bits. There is nothing stronger in existence, says 38-year-old Backal, a dual Israeli-U.S. citizen who was a tank commander in the IDF in the Lebanon war. All other encryption methods have been compromised in the last five to six years. ... -- Eric Michael Cordian 0+ O:.T:.O:. Mathematical Munitions Division Do What Thou Wilt Shall Be The Whole Of The Law
Snake Oil That Will Not Die
Oh look, it's a brand new fluff piece on Meganet and their Virtual Matrix Encryption, deconstructed years ago in various forums, including this one. http://www.inet-one.com/cypherpunks/dir.1998.01.01-1998.01.07/msg00047.html Why on earth is the Department of Labor giving them money? Meganet now claims that all other encryption methods have been compromised - except for theirs, of course. Titter. http://www.israel21c.org/bin/en.jsp?enPage=BlankPageenDisplay=viewenDispWhat=objectenDispWho=Articles%5El306enZone=TechnologyenVersion=0; - Company develops unbreakable data encryption code By Nicky Blackburn February 09, 2003 Meganet has won a $4 million tender to supply the U.S. Department of Labor with information encryption and digital signatures for its 18,000 employees. Meganet, an Israeli-U.S. data security company, has developed an encryption technology that appears to be unbreakable, enabling governments and corporations, to keep their data safely out of the hands of competitors, thieves and saboteurs. Among the clients that believe in their ability to protect sensitive information is the U.S. government ... Meganet Corporation's founder, Saul Backal, claims that its solution can put an end to these problems. Meganet offers a patented non-linear data mapping technology, called VME (Virtual Matrix Encryption), that creates exceptionally random cipher text and combines it with a one million-bit key, which is unheard of in today's data security markets. Competing solutions offer a maximum of 256 bits. There is nothing stronger in existence, says 38-year-old Backal, a dual Israeli-U.S. citizen who was a tank commander in the IDF in the Lebanon war. All other encryption methods have been compromised in the last five to six years. ... -- Eric Michael Cordian 0+ O:.T:.O:. Mathematical Munitions Division Do What Thou Wilt Shall Be The Whole Of The Law
Re: more snake oil? [WAS: New uncrackable(?) encryption technique]
at Friday, October 25, 2002 6:22 PM, bear [EMAIL PROTECTED] was seen to say: The implication is that they have a hard problem in their bioscience application, which they have recast as a cipher. The temptation is to break it, *tell* them you have broken it (and offer to break any messages they encrypt in it just to demonstrate) but dont' tell them how you did it. That would probably be even more fustrating for them than the problem was :)
