See if you can IMPROVE on THIS privacy plan!

Good question Jim.

If the sender is really really worried about the message being "cracked" by "someone" they could of course write the original message in a substitution code or better of their choosing then password protect the attachment and encrypt the whole thing. So the "snoop" has 3 levels to beat. Still NOT fool proof.

But one has to ask if this message needs all that protection maybe it should not be written at all or sent in the first place.

 

Sbwave email encryption is a free service that encrypts text messages for email delivery.
http://www.sbwave.com/enkryptor/home.html

 

That's good, text is better than M$ Office document

 

Escalader -yes it is and no adverts either amazing

 

One post trimmed from the thread - let's make sure that the thread doesn't take a political turn. If it does, the thread will be closed.

Regards,

Blue

 

You are giving the NSA and CIA too much credit. Remember the simpsons movie where some agent was in a huge phone tracking room at the NSA, and said something, "finally, we have picked up something useful!" Ironically, their massive surveillance system provide so much info, that they have trouble sorting through it. I'd be more concerned with old-fashioned sleuthing rather than high tech surveillance. You'd seem to stick out with all that stuff.

 

You may not be giving the NSA enough credit. Do you think that the7y collected all of this info just for fun? I am sure that they have a way of searching through it.

 

Hello,
People working at security agencies are people like you and me. They are not Hollywood movie stars getting satellite images and reconstructing things in 3D in real time. That's science fiction.
Mrk

 

Yes, go to http://phoenixlabs.org/ and add :

 

Some thoughts.

I do! As referenced by this audit (U.S. Department of Labor - Office of Inspector General - Office of Audit - March 2005), the Department of Labor spent $3.8 million on Meganet's snake-oil, yet decided not to use it. Quite a large sum (to me, at least) wasted on perhaps the ugliest craptographic mess I've ever seen. I personally confirmed this with the Department of Labor after reading the press release from Meganet, in early 2002.

Despite the fact that government agencies have access to good cryptography (i.e., the NSA), you'd be surprised at the money they waste on boneheaded decisions like this. However, regarding the AES, the situation is different; in some cases, commercial implementations of the AES could be significantly cheaper than in-house, custom implementations. In such cases, it makes sense for the government to opt for the former.

There's no doubt that Serpent was built like a tank, and was the frontrunner, when "security margin" was taken into account. However, there's an important thing to take into account, when looking at distinctly designed primitives under this model. Consider that Rijndael, Twofish, and Serpent all have different round functions; in other words, each block cipher's design team decided what they felt should happen during each round, respectively. Needless to say, "what they felt," being subjective, differed between the teams. While "security margin" is a useful, generic model for juxtaposing cryptographic primitives, it has its limitations. Let's look at an example that demonstrates this by putting "security margin" into perspective.

Assume we have two block ciphers, A and B. A is a Feistel, while B is an SPN. There's a truncated differential attack on A that covers 7 of its 10 rounds and a higher-order differential-linear attack on B that covers 20 of its 40 rounds. On the surface, we can say B is stronger than A, because it still has 20 rounds left untouched, whereas A is only 3 rounds shy of a full break. On the other hand, this starts to lose value, when you consider that we're talking about two block ciphers based on different structural designs, using two different round functions, and analyzed using two different attack models. It could very well be the case that extending the attack on B's remaining 20 rounds is easier than extending the attack on A's remaining 3 rounds. It all depends on what's going on inside the round function.

While there are valuable design philosophies tucked within Twofish and Serpent, there's a good reason to use the AES; as I mentioned in a previous thread, it's receiving more cryptanalytical attention than any other block cipher - Twofish and Serpent included. This reasoning should be compelling enough for anyone, and you'll find that it's supported throughout much of the cryptographic community. Unless environmental constraints prevent it, for whatever reason, I strongly advise developers and consumers, both, to use the AES, when at all possible.

 

Re: Some thoughts.

Nice post, there's food for thought in your words.
Regarding hash functions, is still safe to use SHA-1? Or we better switch to SHA-256, Whirpool, Tiger?

 

On hash functions.

I appreciate it!

