cwCrypto Beta Testing

We are now releasing our newest program, cwCrypto, for public Beta Testing.

cwCrypto is a simple text encryption program that allows you to choose from 5 different encryption methods, choose how many times you want it encrypted, your encryption key and converts it to hex so that the text can be copied and pasted to another copy of the program for decryption.

Use it to secure your messages before sending them via email, or saving them to a text file.
Only you will have access to decrypt the message, or anyone you give your methods of encryption to.

Please post any questions, comments, suggestions or bugs to our support forum and we will respond accordingly.

Thank You


Name: cwCrypto
version: 1.0 Beta
Date: 04/28/2010
Site: http://capp-ware.com/cwcrypto
Support: http://forums.capp-ware.com

 

As we realize that trust is earned with software, not just given, we want to provide the additional information about the software for peace of mind.
All of Capp-Ware Solutions software is spyware/trojan/malware free.

Below is the file information:

File size: 589824 bytes
Filetype: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
MD5: 206b91eea87daf46fb0f492b0f70e6a7
SHA1: a24992492ec4d556a9f026f405580623d9d5c1ac


~ Jotti's Results Removed per Policy ~ (permalinked)


Thank You

 

cwCrypto doesn't do any encryption of files themselves, but instead, allows you to create encrypted messages.
More designed for transferring encrypted data back and forth between users.

So, instead of typing up a long message, saving it to a file, encrypting/compressing the file, attaching it and sending it, then go through the reverse at the other end....Just type the message within the program, encrypt it and send it as is.

Also, cwCrypto is easy enough to use for novice computer users.

 

I don't see any advantage over using Thunderbird+Enigmail...

 

The advantage is, the person on the other end doesn't have to be using Thunderbird + Enigmail too. So, 1 user could create an encrypted message and send it through outlook express, if they choose, and the receiving user doesn't have to even have an email client to decrypt it.

And once again, user friendliness is a plus. so, it can be used by novice users too.

 

Hi Capp,

Several things...


* I'm curious what is happening when you select the, "number of passes." Does selecting DES with 3 passes literally give you 3DES? I'm asking an interpretation question about the use of your term "pass."

* Doesn't the recipient of the message need to have a copy of the software on their computer?

* Give me a sales pitch on why I would use this as opposed to, say, AxCrypt, which makes self-encrypting files and the person receiving the file requires no other software.

* To decrypt the message, am I right that the recipient needs to know:
1. What algorithm is being used
2. The number of "passes."
3. The password
If the above is correct, why the need to know the other two pieces of information other than the password? If I know the password, there are only 25 other combinations of algorithm and passes (5 of each). So, what purpose does it serve requiring the algorithm and number of passes? If I have the password and the software required, then the "brute force" required to get the other needed pieces of information would take maybe 3 or 4 minutes. That confuses me.

I have other questions, but those are good starters.

 

Thank you for your inquiry. I'll happily answer your questions the best I can.
I'll just order then numerically for simplicity.

1) The "number of passes" is how many times you want the program to encrypt the text. 3 passes of DES does not make it 3DES. What it does do is, takes your text, encrypts it once, then encrypts the already encrypted text again, and then does it one more time. So the last two encryption passes, are actually further encrypting the already encrypted text. That makes it even hard to break, since you are encrypted "gibberish" for the most part after the first pass.

2) Yes, the recipient would need a copy of the software to decrypt it as well. But since it is a stand-alone app specifically for encrypting text, instead of plug-ins designed for mail clients or browsers, the user doesn't have to change their way to doing day-to-day tasks to be able to use it. And, the user could install it on a USB drive to take with them if they choose. And, if you are using XP Sp2 or higher, you technically don't even need to run the installer, just copy the .exe to wherever you want it. The installer is just designed to make sure the user can run the rich text field within the program. After Sp2, it is included with the OS, so you can just use the program as is, no installation required.

Going with the example in a previous post...If I use Thunderbird+Enigmail to encrypt the message, the user on the other end would too. Well, if they don't like thunderbird or prefer another mail app, they don't have to install something they won't use.

3) The big difference is, cwCrypto does not encrypt files, but text itself. Also, cwCrypto does not hook itself within the shell, so you can install it on a thumbdrive and take it with you and encrypt message on the go. This also eliminates having to send attachments as you can send your encrypted message as "plain-text" emails. Helps reduce the size of the email being sent too.

4) That is correct in that the end-user will need those 3 pieces of information. But, it is not that simple. Knowing the key won't allow you to just brute force it. Since you can choose whatever and however many methods you want to encrypt it with, you can use multiple methods, keys, etc..

