Serpent cipher

I'm new to encryption, I use Keepass for my passwords, AxCrypt for single file or folder encryption, Steganos LockNote for confidential notes. I'm just trying to see what best fits my needs. Also I installed TrueCrypt, but I havent used it, because I'm trying to fully understand it.

I've read that the most secure encryption was AES, and that with 192 or 256-bits it was aproved by NSA for TOPSECRET documents. But also I read that Serpent is more secure and that the only advantage of AES is that it's faster.
Also I saw on somebody's sig (can't remember now), that he had Serpent with Whirlpool hash. But I read that Whirpool is asociated with AES.

Can somebody please explain this?

How do you implement this algorithms? I know Keepass implements AES and Twofish, but have you like an option? How does this work?

Thanks

 

i found a good page on truecrypt's site explaining the differences between them, or maybe it was on google. can't remember. my mind is shot as usual :/

aes is approved by US government for use in top secret documents.

some have found aes to be "mathematically flawed" that enables you to break it in 2 fewer rounds, but you still can't crypto analyze it and well, out of the three point umpteenth billion years you need to brute force it, the "flaw" maybe allows you to shave of a couple of years.

seriously, absolutely nothing to worry about.


basically you have the cipher and the hash and the signing

so you can put aes + whirplool
or serpent + whirlpool
or aes + md5
triple-des + sha-1

well, the possibilities are endless

all combinations available in truecrypt are "safe" to the best of my knowledge. some are 'better' than others, but even the 'worst' will take many a year to break. so it's not really of any use to say good or bad.

*edit: twofish is basically blowfish but better

 

So, I think I'm starting to understand...

What's the difference of the cipher and the hash? What does each one of them do?

 

There are several things wrong with this post.

The first bolded statement above is just wrong; maybe confused with something else?

The second bolded statement regarding Twofish is also, at the least, oddly phrased. Blowfish is a 64-bit cipher while Twofish is a 128-bit cipher. The two are cryptographically related and designed by Bruce Schneier (Twofish with the help of fellows at the Counterpane Labs). Simply saying, "twofish is basically blowfish but better," is as simplistic as it comes.

 

Various thoughts.

First things first. Use the AES. Implementations that use the AES have made the right design decision. Now, keep reading to find out why.

Quoting from CNSS Policy No. 15, Fact Sheet No. 1:

So, yes, you're partially right on that one.

Consult this post of mine, regarding why I feel it's preferable to use the AES whenever and wherever possible. From a security perspective, there's no need to implement Serpent or Twofish, "just in case." It boils down to the fact that the AES receives more cryptanalytical attention than any other block cipher, which is how a cryptographic primitive "earns its bones," so to speak. If you want even more reassurance, Ross Anderson (co-designer of Serpent) and David Wagner (co-designer of Twofish) recommend using the AES over Serpent and Twofish. Read Ross's thoughts on this on page 94, in Chapter 5 of his book, Security Engineering: A Guide To Building Dependable Distributed Systems (To all the security engineers in here: Do yourselves a big favor and download the first edition of this book). Read David's thoughts on this in a sci.crypt post of his. I highly recommend reading anything that David Wagner writes; it's always thought-provoking.

Consult this post of mine, regarding the similarities between the AES and Whirlpool's internal block cipher, W. Both the AES and Whirlpool were co-designed by Vincent Rijmen (the "Rij" in "Rijndael"), and both exhibit structures based on the wide trail design strategy. Here are some thoughts on the upcoming NIST hash function competition and our reliance on the NSA-designed SHA-256 as our interim standard, until the competition gives us something new.

I suggest that you consult the Handbook of Applied Cryptography for information that will help you differentiate between block ciphers and hash functions. Consult Chapter 6 [PS, PDF] for block ciphers and Chapter 9 [PS, PDF] for hash functions.

