What Encryption softwares do you use?

"What Encryption software's do you use?" +1 for AxCrypt, LockNote, and others listed in this thread.

Nobody here can crack your winrar file Period! yes I agree, the only way their going to crack it is if you used a weak password, you already indicated in other threads your password is not weak, so NO nobody is going to try to crack your winrar password, Yes I agree no proof in these so called attacks against WinRar files at least I cant find any, but nobody knows what they may have in the future? you already know they cant crack it now so why sit and ask the same question over and over again? my advice is to move on and learn about something else, because your wasting your time unless winrar is paying you $$$ to sit on wilders and ask the same question over and over again.

But if someones password is stored somewhere on their HD? this is usually someones weakest link im not saying your pass is stored on your drive, im just giving an example so please don't take it the wrong way.

Source:http://www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=5791&highlight=winrar

 

I think there's a huge disconnect in the actual understanding of what constitutes an "attack," and the circumstances that must arise in order for these attacks to be mounted. Tragically, it seems that some are fixated on using AES-256 with a good password, while these attacks have absolutely nothing to do with that, at all. As I suspected in one of my previous posts, this represents a lack of comprehension when it comes to the difference between cryptographic algorithms and cryptographic products, and the reality that a strong former doesn't guarantee a strong latter.

For instance, one attack on WinRAR works against a communication channel between Alice and Bob, and exploits the fact you can manipulate the compression function without causing any effect in the encryption function; this non-integrated, independent interaction between compression and encryption makes way for undetected manipulation, because of a lack of authentication to preserve integrity in the face of an active adversary. This is an active, online, chosen-protocol attack that allows plaintext to be recovered. Does it work in a passive, offline scenario like yours? No.

As for the AES, I know a significant bit about it, since it's the cornerstone of my work with one of its co-designers; in no way are these attacks related to the AES, and if that's the cause of raised defenses, please, feel free to relax. And, while relaxing, please take the opportunity to read more into these attacks, because they're by academics who know a thing or two about cryptography and the products that incorporate it. You might be surprised to find that you're challenging challengers who don't exist. Here's a question: Where is your opposition placed, in regards to these attacks?

What to take from this: Are there scenarios in which one can recover plaintext from supposedly-secure WinZip and WinRAR archives? Absolutely. Are we saying that your scenario is one of them? No, we're not.

 

Thank you for your honest post.

 

Based upon my own casual reading of the academic articles “Attacking and Repairing the WinZip Encryption Scheme” by Kohno and “On the security of the WinRAR encryption feature” by Yeo, I agree with the observation that the integrity and strength of AES component of WinZip encryption is not in question. Technical issues in WinZip encryption (e.g., version 9.0) were addressed years ago, and are no longer relevant. For example, Yeo describes "the underlying encryption core (which is AES)" of WinZip/WinRAR as "a secure scheme."

I see no method described in the work by Kohno or by Yeo suggesting that an adversary could directly “recover plaintext from supposedly-secure WinZip and WinRAR archives” when using recent versions of those products. Am I missing something?

Due to the fact that the industry-standard Zip file format does not encrypt a file’s metadata (e.g., file name), it is possible for an adversary to add or replace files in an archive, or to use ‘social engineering’ or ‘man-in-the-middle’ techniques to facilitate a deception. These cases, however, are not at all the same as directly gaining plaintext visibility to an encrypted file, a weakness that does not exist with recent versions of WinZip, to the best of my knowledge -- correct?

 

Right. As I mentioned earlier, I wasn't sure as to whether or not these issues were corrected in recent versions and referred to past, affected versions. So, if you're using a newer version, you might be fine; the point I was trying to make is that even if you are using an older version, you might be fine too, assuming you're not using it in the scenario on which those attacks were based.

Albeit a different problem, metadata can indeed leak information, and it's tempting to encrypt and authenticate it to minimize this leakage. While this isn't the same as directly leaking plaintext, it could very well provide an adversary with useful information about that plaintext. You've got to be careful with metadata; it can be a forensic jackpot.

 

