1

Would anyone be so kind so as to describe to me the Serpent-256 cipher? How does it work and how secure is it compared to AES?

I have searched everywhere and found scarse info about it.

Anything related to it (speed, security, mode of operation, programs which use it, etc.) are highly appreciated.

Improve this question
1

1 Answer 1

Reset to default
2

Description of Serpent

I'd suggest you read the paper submitted during the AES contest:

Speed

Serpent is slower than Rijndael (cipher chosen to become AES), because it uses more rounds. See these benchmarks, Serpent in CTR mode could encrypt 32 MiB/sec while AES-256 in CTR mode could encrypt 96 MiB/sec. Additionally Serpent took 1.2 microseconds to setup key and IV while AES-256 took 0.76 microseconds. More benchmarks from the AES contest are available here; on a variety of platforms Serpent can encrypt 2 to 4 times less data than Rjindael (granted this was Rjindael which was slightly tweaked to become AES).

Security

Roughly equal in that both when implemented properly are secure against all known computationally feasible attacks. There are slightly better attacks on AES, but all the public attacks on AES are not computationally feasible (e.g., 4 times faster than brute-force) as well as other obscure attacks on AES (that is there's a related-key attack on AES that assuming some strange conditions is significantly better than brute force but is irrelevant for AES as typically used in a way susceptible to the attack, and then even then the best related-key attack takes 299.5 time which is not feasible). A large reason for more attacks on AES is that AES is widely used and analyzed, Serpent is not used nearly as much as it didn't win the AES competition (Rijndael won and became AES).

Mode of Operation

The mode of the operation is independent of the block cipher used--it's a separate choice. That is you can use either serpent or AES or any other block cipher in any block cipher modes. A mode of operation just considers how you take a block cipher that can only be used to encrypt/decrypt blocks of a fixed size (e.g., 128-bit block for Serpent256 and AES256 - the 256-bit stands for the keysize) and use it to encrypt/decrypt arbitrarily sized blocks of text without potentially leaking information if your plaintext is redundant (except in ECB mode which is an insecure mode where you naively just split the plaintext into equal sized blocks and apply the block cipher on each block independently).

Improve this answer
7
  • The block size for AES is always 128. Modes of operation address how to add message dependancy or position dependancy to more than one block of ciphertext.
    – Anton Garcia Dosil
    May 18, 2014 at 22:17
  • @AntonGarciaDosil - Edited. Thanks, it was a good catch. Note that there's intrinsically no reason that AES fixes the block size (e.g., prior to being standardized into AES, both the key size and block size of Rjindael could be changed independently).
    – dr jimbob
    May 19, 2014 at 6:47
  • 1
    Performance isn't so simple. 1) Serpent is pretty fast in parallelizable modes by using a bitsliced implementation, but can't compete with AES-NI. 2) Claiming it's slow "because more rounds" isn't sufficient either. Performance depends on both the number of rounds and the complexity of each round. Even the definition of "round" is pretty murky, for example what's called two rounds in ChaCha is only called one round in BLAKE.
    – CodesInChaos
    May 20, 2014 at 8:24
  • @CodesInChaos to quote Serpent's homepage "Serpent and Rijndael are somewhat similar; the main difference is that Rijndael is faster (having fewer rounds) but Serpent is more secure". I agree benchmarks shouldn't be trusted as hard fact (often depend on external factors like processor, how it was coded, etc) and that a serpent round != Rijndael round. Also the parallelizability of a block cipher should be irrelevant when comparing CTR mode (where decryption/encryption are both naturally parallelizable even if the block cipher is not.)
    – dr jimbob
    May 20, 2014 at 17:32
  • @drjimbob You can only implement Serpent efficiently when working on multiple blocks in parallel on a single core, whereas AES can also be implemented efficiently for a single block. So if you use CTR mode the relative speed of Serpent will be better compared to single block encryption. The Serpent implementation you liked probably doesn't take enough advantage of bitslicing. In OpenSSL Serpent seems to be 4x faster in parallizable modes (CTR, CBC decryption) compared to sequential modes (CBC encryption). So performance in CTR mode should be comparable to AES on modern CPUs without AES-NI.
    – CodesInChaos
    May 20, 2014 at 18:11

Not the answer you're looking for? Browse other questions tagged .