(Also, if you're interested in more of my opinions that I don't cover in this post, I suggest looking through my post history. I talk about why the AES is all you need, from a cryptographic standpoint, and why recycling the AES for encryption and authentication makes incredibly good sense from an engineering standpoint. If I dive into some concepts that you don't understand, feel free to ask me about them, and I'll be glad to elaborate.)

Cheers!

 

Meaning no disrespect to Justin, but another approach would be to run TrueCrypt's built-in benchmarks to compare the speeds of the various algorithms. I feel certain that all of TrueCrypt's included algorithms offer more than enough security to meet my needs, so I chose Twofish because it runs the fastest on my system.

I feel that in terms of real-world applications, comparing the strengths of the various block ciphers is a bit like comparing the thickness of steel doors. One may be 6" thick while another is 8" thick, but both doors already greatly exceed the security requirements of most homes (unless you are anticipating a mortar attack or something). Of course, under this analogy the 6" door turns out to be a bit easier to swing open, which makes it the better real-world choice.

 

http://www.theregister.co.uk/2002/09/16/new_aes_crypto_standard_broken/
"Theoretical attacks against AES (Advanced Encryption Standard) winner Rijndael and runner-up Serpent have been published. They might work in the practical world; they might not. That's about all we can say from the latest edition of Bruce Schneier's CryptoGram newsletter, which seeks to simplify the issues discovered by researchers Nicolas Courtois and Josef Pieprzyk, and elaborated in a paper entitled "Cryptanalysis of Block Ciphers with Overdefined Systems of Equations".

i might be wrong in my assumptions about twofish, it does use some of the same nuts'n'bolts as blowfish, just with improvements all around the board + beefed up key length. in my book, that's "almost the same, but better". i'm no mathematichian though.

plus, this forum is for home users. you need to talk "as simplistic as possible".. if you want to talk high level stuff, i suggest going elsewhere.

 

Please don't suggest that those who wish to delve deeply into cryptographic concepts should go elsewhere! Cryptography is by its very nature a complex topic and we desperately need to have knowledgeable people around who can explain it to us. I find the entire subject fascinating and I'm learning more every day, especially from Justin's posts. I don't mind if the discussions get technical.

 

Please, speak for yourself !


I'm personaly very intrested in Justin's posts.

 

I quite agree, and at the moment Truecrypts forums are down and because I have a email carrier that has a free edition I can't post because I have no posting buttons

 

Justin's contributions here, in the TrueCrypt forums, on his website, and elsewhere over the years have been of great value. Users appreciate such postings because expertise triumphs simplicity in the end.

Justin - please do not be offended. We can learn much from you. I am sure the programmers at TrueCrypt and elsewhere consider your advice as helpful in implementing better cryptographic solutions.

Those who cannot understand all your writings can always simply scroll to the next post. There should be room here for both experts and simpletons.....

 

Thanks to all the replies. I have a looong read ahead, I don't know where to start or when I'm going to find time for it.

I enjoy Justin's posts, despite sometimes I have to read them several times to understand them. I'm learning a lot, but because my previous knowledge about cryptography equals to zero, so I also enjoy when somebody talks "as simple as possible".

Now, lets go download those pdf's

 

You, who joined the forum THIS MONTH, are suggesting that I, who joined in 2004, "go elsewhere?" I think all the posts above said it all very well. Welcome to Wilders.

 

In reality, you're absolutely right. As I've said numerous times (possibly excessively), whenever cryptography fails in practice, it's almost never because of the cryptography itself; that is, whether or not you've using the AES, or Twofish or Serpent, isn't likely to matter. From the perspective of an end-user of an application like TrueCrypt, this holds true as well. They're given options, and it probably doesn't matter which one they choose. Your steel door thickness analogy is similar to the analogy I use when arguing against the urge for cascades, of which TrueCrypt uses. You're stacking more bricks onto a wall that's already too high to scale and too thick to torpedo. Adversaries will simply go around it, and you're catering to this by adding the extra complexity that cascades bring to an implementation. The implementation of the cryptography demands much more attention than the cryptography itself. Don't worry about the latter; it's the former that's going to let you down.

