Slashdot Mirror
Crypto Snake Oil
An anonymous reader writes "Luther Martin of Voltage Security has published an article about the perception of cryptography today with regards to quality and honesty in vendors. From the article: 'Products that implement cryptography are probably credence goods. It requires expensive and uncommon skills to verify that data is really being protected by the use of cryptography, and most people cannot easily distinguish between very weak and very strong cryptography. Even after you use cryptography, you are never quite sure that it is protecting you like it is supposed to do.'"
Snake oil is a traditional Chinese medicine used for joint pain. However, the most common usage of the words is as a derogatory term for medicines to imply that they are fake, fraudulent, and usually ineffective. The expression is also applied metaphorically to any product with exaggerated marketing but questionable or unverifiable quality.
'nuff said
Even though in many cases this might be true, and product prices are increased because of it, weak encryption is a lot better than no encryption at all. There are many people out there who might go as far as casual data theft (eg; taking someone at their school's USB memory stick), but even a weak layer of encryption will stop all but those who know what encryption is and where to start breaking it.
Warhammer forums
Samuel L. Jackson's favorite dish: Snakes in Oil! Probably virgin oil at that.
If you are worried about the honesty of vendors, this is exactly why you should be using free cryptography software in the first place, because you know that is going to be strong, and trustworthy, because otherwise someone would have changed it by now. :)
It is also much easier to verify strength by reading the source rather than by reading the binary or by cryptanalysis.
>Even after you use cryptography, you are never quite sure that it is protecting you like it is supposed to do.
Which is why everyone should enjoy themselves trying to break the encryption on any product they buy; be it wifi access point, USB memory stick, or a file encrypted with some PC software; trying to break the encryption is enjoyable and vital to continuing security.
So, for example, with a post like this, will somebody in a dark suit and glasses show up at my door tomorrow?
c id=15899118
Blasphemy #1: I've heard from a claimed friend of one of the inventors of RSA that it was cracked it years ago. Yet, it continues to get worldwide use. Sure my friend was probably full of it... but who am I suppose to trust here? The government?
Blasphemy #2: One of my close friend's mother had to switch fields from Numerics after she published some papers considered too sensitive. It had something to do with factoring.
Blasphemy #3: Anybody else notice that quantum computers have been proven to be capable of factoring really well, but no one has shown that they can solve any NP-hard algorithms? Come on... factoring isn't NP hard.
Then, there's just some silly stuff I've noticed about crypto. Why do we always seem to use encryption just a generation or so ahead of what is needed to crack it? SHA-1 for example... And, why do we encrypt one small block at a time. Each encrypted file usually gives many independent chances to crack the key, and in many cases, some of those blocks have known data. Also, public key is great, but secret key can be easily shown NP-hard to crack (in terms of secret key length) with semi-reasonable assumptions, while public key has no such simple proof. I personally have been trying to prove that no public key system can be NP-hard, but what the heck... I'm not that good. However, I do believe it's probably true.
It seems any time you start talking about crypto, you get assailed by experts telling you just how full of it you are. Consider something simple, like generation of random numbers. Just claiming you can do a good job brings nay-sayers out of the woodwork. See:
http://linux.slashdot.org/comments.pl?sid=193904&
http://www.billrocks.org/rng
for how to do it well. Any child could do it (well at least my geeky 6-year-old).
Everything about crypto is scary... Are we being manipulated into using weak encryption? Is there some invisible line, which if crossed, bad things can happen? The scary part is the unknown.
--
Just because your paranoid doesn't mean the world isn't out to get you.
Beer is proof that God loves us, and wants us to be happy.
Many Slashdot readers are savvy enough to know that when a software product advertises itself as using, say, secret encryption algorithms with 10,000 bit keys, it's probably snake oil. But I'm seeing increasing amounts of snake oil that uses the Advanced Encryption Standard, AES, and it can be just as weak.
AES itself of course is nigh-on as trustworthy a cryptographic primitive of its kind that we have. But just because you've used the right primitive, doesn't mean you've built a secure product. You have to consider what chaining mode to use, how to handle passphrases if they exist, how to keep your secrets secret, defense against side channel attacks, and more.
What I look for is a product that provides enough information that I can actually assess its security - what attacks they've considered and how they've built the product to defend against them. What I see disturbingly often is a bald declaration that the product is secure, because it uses AES.
Xenu loves you!
>> It requires expensive and uncommon skills to verify that data is really being protected by the use of cryptography
No. It requires reading a couple of good, inexpensive books and understanding of what the heck you're doing. Math behind the whole thing can be complicated. But you don't really need to understand the math 100% here. All you need to know is whether an algorithm is considered "strong" by today's standards, understand a few key concepts, guard your keys, and aproach security related coding with a healthy amount of paranoia.
In other words, a decent developer can get a pretty good understanding of this all in two weeks or less. And these skills need to become "common" already.
If you believe that, no wonder so much insecure stuff is being written. I have been called upon to review code written by developers with your level of knowledge in crypto. They do things like use RSA without proper padding, or use predictable IVs in CBC mode, or fail to properly authenticate the message. They also add totally unnecessary complexity to the system in the mistaken belief that their improvements make it more secure. I shudder when I see a copy of "Applied Cryptography" on the shelves because it is just enough knowledge to be dangerous.
Even the experts make errors in cryptographic protocol design and implementation - I've been doing this for ten years and I've made at least one howler myself. Why do you think, contrary to the advice of pretty much everyone who really knows their stuff, that people with a couple of week's worth of knowledge can get this stuff right?
Xenu loves you!
Products that implement cryptography are probably credence goods. It requires expensive and uncommon skills to verify that data is really being protected by the use of cryptography, and most people cannot easily distinguish between very weak and very strong cryptography.
Can you distinguish, by inspection, between a reliable automobile and a piece of junk that will barely last 2 years? I certainly can't. So I rely on reviews by people I trust when I buy a new car.
In the field of cryptography there are several people who have written peer-reviewed books about cryptography, are trusted in the community, and who occasionally review products. Bruce Schneier is one (there are others, use Google, this is not mean to be a puff for Schneier or his company).
There are also open-source cryptographic programs, which are peer-reviewed and definitely not snake-oil.
or you could just take the common sense approach and use products that rely on algorithms that are open, widely tested and reviewed, and known secure. Algorithms like Blowfish, AES, etc. I use Apple's built-in Filevault protection to encrypt my Powerbook's hard disk, in the event that it is ever stolen. It uses AES-128, which means I know that no-one is getting in without my password.
Any vendor that relies on a custom algorithm for their encryption technology shouldn't be trusted.
Get creative, use Rot-14 or something.
God spoke to me.
It's pretty well known that there are many snake oil products that deploy cryptography. Bruce Sneier frequently displays snake-oil cryptography products in his newsletter, for instance. And these are just the really obvious ones.
Some time ago, I tried to evaluate if a Enterprise Service Bus (intercomponent communication) was fit enough to be put into a production environment. It said that it had AES encryption build in. When I looked at the manual, it displayed a pop up window where you could choose the key-size. It listed exactly all key sizes that were *not* possible for AES. This was a very short evaluation, I can tell you. This also shows a very important thing about cryptography: the algorithms used say very little about the security of an application.
Generally, the manual for cryptographic services is easy to find. This is simply because cryptography is added at the end of the development lifecycle. This is logical because cryptography is not part of the main functionality of most applications (e.g. mime encryption in email products). It's something that was added after the products main functionality was finished. So just look at the last paragraph, or Appendix Z and you are looking at it.
Sometimes it is easy to see why so many products contain bad cryptography. Take XML signatures for instance. XML signatures themselves contain *references* to the data that is signed and the cryptographic techniques used. If you are to verify an XML digital signature, you *must* check if these are not altered. Furthermore, you must keep the XML schema-definitions on your own disk, and not retrieve them from the internet. Nevertheless, I've not seen any API-documentation even mentioning this rather obvious cryptographic insight. You can rest assured that there will be many implementations that will get this wrong.
Cryptography is hard.
The real insight of this story is the listing of the products into "credence goods". If you can call this new insight. Otherwise, it's just stating the well known/obvious.
This is something I've often considered about commercial encryption software. There's just no way to be sure of their validity, as they are closed source implementations. Open source solutions like Truecrypthttp://truecrypt.sourceforge.net/ are at least somewhat more trustworthy, in that they can be openly reviewed by anyone. Despite the fact that I know jack all about the specific math behind AES and such, at least I can read some simple explanations of the concepts, read the source, and decide if I want to trust my data to it. Honestly, unless we get down to the fraction of the population that actually does understand these bits at a deep level, that's the best any of us can do really.
Sure, large clusters of powerful servers working in tandem(or quantum computing) may render the factoral math behind crypto obsolete. A nice thing though, is that those kind of solutions are limited to those that can afford them. Still, even if it's all true, and I'm wasting my time encrypting things, what better solutions do we have?
In other words, for crypto-dummies of the likes of myself, it's probably better to stick with peer-reviewed, time-tested Open Source programs.
My new blog
Snake Oil Warning Signs: Encryption Software to Avoid
Last updated 1998, still insightful.
Any sufficiently advanced libertarian utopia is indistinguishable from government.
Anyone remember the Blitzkrieg server, which seems like the solution to all of the world's security needs? The expression Bruce Schneier used was "just too bizarre for words". I don't know if this was an elaborate trolling attempt or an actual real honest scam to deceive the terminally dumb, but it's fun to read, still, just for the amazing technobabble and ludicruous claims.
So did he write the article and then post it on wikipedia, or did he swipe it from wikipedia and post on his site?
http://en.wikipedia.org/wiki/Snake_oil
Not trying to troll, I just couldn't figure out which it was and I don't have a lot of time to investigate.
Transporter_ii
Doctors destroy health, lawyers destroy justice, universities destroy knowledge, religion destroys spirituality
All too often when people talk about their security solution they talk only about the cipher they are using, the length of keys and the time required to crack it.
Nowadays this is moot.
Security is in the protocol, how you exchange keys amongst parties and more importantly how you store the keys locally on the client and server.
I don't give a shit how strong your cipher is if your keys are negotiated in an in-appropriate fashion or stored in the clear on your machine. I'll do a dump of your memory and analyse the result for random looking data runs, chances are it's crypto related. Knowing the key and block lengths of your cipher getting past your security will not present a tremendous difficulty.
Unfortunately with security, you are not making something that will either work or it will not, you are adding protection to something that works. Hence it's pretty easy to hack together something that works but fail stands up to even basic analysis.
Real security lies in trusted platforms ( here we go...! ) and data hiding techniques using obfuscation. Unfortunately this sort of thing, data obfuscation in particular is difficult to explain to Joe public and can't be used to advertise you product.
Oh well, and Bruce, if you're reading this, how about a 2nd ed. of Practical Cryptography.
It isn't a matter of honest vendors. It can generally assumed that most/all cryptography companies are owned and run by the various security services. For decades a US/Swiss/Israli firm Crypto AG sold a cryptology machine with a secret built in backdoor. At least until Pres. Reagan announced on television that they were reading Gaddafi's coded messages.
There has also been speculation why Windows requires three unique signing keys. The disengenious reason given being that in case the first one got lost in a fire.
davecb5620@gmail.com
While I was searching for a crypto solution for my thumbdrive, which will work under Windows and OSX (and source for UNIX'a'likes would be nice), I came across some site that claimed something like, "5,000 bit unbreakable encryption!". I chuckled and then moved on without even reading what they had to say for themselves. Simply because just making some crypto scheme x,xxx bits is not a magic bullet. In fact, any company which relied on such a silly idea MUST by definition be peddling weak crypto. Even if they don't know it.
There are people in the World who think they know crypto. A very small subset of those actually do and then a very small subset of those can actually implement crypto properly and securely. I would guess that of all the big vendors putting out crypto products, you could probably count on one hand those which are doing a decent job of it. The World over.
How many poor bastards fall for the x,xxx bit crypto bullshit and fork over their money for that dubious security?
To protect yourself truly, you must know the people who theoretically can sniff your sessions and have access to your files: call them the "audience".
Your audience are either script kiddies with tools who want your CC number, or professoinal mathematicians hired to break access codes to your military research.
For the former audience, use google to make sure no tools are lying around ready to ruin your shit. Inventing your own scheme is actually a good idea.
For the latter, hire professional assistance, don't use your own coded-over-the-weekend scheme, and don't mess with the Russians.
If you are truly concerned about the validity of cryptography provided by the vendor, then try to find products that have been certified under the FIPS 140-2 standard. The only problem might be that a lot of those products are usually commercial grade items meant for use by government agencies; however, some of the items that have received approval are reasonably available to consumers. The products are reviewed by independent labs, and then the CMVP reviews the labs results. (The site was down earlier this morning.)
These products have been reviewed by independent labs, who review their implementation to verify that cryptographic mechanisms are implemented properly. This includes reviewing source code and/or hardware designs. Just a thought for anyone who is truly concerned that their hardware or software be compliant. (Note: If you want a "secure" operating system, look into CC Evaluation.)
"Some days you just can't get rid of a bomb."
http://cs-www.ncsl.nist.gov/cryptval/aes/aesval.ht ml
NIST maintains a list of those who passed the tests successfuly, and were certified to use AES in their products.
So, besides making sure that all the things mentioned by the parent were done right, check out whether the algorithm itself was properly implemented.
The saddest poem
Use ROT-12 to decrypt. Well, either that, or use ROT-14 twenty-five more times. It depends how much your time is worth to you.
Have you ever wondered How to Take Over
I worked for sevearal years on a programming language called REALbasic. In the latter releases that I saw, it featured "encryption". A compiler is basically a tool that takes human readable commands and turns them into a program that a computer can run. This process is not easily reversable, and once compiled, it's difficult at best to make changes to the progam.
Encryption was added to RB so that it was possible for you to give away portions of your program's "source code" (the human readable part) without anyone actually being able to READ it. They could incorporate your souce into their new project and use it normally, they could just not read it or make changes to it.
This sounds like a nice idea, until you realize that when you get someone's "encrypted" source code and add it to your program, the compiler has to be able to read the source code, because it needs to translate it for your new program. This means one thing: the encryption is not secure because the compiler itself must somehow posess a "master key" of sorts so that it can read the source code to do its thing. So... when you select the module and try to open it to look at it, it's not that it can't read it.. it's that it won't read it. A sufficiently skilled programmer could go into the compiler and flip a switch inside it and basically say "ignore that", and you would have unrestricted access to the so called "encrypted" informataion.
I assisted with a project where we found out how this information was encrypted. In short, a fixed key was used to encrypt the project data. Then a different fixed key was used to encrypt the passcode you would use to "protect" the project. Thus, the compiler could ask you for the password if you wanted to read your own project, and it could verify you typed in the correct passcode. If you did, it would decrypt the project for you to view. So you see, the compiler does not NEED the passcode, it simply WANTS it.
It took us about a week to write a program that would read in the projects, decrypt them using the fixed key and completely ignoring the passcode thing, and saved an unprotected naked project file that anyone could edit or view.
This is probably not too far from the mark on how a LOT of programs "protect your privacy". In reality they are only protecting you from the casual inspection. Anyone that really wants your data can get it, all too easily. Be sure that with any program you are certain that the program NEEDS the passcode to unlock your data. If it only WANTS it, (is there a password reset option available?) then you know it's "security through obscurity", and we know how totally worthless that is.
You thought your windows or OS X keychain was secure? You have auto login turned on? Does the computer need your password? Think about it.
I work for the Department of Redundancy Department.
From what I can see, this checks only that what the product is using really is AES; it doesn't check that it's being used correctly or that the product is secure as a result.
Xenu loves you!
If the author of the article is bringing this up, what does it say about his employer's products? I checked out the product at their http://vsn.voltage.com/ on-line service and it looks interesting. They also have http://developer.voltage.com/ a free toolkit for integrating their Identity Based Encryption (IBE) into applications.
What happens if I use predictable IVs in CBC mode?
I just finished up a system where I do use (very) predictable IVs in CBC mode (with AES128).
From what I could tell, an IV really only helps with preventing parallel dictionary attacks. That is, like people use against the UNIX crypt function (in passwd files). Since there won't be more than about 30 things ever encrypted with this key, I figured I didn't need the additional security IV gives me.
And besides, the IV has to be in the code or data somewhere, as it is one of the bits of data needed to decrypt. Most people just store it next to the cyphertext.
http://lkml.org/lkml/2005/8/20/95
Skype is the #1 "free" voip application around, both in features and amount of users. They claim to be using "very heavy duty crypto stuff, 256 bits this and that blabhlah". Yet there are no indication of a robust PKI scheme being in place (in fact, it's virtually impossible) which reduces their products security closer to zero. What they use is some auto-enrolling service that is protected by user account credentials. (Which are often weak.)
It's good enough against amateurs, and even professionals that can't get well enough into your network. However against anyone with proper resources it's simply trash. Furthermore they fail to mention that even if anyone can't eavesdrop your connection it is possible to determine other things from your usage - you are not completely safe. They've caught stuff like fugitives that have been stupid enough to use Skype already. Think about that.
Check out the author's company's product at the Voltage Security Network.
In fact, I am the Blitzkrieg server. Your attack has been logged. Your house will be destroyed in the next few minutes.
You have been warned.
One of the major perils facing a would-be crypto user is himself. Many people think they know it all (as evidenced in many of the posts to this article) and therefore can dictate insecure and plain silly design choices when deploying a secure solution in a non-trivial environment (for anything: authentication, the crypto itself, access enforcement, etc.).
For the vendor this creates a conflict. On the one hand, you want to satisfy the customer's request. On the other hand, you know your customer is shooting himself in the foot and very possibly becoming a vendor reputation problem later on down the line.
In my experience, most customers are accustomed to being "always right" and fail to recognize that crypto/security may be one of those things that they simply do not know enough about and to let the vendor help them. It is often the case that the vendor can explain/evangelize and detail the very attack the customer is opening himself up to with little or no effect - the customer is convinced they know it all.
Ok, I'll be fair - though God alone knows why, and I think even God gave up trying to figure out the tangled mess I call a brain some time ago. They did use DES - not triple DES, just plain DES - for the really really sensitive stuff. The encryption key was visible to anyone logged in on any account, however, as the DES they used required the key to be the first parameter and they made no effort to erase it. So it was technically encrypted. (Once the passkey has been broadcast to all and sundry, I do not regard the encryption as anything more than a technicality, and in the case of DES, I seriously doubt you could even claim that.)
I've heard that security has since improved. I say "heard", because it was some time AFTER security was said to have been improved that reports started coming out of a fileswapper using NASA storage machines as extra disk space - the very same organization and very same type of mass storage device I had serious doubts about many years prior to that.
But that's a Government institution! Yes, and they're the ones with a great many experts in such matters and a great many contracts with people who can not merely withdraw business but also guarantee a disaster in the next election. The bulk of private corporations out there have neither the skills to draw on OR the incentives to maintain some sort of standard. All they have to do is ROT13 and tell you it's got digital security. Enough suckers'll buy into it to keep the CEO in champaign, caviar and girls of commercially-negotiable virtue for life.
The problem is, there is no mandated minimum standard for security, so those who can WILL use the lowest standard possible that will deceive customers into thinking they're safe whilst staying a gnat's whisker (after being compressed by the forces of a neutron star) beyond what could be sued for in courts, assuming a technically ignorant judge.
IMHO, "snake oil" could be vastly reduced - not eliminated but reduced - by placing minimum standards for crypto, compression and other easily-manipulated areas of technology, and enforcing them. Not maximum - that's what the intelligence services want, and they want it to be zero. I'm strictly talking minimum. Your good, old-fashioned lemon law - does it fill the purpose for which it was sold to the customer? Yes or no.
In the case of cryptography, that would be rephrased as follows: would a reasonable person, aware of the strengths and deficits of the technique concerned, aware of any warnings published on the block crypto lounge, hashing function lounge, etc, aware of the Usenet Crypto FAQ (ie: aware of the "common knowledge" that exists on cryptography), and aware of the grade of security the user is demonstrably expecting, agree or disagree that the cryptographic system sold meets the grade expected or not?
If it does not, it is a lemon for the purpose for which it was sold. It might be perfectly good otherwise, but it doesn't, can't, and never will do what was expected of it.
This would be enforceable, as I said very clearly that I'm talking about weighing the "common knowledge" against the "personal expectation". Both are easy to define and even a non-expert should understand a skull-and-crossbones labelled "BROKEN, DO NOT USE" in a crypto lounge. They might not understand the fine nit-picking or the advanced maths, but that's why I'm sticking solely to what is commonly known and understood, not what is derivable from axiom 327 as applies to lemma 291 as described by Professor Branestawm's obscure paper entitled "techniques for splicing dormice genes into giraffe brai
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Because WPA is inconvenient when you're using a device that doesn't support it.
WPA-supporting devices are all but mandatory for laptops and WAPs these days. If your device doesn't support WPA, replace it.
These WEP is little more than a "no tresspassing" sign - it will keep people from accidently connecting to your WLAN, but not much else.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
the NSA has been telling people for years now to not rely on RSA. They suggest switching over to Elliptic Curve or other advanced algorithm.
Provide a cite for that, please?
I don't personally feel very kindly disposed towards RSA - I don't see any advantage it has over Rabin-based schemes and important disadvantages - but I think it is scaremongering to say that the NSA have been warning people about it.
Xenu loves you!
If a million people read the code, and 1 in 10,000 were cryptographers who examined the code closely, that's still 100 cryptographers examining the code. Assuming most of them were working independently or in small groups, that's good enough for me. It's probably a lot better than a closed-source solution where maybe half a dozen experts looked closely at the code.
The best thing about open-source is that if it's a real concern to you, you can hire your own experts to check out the implimentation. You don't have to take the vendor's or anyone else's word for it.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I'd like to be funny and say it's because I've used OpenSSL, and I am astounding anyone (including myself) is capable of making a system that works with it, let alone is secure. It's a complete disaster.
But really it's because the system I'm using is an embedded system. And by embedded system I don't mean a full-blown PC running Linux, I mean a small system. I was allocated about 4,000 instructions for my crypto work (and an AES ECB accelerator).
In CTR mode, the each encryption doesn't depend on other data encrypted before it. Thus someone could change a single 128-bit area in the cyphertext and it wouldn't affect anything else. This greatly reduces the difficulty at changing my cyphertext to change the plaintext in certain areas without it being detected after decode.
I appreciate your info, but I think you're jumping to huge conclusions about my system. Again, in my system only about 30 pieces of plaintext will every be encrypted. And they will be encrypted by legitimate users. So I don't have to worry about people trying to guess the IV before encode. There are no clients of my crypto code that are malicious (and if they were, they'd have brought the company down already, crypto or no). And besides, if you were to break into the code I am securing, you'd just change the system so that the crypto wasn't used instead of trying to game IVs.
I guess on of the most important things is that I'm using crypto for authentication more than message hiding.
As to your last statement, I wasn't speaking of anything but AES128 here. But I think I did use RC5 without an IV for crypto in a previous product. It wasn't broken, it was exploited (bypassed), making all of my efforts moot anyway.
http://lkml.org/lkml/2005/8/20/95
Get a console with wired connection then use a standalone WAP. If your favorite game doesn't support that ask yourself if you would rather be safe or have fun.
The other alternative is to make sure there's nobody within range who might be hostile, or put up a faraday cage around your gameroom or house.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Discussing encryption under ideal circumstances is like saying birth control pills are 99.97% effective when taken as directed in laboratory studies.
If lots of smart people *haven't* reviewed a system, then it probably wasn't interesting enough to review, so don't bother with it. This includes commercially distributed systems like GSM cell-phone encryption and WEP, both of which collapsed when a couple of smart people at Berkeley looked at them (IIRC, GSM's algorithm took three hours to crack instead of two, because the Chinese lunch Ian was having was interesting that day, but I may have the details backwards.)
Microsoft's PPTP used RC4, which lots of smart people had looked at. Problem was, the smart people all said "It looks pretty strong as long as you don't do this or that with it", and Microsoft's design found a couple of different ways to do this and that, as well as recycling some other weaknesses from older products.
That's why the kinds of people you're giving advice to definitely should *not* use OTPs. The rules for using them are very simple - the pads have to be purely information-theoretically random, and you have to make sure they can only be used once. Those rules make OTPs operationally annoying to use, which results in clever (as opposed to smart) people "fixing" the problem by generating their one-time pad using some algorithm or other, or sloppy (as opposed to stupid) people doing things that let pads be reused or stored or copied or whatever. The Venona decryptions were successful due to Soviet operators reusing "one-time" pads when they ran out of new ones, and also because the randomization methods (clerks banging on typewriters that had original and carbon-paper copy) weren't really good enough randomness.
Cryptography's harder problems are mostly implementation-related. There are enough really strong algorithms out there to make good crypto possible, though occasionally there'll be attacks on important algorithms like MD5, and Moore's Law means that you need to be careful that key lengths are good enough for the length of time you need to protect your information, and strong keys won't usually protect you against the KGB installing a bug in your computer's keyboard or pointing a ceiling camera at your monitor. But design of intermediate problems like key exchange or user authentication can still be difficult, and integrating them into applications and operations is still hard. We're at the point that you can build a nice solid steel front door to your building with an unpickable lock on it, but that doesn't mean that the side windows aren't open, or that the parking-lot valet didn't make a copy of your keys.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Let's consider this conversation between me and you over. I ask for help with one thing and instead of get criticism from people who don't know anything about the system I implemented (and I like it that way) insulting me as not even knowing as much as they got from reading a single book.
The useful part of this conversation is clearly ended and I don't see any point in hurling judgements at each other.
http://lkml.org/lkml/2005/8/20/95
Again, the system I'm on is not just a PC in a box. Performance is critical, and I can't use a two-pass system.
I'm sure it's great to have a ton of MIPS available and to be able to choose from many complex modes of operation, but that's not the situation I'm in.
Your judgement of wrong and right assumes you know all the tradeoffs. You don't. Please leave out your uninformed judgements. I just asked from some help on IVs, and as far as I am concerned, I got it. So if you think you can't help me further with the amount of information I am able to give, then I understand.
http://lkml.org/lkml/2005/8/20/95
None of this is an insult against Apple's product - I don't know what they're using. I've seen a wide variety of similar applications over the years, and saying that they use AES-128 only says they've done the obvious parts well, so the product runs as fast as a well-oiled snake. It doesn't say whether it's secure or not.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I think instead of just using broken crypto and advertising as "uses 128-bit AES for maximum security", I'll instead do that AND insult others. I'll be sure to pass immediate judgement on others and state I know what their plan is without knowing anything about what they're doing.
Then I'll be following the example of you, it seems.
Thanks for the initial help. No thanks for the ivory tower bullshit.
http://lkml.org/lkml/2005/8/20/95
You know that's not how it is, right? In practice, if a hundred thousand people download it, then at most a thousand will hack on it, at most twenty or so will thoroughly review the security related code, and an average of zero of them will be cryptographers.
In the unlikely instance that a cryptographer does review it, they will suggest changes, and they'll be told to get lost; cf Gutmann trying to tell people to use proper padding with RSA, or my conversations elsewhere in this thread.
Xenu loves you!
Actually such systems do exist, are surprisingly good, and getting better. They read a formal protocol specification in their own special language rather than source code, but they find real attacks that others have missed. I don't think they're ready to replace experts yet, but they're good enough to be used to find the things the experts missed.
Xenu loves you!
Some level of personal responsibility is called for, too. I frequently see memory sticks lying beside piles of books at the library. If people can't be bothered to physically protect their belongings, cryptography protection won't prevent someone from picking it up, wiping it, and gaining a nice tool for themselves!
Goddamned kids! Get off my lawn!
A lion can only bite one person at a time. An attacker or a worm can attack many at once.
This is what breaks many intuitions about network security. People say "I have nothing worth taking, so no-one will attack my network". But as you surely know, unless suitably firewalled, a PC will come under attack within minutes of being put online, because each attacker attacks millions of machines at a time so attacks are cheap.
Xenu loves you!
Good grief. It's rare to see a company with such brilliance behind it selling more snake oil than Voltage. Their "identity based encryption" is really "email-address-based encryption" - i.e., anyone who can read your email can also read your encrypted email. It's basically using a genius mathematical invention to enable your mail provider to do key escrow. Pass.