It's always about implementation, not the algorithms themselves.

 

Thanks, Justin, for your note.

Concerning the metadata issue, a simple technique to circumvent the problem is to add your plaintext file(s) into a Zip archive, and then add and encrypt that archive into another (i.e., a plaintext archive within an encrypted archive). To the best of my knowledge, an adversary would have visibility to the metadata of the inner archive but not to the files contained within that inner archive. Of course, this step places an additional burden and responsibility on the user.

 

Although in general I agree with the gist of the comment, these attacks on WinZip/WinRAR appear to rely upon ‘social engineering’ or ‘man-in-the-middle’ techniques that are, strictly speaking, unrelated to how those utilities implement the confidentiality of your content through encryption. In other words, the core of the problem in this case is not about the implementation of the algorithms, but seems to be more about the larger ‘ecosystem’ of how those utilities might be used in some very unique circumstances.

 

Actually, I would say that this is an implementation issue, because one of the attacks works due to the failure to authenticate (i.e., preserve the integrity of) the compression method and original file length; despite the presence of encryption, the lack of authentication allows this data to be manipulated without detection. Not encrypting and authenticating is an implementation problem; the Alice-and-Bob communication model, in which this attack exists, specifically exploits this implementation problem. While Mallory is a man-in-the-middle type of adversary, he doesn't have to do any social engineering; rather, he just takes advantage of an implementation that's insufficient for the threat model.

 

Yes, it is true that WinZip does not support digest authentication to ensure integrity of the archive. This is a problem, I believe, for any such utility that adheres to the industry-standard Zip file format. It may be a reflection of my own personal interpretation of what is intended by the phrase “implementation issue,” but intentional conformity to the industry-standard Zip file format doesn’t seem to qualify for this criticism, since support for that specification is a central design criterion for the primary purpose of the product (i.e., compression).

As I view the situation, the ‘attacks’ on WinZip/WinRAR are directed to (1) the issue of the whether the archive itself is secure rather than to (2) the issue of whether files within the archive are secure. Clearly, the archive itself (whether its contents are encrypted or unencrypted) is not secure, because a user can easily add/remove/replace files in the archive whether a passphrase is known or not. Again, I personally don’t see this as an “implementation issue,” but a purposeful design specification of the product’s intended functionality. Most importantly, however, there has been no demonstration showing that encrypted files within an archive are unsecure, to the best of my knowledge, in the sense that an adversary can gain visibility to the plaintext contents of an encrypted file. I fear that a casual reader of this thread might be misled into thinking otherwise.

 

Fair enough, but then I could pass the blame to the Zip format for failing to throw the right cryptography at the right threat model, which, in turn, is passed down to products like WinZip. Even if we don't fault WinZip for implementing a well-known format, it still inherits the problems with that format, just the same.

We know from these attacks on past versions that the lack of integrity can lead to a lack of confidentiality. In other words, because compression and encryption were separate, and manipulating the former could be done without disrupting the latter, an adversary could negate the effect of encryption. It's often worse to lose integrity than it is to lose confidentiality. (An example: What's worse? An adversary knowing that Alice owes Bob 50 bucks? Or, an adversary being able to change that 50 bucks to 50 grand?)

And, it's not enough to just authenticate, either; at least in the case of the version of WinZip that Kohno analyzed, manipulating the metadata wouldn't invalidate the MAC tag. Unfortunately, the casual partaker of cryptography often expects encryption to provide integrity, so they may very well see an integrity problem as an encryption problem. Authentication doesn't get the face time that encryption does, even though it's much more important in some cases; obviously, that needs to change!

On a side note, just to be clear, I do not know of any demonstration that is able to extract plaintext from an encrypted file within a compressed archive; then again, that's not what these attacks were about. They exploited the lack of being able to detect the manipulation, which, in a particular communication model between Alice and Bob, could be turned into an attack that gets around encryption. The point being, this isn't about preying on the presence of encryption, but rather, the lack of authentication.

 

