What Encryption softwares do you use?

Post your winrar file on http://www.mediafire.com/, then post the url to your file, then people can download it and try to break or crack it...

 

I am confused by the verb “reconstruct” in the phrase “reconstruct plaintext.” Can you please elaborate?

That appears to be sound advice!

 

Have you read the article by Yeo and Phan (and also those by Kohno) discussed in this thread? The procedures to ‘break’ an encrypted, compressed file (i.e., where ‘break’ is defined as the loss of the “preservation of integrity”) are conceptually straightforward. I recommend that you study those procedures, ‘break’ your own test file yourself, and report back the results in this thread. Deal?

 

I'm referring to the attack in Kohno's paper; see the attack on WinZip in the second paragraph of page two, under Interactions Between Compression And The AE-2 Encryption Method. Yeo and Phan discuss, essentially, the same attack on WinRAR.

Basically, Alice compresses and encrypts file.dat, which then becomes file.zip. Alice sends file.zip to Bob over some channel (e.g., e-mail). Mallory intercepts file.zip and modifies it in some way; we'll call this modified file file_mod.zip. Mallory has changed the metadata in such a way that the chosen compression method and original plaintext length are now different, which will cause Bob to end up with garbage after trying to decrypt and decompress.

Bob sends a note to Alice, complaining of the garbage. If Mallory can intercept this note, he can pretend to be Alice long enough to tell Bob, "You know, I think I've had this issue before. Can you send me the garbage so I can look into it?" Bob sends the garbage to Mallory, thinking it's Alice; with this garbage, Mallory can reconstruct the data in file.dat. That's the gist of it, anyway. While this attack assumes a particular scenario, it's one that can be found in practice.

 

Thank you. That's very clear. With a proper implementation, the modified file would yield nothing, right? So there'd be nothing for an attacker to work with, except for "it didn't work".

 

With a proper implementation, the metadata would be authenticated, such that any manipulation by Mallory would be detected. So, the modification can still take place, but Alice and Bob will gain awareness of it. This can be achieved with the use of a MAC, using a shared key just as they would for encryption.

 

These papers "Attacks on winzip/winrar" are outdated, can anyone find anything up to date? I have searched everywhere with no luck, I think the authors have fixed these known issues.

Justin Troutman I know I have asked you which Encryption software you prefer back in March of 2009, and you said you experiment with PGP and sometimes GnuPG, my question is has your preference changed sense then?
........................................................................................................

I knew I was missing something, WinRar uses AES with a key of 128 bits. Not 256 bits have a look here for proof.
........................................................................................................

I think AxCrypt is more beneficial than winrar to users who want to encrypt private data due to its integrity, and its free, I also like the fact you can use both a password and a keyfile.

Does Winrar have any of these features that AxCrypt has?

• Dynamic brute force counter measure - iterative key wrapping.
• Secure memory handling - no keys or data in the paging file.
• Data integrity verification - no undetected modification.
• Unique data encryption keys used for every file and (re-)encryption.
• Integrated shredder.

The complete list is here
.........................................................................................

Winrar is $29 bucks
But I do give respect to winrar in the fact that I have seen cases on forensic forums where the Investigators could not crack a winrar file.

But in the end it is up to the user of winrar to properly use the features in winrar like Create a solid archive, Encrypt File Names, and use a strong password to secure his file. because if he doesn't than why even bother?

 

Justin, the attack in Kohno’s paper was based on version 9.0 of WinZip. In looking into this issue further, I found the following information, suggesting that recent versions (11.0 and later) of WinZip may be (?) immune to the attacks discussed in this thread:

When you have a moment, can you kindly review the information about the current state of WinZip encryption found here and assess if the attacks described by Kohno or by Yeo & Phan are still possible with recent versions of WinZip? (Thank you.)

 

I believe we should not lose sight of the fact that the primary function of WinZip/WinRAR is file compression, with the addition of encryption as an ancillary component.

 

To verify my own understanding of the attack, this is essentially a ‘social engineering’ threat. In particular, Bob has been tricked into actually decrypting the contents of File.zip -- which only appear as ‘garbage.’ Correct?

 

Thanks for pointing that out, I think we all have lost sight of the original topic What Encryption softwares do you use?

I was basically pointing out the advantages an "Encryption software" has over "Compression software with built in encryption"

 

And, it's been informative.

I use GnuPG for files, email and signing; TrueCrypt for containers, partitions and Windows disks; crypto-LVM for Ubuntu partitioning; SSL/TLS for email transport; and OpenVPN for networking (plus standard browser security).

 

Actually, upon further consideration, I withdraw the question. The error in my reasoning, I believe, is that the central directory (i.e., the metadata) of the archive is unencrypted and not authenticated – and, that fact is the root problem underlying the attacks described by Kohno and by Yeo & Phan. Thus, even if an encrypted file within an archive is authenticated, the basic problem has remained unaltered.

 

I use DiskCryptor for windows partitions.

 

I still use PGP products, as well as GnuPG. When it comes to cryptographic products, I care most about the reputation of those behind the implementation; anyone can get ahold of standard cryptographic libraries and such, but not everyone can properly deploy them. Call it a liability thing, even. I have no reason not to go with the grain; it makes the most sense to me.