So, for example, if I did this:

• Encrypted my message 4 times with BlowFish and the key of "password".
• Then, encrypted it twice with DES and the same key.
• Then, encrypted it again 3 times with TwoFish and the key of "testing".

You would have to know the exact steps took to encrypt it, and then do it backwards to decrypt it. Doing a brute force wouldn't work then as it would just scramble the text if you didn't do it just right.

Yes, you can do an easy encryption and just do 1 pass with blowfish with a simple key and it will be sufficient, but if you want to make it really complex and nearly impossible to break, use different keys and different methods.

For testing purposes, I encrypted the text from my resume 25 times with blowfish and a 15 digit key, then another 3 times a piece with each other encryption method and a different key on each one. I don't see that one being cracked.
It was just for testing purposes of course, but if it was an important bit of information, that would make sure it would stay a secret.

Once of the biggest selling points I can tell you is, it is very user friendly. Novice users can easily pick it up and start using it without much trying. As a computer consultant, I can honestly say the majority of our clients are novice users and asking them to try and use some of the tools listed in a post above, you would get a lot of blank stares. For tech-savvy people, yes those are great, but for the rest of the population, easy to use and minimal setup requirements are a plus.
On a personal level, there isn't a person in my family that would be able to use any of those tools listed above.

I hope that answers your questions and thank you for taking the time to ask them. We appreciate constructive feedback and questions.

 

From my understanding of cryptography, in order to decrypt some encrypted data there are the following situations:
1) The algorithm you use is weak. In this case using it has no meaning, because it will be quickly defeated. So instead of using a weak algorithm and then a strong one, you could safely use just the strong one.
2) The password you use is not strong enough. This situation leads to the possibility of successfully using a brute force approach. In this case, why not use a single encryption algorithm and a longer passphrase? The result is the same as multiple encryption runs, but the implementation is safer (because of the reduction in complexity).
3) Bad implementation. In this case, it doesn't matter how many times you encrypt the data, the result is the same...

 

The 5 different algorithms available in cwCrypto are 5 of the best algorithms available to the public. You are given a choice as to which algorithm you want to use and what passphrase, or key, you want to encrypt the text with.

Everything you listed above is user choice. If the user decides to use the least effective methods for encrypting their text and a short, easy to guess passphrase, then it doesn't matter what tool they use to encrypt their messages, they will be easier to break.

Each encryption method is implemented according to the guidelines of their creators. When you encrypt a string with a key, that is the key used to decrypt it. The only key.
It works the same way with every encryption program out there. You set the key, or passphrase, and that key is the only thing that unlocks it.

 

i try it and it doesnt work

using win 7 X64...

 

Hmm...do you get a specific error or run-time message?
We had several closed beta testers on Win7 and didn't run into any problems.

@snowdrift. Thanks for sharing. Not related to our program.

 

Anything that makes it easier for the common man to access security is a great thing. I haven't tested, but I will. To most people, just using Thunderbird plus Enigmail is a challenge. Not to mention getting the receiver set up, esp. if that person is a client with no experience. The more truly secure, user-friendly alternatives, the better. Despite many years on the scene, encryption is still a mystery to most. People crave a hushmail experience for messaging, but the web-based server drawbacks...not so much.
And to a novice, GnuPG gives the feeling that people look like they get in old movies when they have to pick which wire to diffuse the system. It's an " I don't think so" experience, still.
We have a lot of options for encyrption, but none are esp. both cost effective (free?) and (the key) user-friendly to two standard-use parties who wish to message or share from a desktop without hassle.

 

What does this have to do with our software?
Please stop posting non-related things in our thread. If you have questions about our software, or suggestions to make it better, we would love to hear them. But posting multiple products that are not related to ours with no explanation and then links to a comic strip character, have no bearing on our software products.
If you have a comment you would like to make to us that do not involve cwCrypto, please PM us.

Thank You

 

Something else you have to keep in mind is, there are A LOT of people that are just now getting into computers. Navigating Windows is enough of a challenge for them. I know because a lot of our clients are like that. So, having something very user friendly that uses terminology they understand is not a bad thing.
As mentioned above, there are quite a few people in my family alone past retirement age that just got their first computers in the last couple of years.

 

the problem is simple , after i encrypt my msg i cant decrypt it , it gave error for wrong key twice... and my hex number became something else that cant be read .

 

Ok, so the program actually runs without problem. There just seems to be an issue with functionality. Alright lets see.

Walk me through step by step what you did.
I just tested it again and didn't get an error unless I changed the key.

 

I'm interested, but I don't want to install the demo yet. I do have a few comments and questions:

From a usability standpoint I don't think it's a good idea to require users to know the exact order of decryption (algorithms, number of passes plus their passwords), although I think I understand why you're doing it that way. It seems to me that this approach will tend to add complexity a lot more quickly than it adds security, and it's sure to cause many users to lose access to their data. Have you "done the math" on this approach to confirm that it offers worthwhile advantages over using a single algorithm and a fixed number of passes along with a stronger password?

I can easily imagine how the added complexity of your method will cause significant amounts of encrypted data to be lost, and eventually you (or somebody else) will have to provide a brute-forcer that tests all reasonable combinations of algorithms and numbers of passes against the known password(s) so that various users can recover their data. I suppose the brute-forcer will have to apply randomness testing or text recognition in order to tease out the decrypted message, since from the sound of it I don't think you're attaching any identifiable fixed data to the message that could be used for this purpose. You're just encrypting the plain text directly, right? No salt, no headers?

How do you envision that each user will remember the correct combination of algorithms, passes and passwords? In their head, along with the password? Written after the password in code, like a combination lock? (eg: "GreenCheese 2D 3B 4T" or "SuperSecret 4B 1D BlackCat 15T"?) I imagine that each user will want to settle on a particular combination and then stick with it, otherwise there will be a hopeless jumble when the time comes to decrypt a particular message.

Also, what level of security are you hoping to provide with this product?

I'm sorry if it seems like I'm grilling you. I appreciate that you've gone to the effort and you're choosing to make this product available, and I'm always willing to look at (and sometimes poke at) new ideas. However, since you're offering a new data-encryption product you might as well prepare yourself for even more grilling from far better-qualified people than myself.

 

This all comes down to user preference. We all know that there are a lot of people that use simple passwords and use the same one for everything. If they choose to do so, they can just use the same password and leave the methods and passes at default. So, they will still get good protection with BlowFish encryption a single time.
And, the more advanced users that like to make things complex, can do so as well.
You are not required to use more than 1 option or even more than 1 pass. It is just there if you choose to use it.
We haven't done a market analysis of what would be better, but that is why we are offering the user to make that choice themselves. If they feel secured with a single pass of encryption, then so be it.

There is always the possibility of data loss this way. If a user encrypts a message, then copies and pastes it but forgets a character, it won't decrypt properly. But accounting for user error in all facets of usability is quite impossible.
Part of our disclaimer and terms of use is that we, Capp-Ware Solutions, maintain no responsibility for data created in, or copied to/from the program. So, if a user does encrypt some information and then forgets how to decrypt it, there is no brute-force unlocker going to be created for that purpose.
Yes it happens. Happened to me once. I password protected a document and encrypted it several years ago and have no idea how to unlock it. lol.

But, to answer the other part of the question, No...no information, headers, salt or anything at all is added to the message. So, the encrypted string is 100% only the users message.

That is what we hope happens as well.
During the closed Beta testing, we had a number of users we would communicate back and forth with through the program. We would agree on a particular method, passes and key ahead of time and use the same one each time. At one point, all communications had to be decrypted, replied to, encrypted and then sent, for testing purposes. Some of the conversations were rather lengthy and we even filled the text with random ascii characters and symbols to test it.
So, we are hoping that userA and userB decide on a routine and keep using it.

I'm not sure what you mean? sorry.

No worries at all. We expect this anytime we release a new software title and we welcome the questions. That is a big part of the Beta.

 

That is a classical issue and a critical point of weakness in the strength of the privacy provided by the encryption: namely, the secure exchange of the password between users over a non-secure communication channel. Does cwCrypto attempt to address this concern in any way?

 

I understand what you mean and it is a weakness for sure, but I am not aware of a single program that has a better alternative to handling this. It is not a weakness within the cwCrypto program, but a weakness in the act itself.

Obviously, however the user chooses to pass on the protection credentials is their choice. We handled it via phone or separate email.
If you have any suggestions as to how we could incorporate this into the program itself, we are open to ideas

 

The exchange of public keys between the two users (i.e., the use of public/private key pairs) is an approach that has been used for data-in-motion (e.g., see PGP Desktop).

 

Something similar to that might work on a LAN setup, but for the majority of users, information will be passed via email.
So, by creating a private key for both parties, the key would still need to be sent to the other person as well. And so repeats the process of how to securely get your key information to the other user.

 

No, each user creates his or her own public/private key pair, the public half of which is freely available (e.g., stored on the PGP Global Directory) and is used for encryption only. The private half, retained by the creator, is used for decryption. In this way, the problem is mitigated.

 

Ok, going with that. How would UserA let UserB get the correct key to decrypt it?