SOSEM file crypter documentation by EddyHawk
---
What
---
SOSEM is a file encrypter coded by EddyHawk (me).
It is part of PROTAGON File Crypter (PFC) series done by me.
SOSEM uses SOSEMANUK cipher, MD4 & SHA-512 hash functions, and HMAC & PbKDF2
 constructions, all taken from WE Pascal sources.

---
What is SOSEMANUK
---
SOSEMANUK is a stream cipher designed by all-French cryptographers:
 Come Berbain, Olivier Billet, Anne Canteaut, Nicolas Courtois, Henri Gilbert,
 Louis Goubin, Aline Gouget, Louis Granboulan, Cdric Lauradoux, Marine Minier,
 Thomas Pornin and Herv Sibert [2005].
It's a synchronous stream cipher having 128-256 bit key & 128bit IV, claiming
 128bit security.
It's basically a combination of SNOW v2 stream cipher with SERPENT block cipher
 (SOSEMANUK actually means 'Snow Serpent').
It's a submission to ECRYPT/eSTREAM and it has been included in eSTREAM
 portfolio along with HC-128, RABBIT, SALSA20/12 & GRAIN v1, MICKEY V2,
 TRIVIUM.
Best encryption performance of SOSEMANUK is 4.25 cycles/byte on
 AthlonXP 1.53Ghz compiled w/ GCC 3.4.2 (by the designers themselves),
 unfortunately the only CISC platform where it beats SNOW2 performance
 (5.125 cycles/byte)

SOSEMANUK requirement: 2kb storage for Alpha table
SOSEMANUK restriction:

Best known attack to SOSEMANUK:
 state-recovery attack using guess&determine requiring 2^4 keystream words
  & 2^224 computations [Tsunoo et al., 2006]
 suspected as vulnerable to cache-timing attacks due to its timing variability
  (no such attack is reported yet, though)

Unbroken status: as 2015, 10 years

---
Regarding SOSEMANUK
---
I personally doubt this cipher. The overall design seems strong and
well thought of. But what the designers are trying to accomplish here?
-SNOW v2 is unbroken & still faster on some platforms
 Maybe because SOSEMANUK uses SERPENT which is a slow performing block cipher.
-It actually uses reduced strength SERPENT
 Maybe because it tries to improve performance.
-If one or all base ciphers (SNOW v2 & SERPENT) are broken in the future,
 would that instantly reduce confidence on SOSEMANUK strength, eventhough that
 may not be at all true?
-If SNOW v2 is broken but SERPENT isn't, or vice versa, in the future, would
 that instantly reduce confidence on SOSEMANUK strength, eventhough SOSEMANUK
 may be actually safe because the other base cipher isn't broken?
-SNOW v2 is one of the fastest stream ciphers while SERPENT is one of
 the slowest block ciphers. Pairing them will produce somewhat less optimal
 perfomance.

Yet the designers did a fine job anyway:
-Managed to combine incompatible ciphers
-SOSEMANUK performs comparably to SNOW v2 (eventhough it includes SERPENT)
-Includes a strong block cipher is surely lend more confidence
-Picks up a weird yet cool name :)

---
What is WE Pascal source
---
Wolfgang Ehrhardt (WE) creates a collection of crypt Pascal sources which is
freely available in Internet, supporting Borland Pascal 7, all flavors of
Borland Delphi, Free Pascal Compiler, & Virtual Pascal, in single source.

SOSEMANUK stream cipher for SOSEM is taken by me from that collection
[SOSEMANUK 07 Jan 2013], then compiled under Virtual Pascal v2.1b279.

MD4 & SHA-512 hash functions and HMAC & PbKDF2 constructions for SOSEM
 are also taken from that collection [CRC_Hash 25 Aug 2014], also compiled
 under Virtual Pascal v2.1b279.

---
SOSEM specific features
---
16,000b file buffer (optimal).
 This is combined w/ special 'xorbuf' to improve speed.

The executable size is ~50kb (as Anub's). Perhaps because it must includes
 all Snow2 & Serpent static data too & because WE source uses
 somewhat extreme unrolling.

---
FAQ
---
What is the actual strength of 256bit SOSEMANUK key?
 SOSEMANUK authors claim that they only aim for it to have 128bit strength
 regardless of its key length (128-256 bit).
 However, best attack so far (above) stated that 225-256 bit SOSEMANUK keys
 only offer 224bit strength (yet still way above 128bit).
 Thus, 256bit SOSEMANUK key either has 128 or 224 bit strength.
 Now, which strength is more accurate? I am not sure myself.
 But picking 256bit instead of 128bit key clearly provide increased protection
  against pure brute-force attack, regardless of its actual strength.
 And I stick to 256bit key (instead of 224bit key) because it's convenient.

End.