I believe that the only threat against which the WinZip/WinRAR encryption was intended to protect is one in which an adversary seeks to gain plaintext visibility to the encrypted contents of a file within an archive. Perhaps one could argue that the scope of their threat model is too limited, but in fairness to those products, they do succeed in achieving their intended objective. For some users under some conditions, that objective may be too narrowly construed, however.

By the way, do you know if the 7z file format has the same limitations as the Zip format?

I certainly do agree!

Yes, it is a key point that all of the ‘attacks’ on WinZip/WinRAR are within the framework of Alice and Bob exchanging an archive, with the mischievous Mallory in the middle. In other words, a casual reader of this thread may fail to notice that the attacks documented by Kohno and Yeo appear not to be applicable to scenarios in which the objective is to secure data-at-rest, as might be the case when using WinZip/WinRAR to create an encrypted archive for file backup purposes on local storage. For data-in-transit scenarios, alternative products such as SecureZIP or PGP ZIP may be a better choice, since both ensure data integrity through digital signatures, to the best of my knowledge.

P.S.: Thanks for participating in these conversations, Justin. I always learn from (and become a bit smarter through) the discussions.

 

How about "data-in-use"? Every time you unzip a compressed file, whether it's encrypted or not, the file's entire contents are written as plaintext to a temp folder so the user can view/edit the data. Although the temp data is normally deleted or even wiped after the file is closed, this is by no means a sure thing. For example, if you experience an OS crash while the file is open then you've just dumped sensitive plaintext into your drive's freespace.

In other words, TheMozart has more to worry about than whether or not somebody on this forum with a bb-gun can crack his supposedly bulletproof password.

 

I agree with this concern. My answer is Full/Whole Drive Encryption.

 

Ditto. Ubuntu Lucid with crypto-LVM for host, running VirtualBox, and Ubuntu Lucid with encrypted home for private VMs.

Edit: You don't want to do encrypted-home on the host, BTW -- that may not play well with crypto-LVM. Just sayin'.

 

Not sure what PGP Zip or SecureZIP are, but for data in transit (a la email) just use regular PGP or GnuPG. They are made for this sort of thing (encryption and authentication/signing).

 

Yes, I agree -- that is very much a concern (but it is not in the domain of the discussion about the ‘attacks’ identified by Kohno and by Yeo, which was the focus of my comments).

 

Yes, I agree -- I cited SecureZIP and PGP Zip because of their functional similarity to WinZip/WinRAR, in the context of the discussion about the ‘attacks’ identified by Kohno and by Yeo.

 

I'm not sure about now, since I haven't seen any recent analyses, but given this same intended objective, they would have failed in regards to the attacks by Kohno, and Yeo and Phan, due to a lack of authentication leading to a loss of confidentiality.

Furthermore, if their objective is the preservation of confidentiality via encryption, then they should be equally concerned with the preservation of integrity via authentication; that is, if you're encrypting, then you need to be authenticating to. That's a good rule-of-thumb.

I haven't looked into this, so I can't say with any certainty. I'll see what I come up with, though.

Unfortunately, folks often send each other .zip or .rar files, thus making the data-in-transit problem very realistic. All in all, it's not easy for a non-cryptographic product to get cryptography right; it's usually better not to expect too much, because of it. This isn't a criticism of what these compression applications do well, but rather, an observation on the subtleties of incorporating things the developers might not fully understand how to do.

Of course. Dialogue is what it's all about. I do enjoy it, and get a lot from it. Thank you, as well.

 

That is a reasonable criticism. However, to be ‘fair & balanced,’ it should be noted that WinZip (to the best of my recollection) has never claimed to be a complete encryption solution. Specifically, the product fully discloses its limitations...

