# CryptoSuite, IND-CCA2 /\ INT-CTXT security, and more.

Discussion in 'Other Ghost Security Software' started by Justin Troutman, Dec 24, 2007.

Not open for further replies.
1. ### Justin TroutmanCryptography Expert

Joined:
Dec 23, 2007
Posts:
226
Location:
North Carolina, USA / Minas Gerais, BR
In the screenshot that shows the "chat" feature of CryptoSuite, it indicates what looks good on the surface; that is, the designers have considered both confidentiality and integrity, by using message encryption and message authentication. However, I have some curiosities and worries. To begin, how is RSA used to exchange keys? Let's say our RSA public exponent, e, is 5, and our modulus, n, is 2048 bits in length. To make a short mathematical story shorter, and less mathematical, if we treat our message, m, as a 256-bit integer, no modular reduction will occur, since it's smaller than our modulus. As such, we can deduce m by computing the fifth root of the encrypted message; in this case, the message would be the 256-bit symmetric key used by a block cipher. You'll need to use a padding scheme to thwart this. It's an obvious, well-known issue that you can research with ease.

Next, we have what are shown as "TwoFish (256-bit) + Rijndael (256-bit)" and "SHA+HAVAL HMAC (256-bit)." I'm assuming that "+" indicates a cascade of some sort. First, let me make clear what should be obvious to anyone with experience in cryptographic implementation. When cryptography fails in practice, it's almost never the cryptography's fault; it's the implementation's fault. Given that, our highest priority is catering to the implementation's demands for simplicity. Whatever makes it less likely for a mistake to be made is gold. Based on this, I can't think of any rationale that would support the combination of primitives in this way. I'm curious as to the designer's thoughts when they were implementing this. I do commend them for knowing what a MAC is, though, which is a rarity in much of commercial cryptographic software. I just think it's better to use primitives in the manner for which they're designed, without adding complexities that make it harder to implement correctly.

Using code-based game-playing techniques, we have provable results that show cascades composed of at least three block ciphers, with three independent keys, to be the minimum, for a significant gain in security. Triple encryption increases security (significantly) in a way that double encryption cannot (negligibly); triple encryption is the shortest potentially "good" cascade, in this sense. Furthermore, we're not sure if security increases when you increase the number of block ciphers in a cascade beyond four. Triple encryption is the "sweet spot," if you will, but the added complexity of implementing a cascade just isn't warranted, compared to what it gives you. There's a greater probability of making an implementation mistake than a practical attack surfacing for a good block cipher. And when I say there's a greater probability, I'm talking magnitudes upon magnitudes.

I advocate the engineering principle of recycling primitives; in other words, if you can use a primitive for both encryption, authentication, and as PRF, then do so, by all means. With the AES, you can do exactly that. For example, you could encrypt with AES-CTR, then compute a tag on the ciphertext, using CMAC-AES, using separate keys for encryption and authentication. The Encrypt-then-Authenticate generic composition, or EtA, is the easiest to get right, from a security perspective, and renders IND-CCA2 /\ INT-CTXT security, given an IND-CPA secure encryption scheme (e.g., AES-CTR) and a SUF-CMA MAC (e.g., CMAC-AES). IND-CCA2 /\ INT-CTXT security is the property you usually want - especially in general-purpose symmetric authenticated encryption schemes. Here's a little diagram I threw together in LaTeX to show what the Encrypt-then-Authenticate composition looks something like, in a more algorithmic view:

To compute separate keys for encryption and authentication, you can do key separation with a PRF, like this:

E_key = PRF(shared secret, 'EtA encryption key')
A_key = PRF(shared secret, 'EtA authentication key')

