AESir File Crypter documentation by EddyHawk
---
What
---
AESir is a file encrypter coded by EddyHawk (me).
It is part of PROTAGON File Crypter (PFC) series done by me.
AESir uses AES cipher, CFB128 block cipher mode,
 MD4 & Whirlpool hash functions, and HMAC & PbKDF2 constructions,
 all taken from WE Pascal sources.

---
What is AES
---
Rijndael is a cipher designed by two Belgian cryptographers: Joan Daemen &
 Vincent Rijmen [1998].
It's a 128bit block cipher having 128-256 bit key & 10-14 rounds.
It's the successor of Square cipher.
It's a submission to NIST's AES competition and managed to become the winner.
 Since then it's simply called as AES.
Rijndael actually supports 128-256 bit block/key in 32bit increments,
 but only 128bit block with 128/192/256 bit key is considered as AES.

Best known attacks on AES are:
 128bit key:
  8 round using biclique key-recovery attack requiring 2^127 data,
   2^125.42 workload, & 2^32 mem [Khovratovich, Rechberger, 2011]
  10? round using chosen-key-relations-in-the-middle attack requiring
   at most 2^32 solutions, 0 ciphertext, & capability to halt encryption
   in the middle and grab the state [Rijmen, 2010]
  10 round distinguisher using biclique requiring 2^126.4 AES calls workload
   & 2^32 mem, with success rate close to 1 [Khovratovich, Rechberger, 2011]
 192bit key:
  9 round using impossible differential attack requiring 2^115.89
   chosen plaintexts & 2^180.89 time [Zheng Yuan, 2010] Unverified
  9 round using impossible differential attack requiring 2^125.89
   chosen plaintexts & 2^150.89 time [Zheng Yuan, 2010] Unverified
  8 round key-recovery using single-key [Dunkelman, et al., 2010]
  12 round using related-key amplified-boomerang attack requiring
   4 related keys, 2^133 data, 2^176 time, & 2^152 mem
   [Biryukov, Khovratovich, 2009]
 256bit key:
  8 round key-recovery using single-key [Dunkelman, et al., 2010]
  9 round using biclique key-recovery requiring 2^120 data, 2^253.1 workload,
   & 2^8 mem, with success rate 1 [Khovratovich & Rechberger, 2011]
  11 round using impossible differential attack requiring 2^122.4 chosen
   plaintexts & < 2^254.4 time [Zheng Yuan, 2010] Unverified
  9 round using key-differential requiring 2 related keys,
   2^39 crypts, 2^38 chosen plaintexts, & 2^32 mem, recovering full key
   [Biryukov et al, 2009]
  14 round using related-key boomerang attack requiring 4 related keys,
   2^99.5 data, 2^99.5 time, & 2^77 mem [Biryukov, Khovratovich, 2009]
 very vulnerable to side-channel attacks:
  128bit key-recovery attack using remote cache-timing requiring > 200m chosen
   plaintexts [Bernstein, Apr 2004]
  128bit key-recovery attacks using cache-timing requiring some access to
   target's machine or running probe software [Osvik et al., Oct 2005]
  128bit key-recovery attack using cache-trace [Zhao, Wang, 2010]
  no effective way to nullify such attacks without degrading performance
   significantly (AES in worst case execution time is 2x slower than normal)
   [Canteaut, Lauradoux, Seznec, 2006])

IP status: standard
Unbroken? status: as 2015, 17 years.

Best known key schedule performance is:
 crypt/decrypt KSA takes 300/1.4k cycles on 128bit key, Pentium Pro, C
Best known encryption performance is 
 18.10 cycles/byte on 128bit key, Pentium Pro, ASM.
 20.00 cycles/byte on PIII.
 10.57 cycles/byte on Intel Core 2 Duo mcpu [Bernstein, Schwabe 2008]
 10.43 cycles/byte on AMD Athlon 64 X2 3800+ [Berstein, Schwabe 2008]
 09.20 cycles/byte on Intel Core 2 Duo mcpu using pre-expanded 128bit key
  (10 round) under? bitslice mode [Matsui, Nakajima]
  but only for 2kb chunk pre-transposed into bitslice form (including
  transpose, it run at ~10 cycles/byte)
 07.81 cycles/byte on Intel Core 2 Q9550 mcpu [Kasper, Schwabe] using
  bitslice & mcpu's XMM registers & CTR mode & 128byte chunk
 07.08 cycles/byte on Intel Core i7 mcpu [Kasper, Schwabe]