As for SHA-1, its safety depends on how you use it. I wouldn't use SHA-1 in applications that depend on collision resistance, but HMAC-SHA-1 would probably suffice in applications that need a PRF or MAC. Conservatively speaking, though, I would avoid using SHA-1 in new designs. If you need something standards-based, then SHA-256 seems like a decent interim standard, until we have a new standard sometime around 2012. It would, however, be nice if the NSA would share the design principles behind SHA-256, so we'll know just how much more security it buys us over SHA-1. (On a side note, if you need a PRF or MAC, I recommend CMAC-AES; it's a good PRF, therefore a good MAC, too.)

I've read some comments by others who suggest using Serpent over Rijndael, because they feel its larger security margin is more conservative; in my previous post, I discussed my thoughts on this. They also recommend using Whirlpool as a hash function, probably because of the length of its output. Recommending Whirlpool while suggesting alternatives to Rijndael doesn't make so much sense, once you realize that they're based on many of the same principles.

It shouldn't surprise you when I say that Vincent Rijmen co-designed both Rijndael and Whirlpool. Rijndael and Whirlpool are both based on the wide trail strategy, with Whirlpool's internal block cipher, W, being very similar to that of Rijndael. It uses strengthening of the Merkle-Damgård variety, and a Miyaguchi-Preneel hashing construction. I think it's a good choice, if you don't need a standards-based solution. Between now and 2012, I'm sure we'll learn a lot more about it and have a better idea as to how well the wide trail strategy fares in hash function design; in return, it will give us some useful insight into the security of block ciphers based on the wide trail strategy, as well.

Back in 2005, amidst the explosion of hash function cryptanalysis, I wrote about an aspect that many reports were overlooking; that is, most of the hash functions we have are based on the same design principles, and are subject to much of the same cryptanalysis. Quoting myself:

Overall, SHA-256, as an interim standard, is probably the most obvious recommendation. We can do a lot better than SHA-256, though, as we've learned a lot since the days of that on which SHA-256 is based. New designs should use it, and old designs should make every effort to transition to it. Moving from SHA-1 to SHA-2 seems like the most reasonable reaction to the situation with hash functions; it's the easiest, being standards-based, which many rely on. It's important that we don't obsess too much over this, though.

 

Re: On hash functions.

Points taken
Congratulations on your promotion to Cryptography Expert, well deserved

 

SecureAction and the NSA

I appreciate it! It's my hope that I can share some of the valuable things I've learned, so that it might better shape what folks demand out of their cryptographic software. There's are huge gaps between cryptographers, developers, and consumers; it's my hope to play some part in closing them.

I wouldn't use any of SecureAction's products, personally. The comments I'm about to make, I've already addressed in an e-mail to them. I've yet to receive a reply, but I'll emerge from my lack of optimism and give them the benefit of the doubt.

Their presentation is poor, and is in objection to good cryptographic engineering. Having said that, let's pick apart some of the lousiness on their site. Quoting from their site:

Multiple block ciphers do not make a product better or more secure; at best, it's clutter. What I discuss in this post applies. In summary, when cryptography fails, in practice, it's almost always because of the implementation. Therefore, it's in our best interest to simply the implementation by addressing the appropriate threat model without any unnecessary complexities. Most threat models need confidentiality and integrity; in more cryptographic terms, they want IND-CCA2 /\ INT-CTXT security. This is achieved through encryption (e.g., AES-CTR) and authentication (e.g., CMAC-AES), in that order (i.e., the Encrypt-then-Authenticate composition). As you might noticed, the AES can be recycled for both purposes.

We don't need a dozen or two block ciphers. It increases the likelihood of making an implementation mistake and confuses the user with too many options, of which they don't know which to choose. Their statement, "makes it even more secure by adding a host of new encryption algorithms," is incorrect; it's backwards thinking and certainly not indicative of good engineering practice. In reality, it wouldn't surprise me if it's a marketing ploy, which doesn't surprise me anymore. I've had quite a few software vendors admit to things like this before. After all, they're merely software vendors; they're not cryptographers, or even security folks. Unfortunately, they shape what many consumers feel good cryptography should look like, even if it makes no sense at all.

On top of this, they throw in the meaningless "military grade" jargon, which is usually marketing bait. If it's not a marketing ploy, and they actually believe that cramming in a multitude of block ciphers makes their product more secure, then the situation isn't any better; it might be worse. What bothers me even more is that, while they spend so much time talking about how many block ciphers they use, they don't even mention which mode of operation they operate in, nor if they preserve integrity any way. Even if they're using an IND-CPA secure mode of operation, such as CBC or CTR, it does nothing for integrity. You need a MAC for that; it follows that if you don't have a MAC to preserve integrity, you might also find that your confidentiality is gone too.

If you want confidentiality, you want integrity too. I would steer clear of any product that doesn't take this into account. Sadly enough, for every one that does, there are 100 that don't. Even more sadly, that's probably an understatement. Based on these concerns alone, I can see no reason why you'd want to trust your data to their products. Hopefully their marketing isn't an indicator of what's really under the hood.

On a side note, I notice talk about the NSA and their cryptanalytical capabilities. I'm not of the opinion that they have any attacks against the AES. They don't need any, though. Why? Because there are almost always easier ways at getting at data. I'd say the NSA is pretty good at this. Be it the NSA or whoever, if you have the type of security that forces them to look at going through the cryptography, as a last resort, you're doing quite well. Teach me!

 

Re: SecureAction and the NSA

And if the NSA is behind your steps, cryptography will be the least of your worries.

 

Justin,
I know I welcomed you in the "welcome thread" and told you how excited I was that you are posting at Wilders, but after reading a few of your excellent posts (like the one above) I had to again say how great it is to have you here! People I respect consider you one of the best and brightest. I especially like your wanting to bridge that gap between the cryptographers/developers and end-users. Again, welcome. (And for what it's worth - I agree completely about SecureAction and the lack of a clue regarding cryptography by wayy too many developers & vendors of encryption software.)

 

Thanks again, and some more on the gaps between.

I really appreciate that, Gerard. It's an honor. I owe it to the pioneers whose work paved the way for the up-and-coming generation - myself included.

These gaps between cryptographers, developers, and consumers certainly need to be closed, and I have no doubt that security will look a lot better, in many ways, because of it. Right now, we have the tools to get the job done, but the folks using these tools don't know how to properly use them. There's some bad news, though. I'd like to tell you that educating developers will solve the problems completely, but it won't. It's not enough that developers know how to use the tools properly. First, they need to know which tools they should be using. This is what we know as threat modeling. It's where a good design begins, so you'd better get it right, because everything thereafter depends on it.

Bear in mind that much of the cryptographic software you see is the product of software vendors. Not cryptographers. Not even security folks. Without a cryptographer on board, or a well-versed-in-cryptography security expert, at least, you're placing your bets on software vendors to establish the right threat model; it's a crapshoot, really, and the odds aren't in favor of the consumer. We can educate them to a certain extent, but to understand what security looks like, you must first learn to recognize insecurity, which takes a certain kind of expertise that, I'll be the first to tell you, comes with a lot of experience.

The situation with cryptography is a difficult one, because we don't have a central regulatory body to tell consumers what's safe and what's not safe. Even worse, the closest link between consumers and cryptography is rarely a cryptographer; it's usually a software vendor, without any cryptographic expertise. Cryptographic design is a little bit art and a little bit science, yet it's alarmingly easy for anyone, oblivious to either, to try their hand at it. What you end up with is a lot of software that's mostly bad, but coated with enough marketing veneer to make it look good in the eyes of unsuspecting consumers.

It's up to cryptographers to instill this better thinking by making it more accessible to consumers. Examples of this are snake-oil FAQs and such (e.g., Bruce Schneier, Matt Curtin, et cetera). Some software is so blatantly horrible that it's easy to apply these snake-oil detection techniques, but some can slip through. Sometimes it's hard to tell the good from the bad. Albeit imperfect, anything that gives consumers a better chance at dodging the bad is a step forward. Conditioning consumers on what to demand out of their software is as important as educating developers on how to properly design it. Look at it as attacking the problem from both sides.

 

So Bruce Schneider is snake oil?

 

Any privacy software is only secure as its weakest link.

As you can see from "Hushmail" articles, they will readily hand over your confidential email to the authorities.

EDIT: I suppose you would probably want to trick people into thinking you are another harmless user by sending messages in pictures or creating a completely new secret code not related to computers. LOL

 

Caspian,

No, Justin wasn't saying that. Just the opposite.

He's saying that Schneier's FAQs (and Curtin's) -- concerning snake-oil -- are examples of cryptographers making cryptography easier for consumers to understand.

 

Hmm.

Bruce Schneider might be snake oil. I don't know him. I'm pretty sure Bruce Schneier isn't, though. Hehe.

Thanks for clarifying that, Gerard.

 

Hushmail is not the way forward for real privacy.

Check out the anonymous remailing systems like mixmaster. Those systems make it very hard to track the user down. Coupled with decent encryption the chances of some agency being able to both track the connection between you AND read the message is very small...as far as anyone knows.