As a cryptographer who has work alongside developers, I stress the importance of not obsessing over things like block ciphers and key lengths. Multiple block ciphers don't make a product better, and I've seen protocols fall apart because of negotiation failures. Standards in cryptography are good things. They invite an onslaught of cryptanalysis and make developers' decisions a lot easier by giving them building blocks that are suitable for fielding in as many environments as possible. From a cryptographer's perspective, there's good reason for using the AES. From an engineer's perspective, there's even better reason for using the AES. Here's the cool part: We can recycle the AES for a variety of schemes, such as encryption, authentication (MAC), and a PRF (pseudo-random function). Not only do all of these schemes benefit from the cryptanalysis that the AES has received, but the implementation is simplified through the recycling process. Mistakes are less likely. That's exactly what we want. We don't need better cryptography. We need better implementations.

Obviously, the problem can't be dealt with by consumers; it's something to be handled at the developer level. TrueCrypt is, and will continue to be, an influential product. I certainly won't condemn it for exhibiting design decisions that I wouldn't make, but it's bound to rub off on future products. Ideally, such a role model would pass along good design decisions. Decisions that reflect the reality of security: Don't keep piling on the cryptography; gut the implementation of the unnecessaries. That's the disconnect between TrueCrypt and myself, if you will. I've only discussed these matters in TrueCrypt's forum, but not with the developers themselves. I'll change that in the near future, however. The problem seems to be that if you take away seemingly conservative options (i.e., cascades), you're going to disappoint the end-users who are conditioned to believe that more is more, when less is more, and that more cryptography is what we need, when simpler implementations are what we need. I'm working on this problem, though. I feel that it's predominantly a lack of communication between consumers, developers, and cryptographers.

On a side note, there may be niche applications for which Twofish or Serpent are better suited; in a case like that, I have no problem with implementing either of them. The general mantra is, though, "implement the AES when you can."

There's no need, practically or theoretically, to be worried about the security of Rijndael and Serpent, in regards to the XSL attacks. While this work, from Courtois and Pieprzyk is worth looking into, and shouldn't be ignored, it hasn't been demonstrated. Furthermore, we don't even know if it works or not. As such, this shouldn't be a reason for not using Rijndael or Serpent.

Twofish is related to Blowfish. When the design team approached the design of Twofish, their initial idea was to take the Blowfish design and extend it to work on 128-bit blocks. They wanted to benefit from some of Blowfish's properties, while introducing properties that made it even more efficient. They arrived at a solution that is, roughly, a single Feistel structure with two Blowfish-like 32-bit round functions.

Despite the similarities, it borrows building block ideas from other block ciphers, as well. For example, Twofish incorporates pseudo-Hadamard Transforms (PHTs), borrowed from SAFER, and Maximum Distance Separables (MDS matrices), borrowed from Square. Given that, it's probably not the best idea to simplify Twofish so much as to call it "Blowfish but better." We understand what you mean, though; it's just a matter of what constitutes the most proper definition.

No worries. No offense taken. Oftentimes, I'm in a bit of a rush, so I may not elaborate as much as I could, but I am certainly willing to simplify anything that may not be clear. In my writings for WindowSecurity.com, my goal is to simply cryptographic concepts for the layman, by keeping the mathematical stuff out of it. Of course, there will be terms that are still foreign to many - terms that can only be simplified so far. When it comes to those terms, I'll do my best to break them down as far as I possibly can.

I'm in the final stages of an exciting piece, at the moment, accompanied by the input of household-name pioneers. It's geared towards developers, but the premise is the same - simplify cryptography. Neither consumers nor developers are cryptographers, but the former depends on the latter's ability to do it right. It should be clear as to why simplicity should trickle down from cryptographer to consumer. The piece will be aided by the comedic relief of Alice and Bob, and of a similar tone to an article I wrote for Microsoft:

 

Interesting, so you found an algorithm named Truecrypt?
Could you correct this post please, because some newbies to encryption are going to be confused by that.

 