(CMAC-AES is a good PRF too, which implies that it's also a good MAC.)

I suggest this as a revision to the software. By doing so, you're using a block cipher that's receiving more cryptanalysis than any other, for your encryption, MAC, and PRF schemes; this makes good sense from both cryptographic and engineering angles. It's a balanced approach that not only simplifies the implementation, but provides conservative security, which is what you want. For the record, I agree with many of the design principles behind Twofish and have no objections with its security. You couldn't really ask for a better presented or documented block cipher. The designers are topnotch. I just happen to think the AES is better.

Now that I've gotten all that out of the way, I'll ask: Does CryptoSuite use a MAC only for the chat feature? Judging by the screenshot that shows the "checksum" feature, it seems that you're only able to compute checksums and hashes on files. First, there are too many options here. I can't think of any good reason why a user would need 12 different functions for computing a checksum or hash - some of which are subject to cryptanalytical attacks or not even intended to be cryptographically secure at all. Of course, CRC-32 and Adler-32 are easy to forge; they're unsuitable for detecting malicious alterations. Furthermore, if you're worried about an adversary manipulating data, unkeyed hash functions won't help you either. Once the adversary makes his alterations, he simply recomputes the hash, which is easy, since it's not keyed.

Assuming you're using an IND-CPA secure mode of operation, such as CBC or CTR, a good block cipher will preserve the data's confidentiality, but it does nothing for its integrity; that is, an adversary can often successfully manipulate the ciphertext, since there's no detection mechanism (i.e., a MAC). Furthermore, the lack of integrity can also lead to a loss of confidentiality. So, if you want confidentiality, you want integrity too. It's almost never a good idea to omit it. When you want confidentiality, you might think, at first, that you need encryption. However, it's a lot wiser to say that if you want confidentiality, you want authentication too. Does CryptoSuite use any kind of MAC for files, or is this just part of the chat feature?

(Also, is there any publicly available documentation? I hope the software comes with it, at least! I don't have access to a Windows machine at the moment, or I'd check myself. Good documentation is just as important as good design!)

(Edit note: Figured out how to post inline images and made the appropriate changes.)

(Edit note #2: Sent a copy of this directly to Ghost Security's support.)

Last edited: Dec 24, 2007
2. ### Jason_R0Developer

Joined:
Feb 16, 2005
Posts:
1,038
Location:
Australia
Thanks for your comments Justin. I have heard of you, and seen some of your postings on other forums. You are very rough to most authors of crypto software. Most of the documentation is available from within the program itself, as it contains a custom help file which you browse.

That is for the CryptoSuite archives. It could be designed a little better now, I like what TrueCrypt have done for instance to make the data seem all random without any "header" give aways. But that is mostly a fluff feature.

Checksumming was just a way to allow people to checksum files into a variety of hashes, mostly for informational/comparison purposes.

I can understand what you are saying about using something everyone is attacking because it's the most tested thing, but on the other hand when I designed CryptoSuite I wanted something unique that I could trust personally. Of course, I use AES, but I wanted something else "just in case" Rijndael was broken (or backdoored as the conspiracies go ), which is why I also went with TwoFish. At the time cascading wasn't so popular as it appears to be now. The Australian DoD (department of defense) also visited me and requested that the free version of CryptoSuite be downgraded in security, which is what I had to do.

From my memory (which is a tad fuzzy) of the chat routine, the two hashes are generated from the shared secret, xored, and then used to verify every packet. If packet tampering is detected (or noise introduced), the client will be disconnected, it's mostly only important when exchanging the private keys though, as you would know. It is why you don't need as secure a passphrase because the ability to brute/break it within the connect time frame (to implement a MiTM) is very hard, though it's always good to have long passphrases anyhow, especially if you reuse them.

3. ### Justin TroutmanCryptography Expert

Joined:
Dec 23, 2007
Posts:
226
Location:
North Carolina, USA / Minas Gerais, BR
On the flawed "just in case" argument.

Hehe, it's true. Fortunately, most vendors I converse with understand that it's nothing personal; it's the design I'm criticism. You have the defensive ones, though, who get riled up. When it comes to cryptography, you can't beat around the bush to get anything done. Show no mercy. Adversaries don't!

Alright, but in production software, is it really wise to burden the implementation with a dozen functions for information purposes? Perhaps you could provide such a utility, separately; if it's unnecessary, I would leave it out.

Your "just in case" argument is a common misconception. Remember, the more options you have, the more complexity you have. When you make design decisions, make sure they're based on things you can quantify. For example, let's say you have two block ciphers, A and B. You're using B "just in case" A is broken. If A is broken, and the attack is published, you might feel at ease, knowing that you still have B to rely on. However, how do you know B hasn't been broken as well, and the attack hasn't been published? You don't, and there's no metric for determining this. You might as well add another block cipher, C, "just in case" B is broken too.

Where does it end? We can certainly quantify how much you're paying for this argument, though, and the return doesn't fit the cost, to say the least.

The paradigm of "not keeping all of your eggs in one basket" is a logical one, but if you look to practice as an indicator of how attack usually surface, you'll find it's unlikely that this paradigm will often be realized, if at all. That's because most attacks are certificational; in other words, they're academic, or "theoretical," without any imminent real-world applicability. Practice doesn't support the argument, nor can you even quantify the basis of the argument itself. What practice does support is minimalist design, and that includes implementing only what's necessary; in this case, a single block cipher.

Protocols have fallen apart because of cascades and multiple algorithms. The odds of this happening are a stack of magnitudes greater than the surfacing of a practical attack on the AES. As I've mentioned before, the cryptography isn't what you need to be worried about; it will be the most well-behaved of your security components. Implementations depend on things like simplicity, minimalism, modularity, et cetera. It makes things easier to build and easier to analyze. Make sure that the way you address this, cryptographically, coincides with that. Less is more. If something's going to fail, I'll bet you it'll be the implementation.

Semi-recently, there has been some intriguing research with regards to the CCA-security of multiple encryption constructions, cascades included. I recommend checking out, "Chosen-Ciphertext Security of Multiple Encryption," by Dodis and Katz, as well as "Tolerant Combiners: Resilient Cryptographic Combiners," by Herzberg. I have no doubt about the potential security and functionality that the application of multiple encryption can provide, in a variety of contexts, which echoes the importance of establishing its security beyond IND-CPA (e.g., IND-CCA).

But, not a single piece of software I've ever seen uses cascades for the reasons outlined in these papers; they use it unnecessarily. That includes TrueCrypt; cascades don't make it any better. The "just in case" argument doesn't warrant the added complexity it introduces to the implementation. My observation is that many (it should probably read "most," but I'll be optimistic here) obsess about the choice of the block cipher, when they shouldn't. There are far more important things to consider. If I see an application obsessing over block ciphers, chances are, they've overlooked something, somewhere else.

I'll leave you with a quote by Ross Anderson (co-designer of Serpent), from his book, Security Engineering:

If you're designing cryptography systems, you probably need this book.

(Oh, and on a side note, I see absolutely no sensible reason to buy into the whole conspiracy regarding backdoors in the AES; it doesn't hold any water.)

Hmm, this isn't HMAC, then. I'll comment on this in the other thread, regarding the chat feature of CryptoSuite.

4. ### Jason_R0Developer

Joined:
Feb 16, 2005
Posts:
1,038
Location:
Australia
Re: On the flawed "just in case" argument.

Indeed, it is helpful getting people inspecting what you do. I guess one issue I have though is you have shown in the past to be a bit jaded when it comes to encryption programs in general, probably due to most of them not really knowing much about what they are doing. It is one reason I spent many, many hours obsessing over the CS archive format, making sure all the unfilled parts of structs were randomized, that everything was fresh on each new encryption, and triple checking it, etc, so that if people did start looking into it there wouldn't be some design flaw. Though can you ever offer a 100% guarantee that there isn't any?

Well that's like saying that any feature in a program is burdening the main point of the program. Like what's the point of a UI when command line encryption works. I don't really see the harm in adding more hashes, since each of them are separate pieces of code, most of them written by their authors, and most of them not used in the actual encryption.

There are indeed practical limits to where you end the "just in case" line of reasoning. Whilst I certainly understand that adding more complexity increases the chances of a mistake occurring, when it comes to cascading ciphers if you can trust them to do one cipher correctly (certainly a big leap in itself), then certainly they should be able to spot a mistake in a cascade implementation.

It is an interesting balance really when it comes to implementing these systems, because you need a good coder, combined with good cryptographic knowledge. Code errors can break the system, whilst not implementing the system correctly in the cryptographic sense can also break it.

There is certainly no evidence supporting such theories so you are right that it doesn't hold any water. Though I'm always wary of something that a government organization or a lot of people in general recommend you use when it comes to encryption. I'm probably more paranoid than most though, half the reason I wanted to do my own cryptographic program.

I'm going to have to do a refresh of CS soon enough due to not supporting UNICODE in the original version so I will take what you said on board and I thank you for taking the time out to offer your criticism. With the new code I have I may even be able to release a linux version of CS without too much drama, which will be good for people like you....

5. ### Justin TroutmanCryptography Expert

Joined:
Dec 23, 2007
Posts:
226
Location:
North Carolina, USA / Minas Gerais, BR
On interfacing, warm fuzzes, threat models, and excessive options.

There's no denying that I'm less-than-optimistic about cryptographic software - open-source and closed-source both. However, I do give praise when it's due. Quoting myself from this thread:

Aside from BitLocker, PGP is an example of an entity that I trust to do cryptography right. What may seem like a demanding attitude is reasonably justified by good cryptographic engineering principles. I call out poor design, and suggest ways to improve it, and I applaud good design, and use it as an example of such suggestions. I think that's fair.

There's never a 100% guarantee. You can make things easier by minimizing the assumptions you make about the design's security. To do this, minimizing the components you use by using only what's necessary. Avoid doing things that make implementation and analysis more difficult. Again, there's no 100%, but there's some place comfortably close to it. Try to get there.

I'm not sure I agree with the UI versus command line parallel. Cryptography should be as transparent as possible and the interface should be intuitive. Consumers are more likely to use cryptography if it's not an intolerable hassle. Convenience wins every time. So, spending time on the interface makes sense. On the other hand, piling on the options doesn't really provide any useful service to the consumer, but it does a good job at cluttering the implementation.

On top of that, it can confuse the consumer as to which configuration is best. It should be secure by default. I'm not convinced that the consumer needs to worry about choosing cryptographic primitives. The software should do it for them. Overall, a good interface is necessary, but excessive options aren't. if you can kill two birds with one stone, why aimlessly throw a dozen at them? Features should fit the need they're meant to fill. Even before that, the need should really be a need.

In your case, you're saying that since the hash functions are off to the side and not part of the encryption code, they shouldn't cause any harm; they're for information purposes. My response to that is, shouldn't software only do what it's intended to do? Isn't the point for it to address a certain threat model? Should educational features be included, just because? Or, should they be provided as separate tools? I'm thinking the latter. Maybe it won't cause a problem, but then again, it doesn't do anything particularly useful for security. It does make the implementation bigger, and gives you more to analyze for correctness and security, though. Is it worth it?

Perhaps they could, but the point is not risking something that can be achieved through simpler and more minimal means. In general, it seems like many developers completely disregard the advice of cryptographers and do whatever gives them the "warm fuzzies." That has a lot to do with my lack of optimism when it comes to cryptographic offerings today.

And, it's nowhere near as easy as simply implementing cryptography correctly and securely. First, you have to thread model properly, and make sure that the cryptography you're implementing matches the threats associated to the application your building. That takes a certain kind of expertise that comes with experience. If you can't first recognize potential insecurities, you can't arrive at anything close to security.

But the things we recommend most are the things we analyze most, and analysis is how primitives and protocols "earn their bones," so to speak. This is the reason why you should use it! Paranoia is useful, but only if it's sensible!

*flashes an Apple logo* Hehe.