Well, I'd still call this an implementation flaw, because Mallory is exploiting the lack of authentication. Bob might even send the garbage to Alice anyhow, which Mallory could intercept without the need for impersonating Alice. However, if we assume that Mallory must ask Bob for the garbage, by impersonating Alice, then I suppose you could say some social engineering is involved; on the other hand, Mallory is lucky because Bob can't see who he's communicating with, so there's not much skill involved, in that regard.

To clarify, Mallory twiddles the metadata (e.g., compression method and original file length), such that decryption and compression produce nonsensical garbage; Mallory needs this garbage in order to reconstruct the original plaintext. Maybe Mallory pretends to be Alice and asks Bob for it [the garbage]. Maybe Bob plans on sending the garbage to Alice anyhow, and Mallory simply grabs it while it's being communicated between Bob and Alice. The attack works because of a lack of authentication; slight social engineering may or may not be needed to mount the attack.

Regarding the text you provided from WinZip's site, regarding the encryption and authentication procedures, it seems they have a good understanding of how things should work, and I'd guess that Kohno's work had a lot to do with that.

 

Yes, I agree.

The lack of authentication, however, may ultimately be due to WinZip’s conscious decision to adhere to the industry-standard Zip file format, even though the company is obviously aware of the consequences of that choice. I can see and can appreciate both sides of the argument. On the one hand, the primary purpose of WinZip is file compression and thus being compliant with the industry standard is important; on the other hand, the product provides secure encryption but lacks the authentication that would prevent the attacks described Kohno and by Yeo & Phan from succeeding.

Unfortunately, it appears that WinZip is promoting the use of its product for the transmission of files through email (see WinZip Courier). This is regrettable, given that the product provides prevents “unauthorized access” to the files in a Zip archive but does not protect their integrity.

 

Of course, if you have a product that maintains compliance, but also has issues that, if fixed, will break compliance, the real fix needs to take place within the industry standard with which it, the product, is compliant. Of course, this gets tricky with products whose focus is not cryptographic security, which gets lost in a sea of other features; if you're going to do cryptography, you've got to do it right, or not at all. Otherwise, you might find users taking bigger risks based on a flimsy sense of buzz-word induced security; this is in general, though, and not aimed at WinZip or WinRAR.

I've used WinZip and WinRAR many times, and appreciate them for what they do best: compress. They incorporate cryptography, but they're not cryptographic applications, so I don't expect them to get this part right; as such, I can benefit from them without risk. Of course, I hope they get it right, because they do incorporate cryptography, and you're going to have some users who put a lot of stock in their cryptographic features. I likely represent a minority of users who take them [cryptographic features] less seriously and use other means of security.

There's also the other group who ignores the cryptographic features as well, but either because they don't know or they don't care. It's the group that does know and does care, that you have to consider. They're going to assume that the cryptographic features in place are sufficient in order to "be secure," and more often than not, have absolutely no clue as to whether or not the cryptography in place can fulfil their expectations. On top of that, developers often don't know much more than the user, which really puts a kink in things.

I haven't looked at WinZip Courier before, but if you're communicating without authentication, then you might as well just strip the product of the rest of its cryptographic overhead. It can be that bad.

 

Speaking of GnuPG, are the people behind it competent in the field of cryptography or are they just a bunch of developers? I believe one of the main people behind it is Werner Koch. I've also heard some people on sci.crypt say that the code is sort of sloppily written. What's your take?

 

ashampoo magical security - AES 256 bits

 

I only know of Werner Koch, and perhaps a few other contributors whose names I can't recall at the moment. The primary reason I use GnuPG, on occasion (e.g., *nix systems), is that it attempts to follow the OpenPGP specification, which is a pretty safe thing to do. To be honest, I can't say much about its code, or the majority of those behind it. I'm migrating over to a strictly Windows environment, so I suspect I'll be using PGP products exclusively from here forward.

 

I'm looking at using Instant Crypt or AxCrypt. Does anyone feel that one is more secure than the other or have a preference?

AxCrypt http://www.axantum.com/AxCrypt/Default.html
Instant Crypt http://www.instantcrypt.com/index.php

 

I've had conversations with Svante Seleborg, the author of AxCrypt, and while I can't personally vouch for its implementation, it has the best shot at achieving IND-CCA2 /\ INT-CTXT security that I've seen yet, in open-source cryptographic software; at least, it uses standards in the encrypt-then-authenticate composition, and if you're going to get that level of security, that's how you'd go about it. Of course, there's a lot more to it, but it's on the right track.

I'm not very familiar with InstantCrypt, but it seems to attempt simplifying OpenPGP-based e-mail encryption; this is a pretty hefty task, but a worthwhile one, in general. While I doubt I'll use it, I'll look into it.

 

I just tested InstantCrypt and I think it might be brilliant to introduce newcomers to email encryption, at least. It is very user friendly. I could talk a client through InstantCrypt in a very short period of time, I think. I'm going to play with it some more, but so far I love it for ease of use.

 

Well, I was going to read up on IND-CCA2 security since Justin brought it up, so my search brought up Justin himself, here:

http://www.computer.org/portal/web/csdl/doi/10.1109/MSP.2008.99

but IEEE's not getting my 19 bucks today . Not that it isn't worth it, of course, but maybe since Justin's right here (and his article probably pretty intensive), he could expand on his thought about encrypt-then-authenticate composition in this regard.

 

+1

Justin, what do you say about DiskCryptor?