cwCrypto Beta Testing

Let’s assume that UserA has UserB’s public key, and UserB has UserA’s public key. If, for example, UserA wishes to send an encrypted email to UserB, then UserA encrypts the message with UserB’s public key. Upon receipt of the message, UserB decrypts the message with his corresponding private key. The public keys can be freely exchanged without any privacy risk, since they are used only for encryption. The corresponding private keys, however, never leave the possession of the users who created them.

I recommend that you review the excellent book Introduction to Cryptography by PGP to learn more about public/private keys.

 

Very interesting. Will read more.

But seeing as how that requires a complete redesign of the program from the ground up, I think we will just see how the public handles this as is. If, in the future, it is deemed as a necessity, we will look into ways to implement it.
I prefer the program to work without having to rely on anything additional than the program itself. Makes it easier to pass a message on to multiple people, and able to keep it as a stand-alone installer.
No stored files, remote files, or anything to manage for the user.

 

You know, this is tough. Capp is a valued member here at Wilders and I respect him greatly. But there are two issues here:

1. Computer knowledge
2. Cryptography & encryption implementation knowledge

While I highly value Capp's general computer knowledge, I am a real stickler (as many of you know) when it comes to security and encryption. I feel strongly that encryption software should be left to cryptographic specialists who then work with the developer for careful and correct implementation of the cryptography.

Without going into a lot of my personal opinons on this particular project, I'll offer this: I have great respect for Justin Troutman and we've been lucky enough to have him post here on occasion. Here are all of his postings here at Wilders (almost all related to encryption software). Also, a quick browse through this thread will shed a little light on what kind of scrutiny any new encryption product will receive here.

With that said, it's tough because Capp is a great Wilders member and knows more than I ever will about general computer matters.

 

Well, thank you for the kind words.

I can assure you that the implementation methods for this program are in line with the developers requirements, documentation and specifications.

One of the best things about it is, you can see immediately the results of the encryption. So, you can physically see the difference. Now, if I were to store you encrypted data in a database or encrypt a file, you would pretty much just have to trust that it is done right, since it is all behind the scenes. But by showing you the results as they happen, you can see what is going on.

We don't claim to be the best at cryptography and it is a tough and scrutinized field to dabble in. Our other software packages have won many awards and received lots of praise, but also received criticism and questioning, but we stand by our products.

This is a Beta release, so there are bound to be bugs missed and hopefully reported so we can fix them.

One of the main reasons we post our software releases at Wilders is because of the massive collection of talent and knowledgeable individuals that come here. Knowing full well that if we are in the wrong, they will call us on it.

I guess our biggest hope is that you try it before you make a final decision.

 

LOL

You are designing encryption software and have never even heard of Diffie-Hellman public-key cryptography? That is bad, very bad. That's like an aerospace engineer never having heard of the Wright Brothers or Stephen Hawking never having heard of general relativity. Wow, just wow.

Bruce Schneier is right -- there is a LOT of snake oil in the encryption software industry.

 

Not sure where you got that. Never said we never heard of it. Said we would read more from the link he sent us.

 

When designing cryptographic software, history is your best friend. What history tells us is that when cryptography fails in practice, it's almost never because of the cryptography itself, but the implementation -- be it because of complexity and/or incompetence. Allowing arbitrary passes of multiple algorithms isn't best practice, or even good practice. The more options you have, the more complexity you have; to say the least, complexity is security's worst enemy. In the case of real-world cryptography, it's the bane of its existence.

On top of that, I see no mention of message authentication. With encryption, you're preserving confidentiality; with authentication, you're preserving integrity. Best practice suggests computing a MAC (Message Authentication Code) on the ciphertext of an encryption scheme that's secure against adaptive chosen-plaintext attacks; that means computing AES-CMAC on the ciphertext of AES-CBC, for example. If you're not already doing this, then you're light years behind; you even risk losing confidentiality due to a lack of integrity.

Some time ago, I collaborated with Vincent Rijmen (co-designer of Rijndael, the primitive behind the AES) on what we call "green cryptography," which aims to recycle as much as possible without sacrificing security; with that in mind, it's easy to recycle the AES in an authenticated encryption scheme that achieves the strongest notions of confidentiality and integrity we have. Give me authenticated encryption over a legion of block ciphers with a million passes any day. Don't feel bad, though; after contacting a few dozen software companies, I found this to be a fallacy of all but one -- that one being AxCrypt.

Cryptography, in the real-world, is saturated with subtleties -- many of which are not obvious. The need for authenticated encryption is essentially one of the cryptographic commandments, which should be known by heart; if you don't even know it at all, then you're certainly in no position to be designing cryptographic software -- unless, of course, you hire a cryptographer. There's a gap between cryptographers and developers, which makes cryptography less tangible than it should be; we [myself, Vincent, and others] are actively working on closing it.

By the way, what modes of operation do you use? Regardless, I would recommend implementing only AES-CMAC for message authentication and AES-CTR and/or AES-CBC for message encryption; there's little need for anything else in this type of application.

 

Thank you Justin for taking the time to contribute useful tips and information, I really appreciate it.

I failed to mention this above, but the program does CBC when encrypting.
Here is the simplified process that is taken when doing the encryption for each algorithm:

1) Add 12 bytes (4 bytes for the length and 8 bytes for the seed values for the CBC routine).
2) Store a block of random data in bytes, which work as seed values for the CBC routine and is used to produce different ciphertext each time the text is encrypted.
3) The data is encrypted in 64-bit blocks and each block of plaintext is XOR'd with the previous blocks ciphertext.

 

No problem. Cryptographic implementations receive nearly the lion's share of cryptography's insecurities in the real-world; this is where the attention needs to be.

Okay, so you're seemingly using CBC with a randomized IV; this is essential to IND-CPA security, which is what we expect of any secure encryption scheme. However, this does nothing for integrity; therefore, you cannot provide any meaningful sense of protection against adversarially manipulation. I caution anyone against continuing with designing cryptographic software for public release if they aren't aware of the need to authenticate encrypted information.

 

I just noticed that "snowdrift" posted, but apparently deleted it; out of curiosity -- why do I find most of "snowdrift's" posts deleted? If you have feedback to share regarding my comments, I'm always more than happy to discuss it.

 

He posted a link to a comic strip that had no relevance to the thread. As has happened a few times. It had nothing to do at all with anything you or I said.

If someone has a general comment, question, suggestion or recommendation about the software, I am all ears, but if you feel like posting to insult, talk about how it'll never be as good as xyz software, or make snide comments/rude remarks, or things that have nothing to do with the software in question, please either don't reply at all or send it to me in a PM.

 

Hi again Capp. With all due respect, I don't think Justin meant anything personal. When he spoke of "integrity" he was speaking of it in a cryptographic context, not in the context of personal standards. He was also talking about your not being able to provide meaningful protection against manipulation because of the lack of MAC (message authentication). This is something he is very vocal about within the cryptographic community. He sees a lot of software being developed without a MAC process and, in general, advises against further development of cryptographic software without authentication. I think you might have misread his comments as being personally hostile when, knowing Justin from his writings here and elsewhere, I know that he was speaking in generalities and since your software doesn't provide for a MAC, he was telling you what he vocally fights for at cryptographic seminars, etc. Truly, I can say with near certainty, that Justin Troutman wasn't meaning to personally attack you in any way. Software developers pay Troutman for his opinions and expertise on these matters and he basically told you what he would have told any developer that didn't program the software with a MAC. Have I made sense? I hope so, because I know what he was saying and can see how it may have been misinterpreted.

When I urged you to read the thread I linked to in an earlier post, it was really a heads-up as to what to expect. The scrutiny and opinions regarding cryptographic software is white hot.

Best to you!

 

Hi and I think you misunderstood . I took nothing Justin said as an Insult or anything other than very useful advice. He had asked about another users comment being removed. The other users comment was what was inappropriate for this thread.
I have read all i can get my hands now over MAC and proper implementation for what I need it to do. I am currently working the program to utilize it for better protection and integrity.
I value Justin's opinion and enjoy when people make recommendations such as his, because it only improves our software.

Thank You

 

hi Capp, keep up your good work

 

I do not know if PGP was among the “few dozen software companies” that you contacted, but I do know that PGP Zip provides an option to sign an encrypted file. Does this not also provide authentication (i.e., enhancing certainty of the identity of the creator of the encrypted archive) as well as integrity (i.e., knowing that the contents of the encrypted archive have not been altered)?

Note that Sigcheck displays a MD5, SHA1 and SHA256 hash of a signed PGP Zip file.

Thank you for this clarification.

 

You're absolutely right; it's never personal. I only meant to evoke a sense of caution; in fact, my tone is lighter than much of the field -- a field in which respect is personal and always a given, but cracking a verbal whip on a lousy idea is fair play. And, it really needs to be that way, because the ramifications of leniency and laxness can be detrimental. Any good standard is born of blood and sweat, due to years of taking a figurative beating.

If its any consolation, I don't write software. I don't plan to, either. I do work with developers, though. They're ten times the programmer I am, but despite that, even with crypto libraries and APIs galore, their end result is often abysmal. They're not bad programmers; they're phenomenal programmers. But when you ask them to establish a cryptographic threat model and properly address it, you're asking something outside of their expertise.

Cryptography, like medicine, is very much a practice; however, there's no regulation as to who can practice it. To many, it's easier than it looks, and if you couple that with the average user who can't tell good cryptography from bad cryptography, you've got yourself a case of inadvertent snake oil. Developers mean well, so it's nothing personal; they're just not aware of cryptography's subtleties. If you can see the seriousness of this, then you'll understand my concern.

I practice what I preach, though, and am excited about some upcoming work that will make cryptography more accessible and tangible to developers. In short, I'll say this: Rather than burden developers with a box full of tools and parts that they must put together on their own, it's better to provide them with off-the-shelf, self-contained modules that have all the right security decisions built in. Implementation assurance becomes a lot clearer, because we're letting programmers be just that -- programmers.

(Capp: No worries, though. I figured you were speaking generally.)

I did not contact PGP Corporation, because they're the one company I trust most, when it comes to getting cryptography right. MACs and digital signatures both preserve integrity via message authentication, but the former does it symmetrically while the latter does it asymmetrically. There are differences, of course (e.g., digital signatures do non-repudiation*, MACs don't), but for this purpose, PGP's method is kosher and in line with best practice.

* Non-repudiation is cool, until you consider that sad state of key management. "I didn't sign that. A(n) insert_bad_thing_here stole my key."