• “Encryption applies only to the contents of files stored within a Zip file. Information about an encrypted file, such as its name, date, size, attributes, CRC, and compression ratio, is stored in unencrypted form in the Zip file's directory and can be viewed, without a password, by anyone who has access to the Zip file.
• “WinZip's encryption method is not the same thing as an authentication method for the Zip file. WinZip encryption is intended to prevent someone who doesn't know the correct password from finding out the contents of your encrypted data. The password is not needed for actions that do not involve decryption of the encrypted contents of data stored within a Zip file. In particular, encrypted files can be deleted from a Zip file, or can be renamed within a Zip file, and new, unencrypted, files can be added to a Zip file, without a password.”

In fact, when adding a file to an archive using encryption, WinZip displays a pop-up window stating: “You should be aware of the advantages and disadvantages of the various encryption methods before using this feature. Please click on Help for more information, particularly if this is the first time you are using encryption.”

The objective of the utility’s encryption feature is clearly stated: “to protect sensitive documents contained in your archives from unauthorized viewing.” It appears that the objective has been achieved, since the attacks identified by Kohno or by Yeo fail to allow an adversary to view a protected document.

I suspect that you are correct. However, is the fault with WinZip -- or, does it reside with the user? If the product has never advertised itself as a complete encryption solution and has clearly disclosed its limitations and yet individuals use it inappropriately, then wherein is the problem?

Is the solution to dismiss any application that provides encryption without also providing integrity through digital signatures?

 

None of those "attacks" can break or crack my Winrar encrypted file. Surprise surprise lol

 

Crack, no; but break, possibly. As Justin has explained, the “preservation of integrity” of your WinRAR encrypted file may be in question when sent from you to a recipient.

 

Yeah, but compression is not really an issue at all since PGP/GnuPG do compression anyway. I think every message is automatically compressed (a good practice when encrypting something). For instance, when I run "gpg --version" I get the following output:

Code:

Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
[B]Compression: Uncompressed, ZIP, ZLIB, BZIP2[/B]

As you can see, it offers 3 compression algorithms, as well as the option to leave it uncompressed (which is not the default).

 

It's great to see that they're transparent about the cryptographic limitations of the product; that's commendable and shows a solid understanding of what they're working with.

With the attacks by Kohno, and Yeo and Phan, it was possible to exploit the lack of authentication in order to ignore the encryption. Furthermore, it was possible for an adversary to reconstruct plaintext not because they broke the encryption -- but because they simply went around it.

That might be a rather important difference to note -- that being, losing confidentiality doesn't necessarily meaning breaking encryption; it could be the case that the lack of authentication gives the adversary enough manipulative power to tweak things in such a way that encryption is negated.

The objective might have been achieved in that the encryption part didn't fail, but it was not achieved in that the lack of authentication did fail, and it did so in a practical communication model. If we assume that adversary is confined to attacking the presence of encryption, then yes: objective achieved. But, that's asking for trouble.

Generally speaking, the tragic part about this is that we can't expect either the developer or the user to understand cryptographic design and deployment. Based on their cursory knowledge, they both feel that the "product" -- in general -- is secure. That's the problem. Education is a big help, but only goes so far. In this case, the developer has stated the limitations, but many users won't read, understand, or consider them; the developer is certainly making a step in the right direction, however. But, you're going to have these kinds of issues in an unregulated arena where anyone can write cryptographic code for anyone to use.

If the cryptography just isn't up to snuff, then yes, I would dismiss the application -- but only cryptographically. I might still use the application for the actual service it's meant to provide, but not necessarily expect it to secure that service.

As such, I might use a dedicated security application to protect the product of that service. In this case, I might use a PGP product to securely communicate a compressed archive file to someone else. I generally shy away from "built-in" crypto-features.

Note: When I say "authentication," I'm referring to MACs (Message Authentication Codes) instead of digital signatures; essentially, they achieve a lot of the same goals, MACs being symmetric and digital signatures being asymmetric.

To be frank, though, with endpoints as loose as they are, a good password and a cryptographic standard are irrelevant; there are almost always easier ways to get at data than through cryptography. As far as I can see, attacking cryptography is the last resort for an adversary.

 

I will send you an encrypted Winrar file. Then you can break it and show me how it's done. Deal?