Requirements: ~2.25kb static mem
Limitations:
 Key schedule for decryption is ~2x slower than for encryption

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

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

MD4 & Whirlpool hash functions and HMAC & PbKDF2 constructions for AESir
 are also taken/adapted from that collection [CRC_Hash 25 Aug 2014],
 and also compiled under Virtual Pascal v2.1b279.

---
AESir specific features
---
Forced disabling of large table for last round
AES compressed table as a bit of resistance to cache-timing attacks, and
 8-byte alignment to remove performance penalty of compressed table usage.
 These features are provided by WE's source. Apparently WE found this
 aligning trick by himself, and it really seems to nullify AES timing
 variability.

8-byte alignment check by also utilizing WE's AES_Encr.

Optimized PbKDF2-HMAC 9000 iterations with Whirlpool, 512bit output.

192bit key (12 rounds).

CFB128 mode
 Only requires the encryption function of the block cipher.
 Since AES key schedule for decryption is slower than AES key schedule for
 encryption, not using its decryption function has a bit of benefit.

---
FAQ
---
What's the meaning of '[AES: Tab-Al  OK]' or '[AES: Tab-Align  OK]' displayed
 on AESir early run?
 It checks whether AES compressed Table is Aligned to 8-byte boundary inside
 AESir code because that way AES will perform nearly as fast as one with
 uncompressed tables. Because unrelated, slight updates to AESir source may
 change the alignment, I make AESir to halt itself if the alignment isn't OK,
 so I can immediately be notified and adjust my changes to return
 the alignment back, usually by simply shortening/lengthening that alignment
 report string.
 Users won't benefit from misalignment too, because performance will go down.

Why choose 192bit key when AES supports 256bit key?
 Unfortunately, cryptanalysis on AES (see above) shows that AES256 is much
 weaker than AES192 in attack complexity, albeit w/ larger key (& 2 more
 rounds). This attack also reach full AES192, but its actual strength is not
 far below the expected strength from its key size.

Why not 128bit key, then, which only 8 out of 10 rounds gets attacked?
 Attack is defined as a way to break a cipher that is faster than exhaustive
 key search (brute-force), thus any attack that requires say 2^129 efforts
 isn't qualified as attack to AES128 since there is faster way to do that,
 that is brute-forcing its 128bit key. Yet AES128 strength will be limited to
 128bit, be that 8, 10 or even more rounds. If we choose to use AES
 but want strength > 128bit against related-key attacks, the only choice left
 is AES192.

What if I just want 128bit strength and no more?
 There are a lot of AES128 implementations out there. Read my EHIL.
 Note that most side-channel attacks target the AES128 in CTR mode.

Related-key attack isn't valid/practical attack!
Cryptanalysts focusing on related-key (weak) attacks only mean that they can't
find (stronger) attack which works against AES!
 Yeah, but isn't that weird that AES-256, supposedly the stronger one,
 is weaker than AES-192 in that attack model? 256bit strength reduced to
 <100bit is huge! What if later someone finds a way to extend this to
 single-key model? Won't you thank me then for my insistence to use AES-192
 for AESir?
 And maybe in the future there is an unexpected usage of cipher which makes
 such attack practical?

What if I still want AES256 because I consider related-key attack as invalid
 attack?
 There are some AES256 implementations out there. Read my EHIL.

Could you implement AES128 or AES256 for me?
 No. Personally I am not convinced of AES strength. AESir is provided here
 just for 'completeness'. Still, AESir isn't deliberately weakened in any way.

Will AESir support HW-accelerated AES?
 No, unless I get a ready AES source which does that.

Why Whirlpool instead of SHA512 for PbKDF2 & HMAC?
 Whirlpool is also co-designed by AES co-designer (Vincent Rijmen) and
 its underlying block cipher is also very similar to AES.
 Thus people believes in AES will surely be more confident with Whirlpool than
 with SHA512.
 Yes, Whirlpool gets a full attack, but so far it's just distinguish one and
 haven't yet led to more powerful attacks, so Whirlpool still safe to use.

End.