Sorry. I obviously meant Twofish as I used the correct name in the next sentence. It's fixed now. Thanks for bringing it to my attention.

 

Do my eyes really read what i think i just read? Who are you again? I thought this is a security forum, what do you expect from coming to a security forum... If you want things spoon fed to you in key-stage 3 language, then i suggest you go elsewhere.

 

Just use chained Serpent-Twofish-AES (or in any order you want) encryption and forget about each encryption algo flaws...

 

Last year I used the cascade Serpent-Twofish-AES, this year its AES-Twofish-Serpent. Nomater how you slice it.. it still is 256 + 256 + 256.

 

I guess that's about 1000X overkill, but whatever.

 

The reality of it all.

To be clear on the security of cascades, refer to this post of mine. I don't preach against using cascades because I think they're insecure. I preach against them because of the added complexity they impose on implementations. Since the demands of consumers often influence how a product is developed, I don't want consumers thinking they need cascades, nor developers thinking they need to implement them.

There's plenty of sense behind simply using the AES. It's conservatively secure and makes things a lot easier for developers. It's not the cryptography we need to be concerned about; it's the implementation part that gives us trouble. So, if you're using cascades, that's probably fine. It's important that consumers understand the reality of what they provide, security-wise, versus what they cost, implementation-wise.

 

Re: The reality of it all.

Thank you Justin for an explination.

 

Hi Justin...
I have one little question...

You have said many times that because AES recieves a lot of crypto-analysis, it is best to use it. Logic (and the stuff I read) tells me you're right...If more analysis is done on a specific algorithm, it is less likely that it has flaws and so on.

But would you please explain why we shouldn't worry that with all that attention on the AES, it won't be eventually cracked?

 

Look at it this way, HURST: In medical research if someone announces a huge "discovery" in cancer research, they announce that is now open to peer review and analysis. The peer reviews are actually intense analysis on attempting to show that the theory is wrong, full of holes, didn't consider this or that, etc. It's not that the intense peer review and analysis is out to discover a cure for cancer themselves (cracking the holy grail), but to prove weaknesses in the presented new protocol. The more analysis that shows the protocol is, in fact, on to something - the stronger the faith is in this particular new "discovery."

Justin, correct me if I am wrong, but I have always seen the intense analysis as a search for weaknesses in mathematical theory - not necessarily attempts to actually "crack" AES. The more analysis that shows the strength of AES, the more one is able to use it with confidence.

 

Why cryptanalysis is a good thing.

Gerard's analogy captures it quite well.

It might be better to look at this more internally, so to speak. Consider that the design of Rijndael is based on smaller components that adhere to a particular strategy for achieving certain security properties. To be more specific, Rijndael's design is based on the wide trail strategy, as are several other block ciphers and hash functions. The wide trail strategy existed before Rijndael came about; it wasn't something that hadn't been fielded before.

In cryptography, cryptanalysis is a perpetual activity. When we field designs, we want them to have seen sufficient scrutiny. If we build our protocols on primitives that we don't know much about, we're taking a gigantic risk; this holds true for the strategies on which we build our primitives. To survive a torrent of cryptanalysis is part of a primitive "earnings its bones." All cryptanalysis isn't about breaking a primitive; it's more often about how well, or not, the design strategies behind those primitives capture certain security properties and how they can be improved.

The AES does receive a lot of attention, and the fact that it holds up under such attention is an indicator that it's based on sound principles for how a block cipher should be designed. Sure, breakthroughs are possible; there's no denying that what we believe to be secure today can be broken tomorrow. Such is the cryptographic life, though. Practice tells us to be conservative, by building primitives and protocols on things of which we have a significant understanding. Cryptanalysis is what gives us that understanding.

That sounds right to me. I agree. A large chunk of analysis that takes place is about design theory; in fact, you might say this is the largest chunk of analysis that takes place. In regards to attacks on primitives, most are certificational (i.e., theoretical, without any imminent real-world applicability), with some constituting what cryptographers refer to as "academic breaks."