VeraCrypt - AES vs Twofish

Discussion in 'privacy technology' started by Amanda, Mar 4, 2016.

  1. Amanda

    Amanda Registered Member

    Joined:
    Aug 8, 2013
    Posts:
    2,115
    Location:
    Brasil
    I'll start encrypting my HD now, but I have a doubt: does it matter which cipher is faster, considering that my HD has a read/write rate of 40 MB/s when copying and pasting large files?

    I know Twofish's slower performance doesn't matter much on memory operations, but since I do video recordings to my HD I wonder if using AES would have any real advantage over Twofish.

    EDIT: Went for AES. I just realized I'm not a valuable target and therefore it's impossible that someone with a great amount of computer would want my data.
     

    Attached Files:

    • VC.PNG
      VC.PNG
      File size:
      37.1 KB
      Views:
      39
    Last edited: Mar 4, 2016
  2. haakon

    haakon Guest

    As an FYI for others: AES instructions are "built in" for most of Intel's high-end CPUs and offer a significant boost in performance.

    http://ark.intel.com/
    Look for "AES New Instructions" yes/no for the CPU of interest.

    I can't say for AMD procs.

    VCbench.jpg
     
  3. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    In almost any multithreaded processor (including AES-NI), you will be IO bound, not CPU. The data rates of domestic video recordings are also not usually that high due to improvements in video codecs.
     
  4. Palancar

    Palancar Registered Member

    Joined:
    Oct 26, 2011
    Posts:
    2,402
    Comes down to your trust of the API given to TrueCrypt (and now VeraCrypt) to make hardware acceleration work. It is not an area where there is an incontrovertible conclusion. To be flexible there is an option, which many users with advance machines elect, where you disable acceleration and therefore do not use the API that was given even if the computer supports such acceleration.

    Either algo works well and I don't notice much speed difference until at such time as you start triple cascade's, which I do on many archival volumes. Speed vs security tradeoff I am willing to make. My .02
     
  5. Amanda

    Amanda Registered Member

    Joined:
    Aug 8, 2013
    Posts:
    2,115
    Location:
    Brasil
    No need to trust, at least no blindly :) TrueCrypt has already been audited and it actually fine, no major security or cryptography problems. And VeraCrypt is TC continued - both are open source.
     
  6. Palancar

    Palancar Registered Member

    Joined:
    Oct 26, 2011
    Posts:
    2,402
    You missed my point so let me elaborate. Just trying to help here.

    TrueCrypt had NO control of the provided AES-API. This came from Microsoft. Two articles with a couple of snips to point you in the direction to learning.

    http://download.cnet.com/blog/downl...rdware-acceleration-convenience-improvements/

    The latest TrueCrypt takes advantage of pressure directed from TrueCrypt towards Microsoft in the wake of version 6 that requested an API for hibernation files, which had not existed previously.
    ## This AES-API that came from Microsoft is encrypted and is not open source requiring you to trust Microsoft!!



    https://www.truecrypt71a.com/documentation/hardware-acceleration/

    If you want to disable hardware acceleration of AES (e.g. because you want TrueCrypt to use only a fully open-source implementation of AES), you can do so by selecting Settings > Performance and disabling the option ‘Accelerate AES encryption/decryption by using the AES instructions of the processor’


    We examined this over many threads at the TC forum throughout the years. Pro's and Con's went back and forth. You will have to make up your own mind on this. The acceleration API came from the same company that made Windows. I guess to be consistent you either trust Microsoft or you don't.

    I personally elect to use the open source and "known" AES afforded by TrueCrypt and now Vera Crypt by default. Only rarely will I pick a small speed differential over security. I turn off and use the established method, but again, its your call.

    I hope this post clears this up for you.
     
  7. Amanda

    Amanda Registered Member

    Joined:
    Aug 8, 2013
    Posts:
    2,115
    Location:
    Brasil
    @Palancar You're right, I forgot that the API is provided by MS. My apologies.

    Is the Crypto API also provided by MS when we don't use hardware acceleration?
     
  8. Palancar

    Palancar Registered Member

    Joined:
    Oct 26, 2011
    Posts:
    2,402
    NO. The "original" product is open source and did not come from Microsoft. It is un-able to do acceleration as you have found out. When you turn off/disable acceleration (assuming your machine supports it), TC/VC reverts to the included original open source method of crunching the math.

    Your use of the word "apologies" is also completely unneeded. We are two friends helping each other along, that is all. I have well over a decade and too many thousands of hours to count using this code. You returned the favor answering some of my linux inquiries when I switched to Debian awhile back.
     
  9. haakon

    haakon Guest

    Some of us might recall Rijndael won NIST's AES contest in October of 2000 over Twofish and Serpent largely due to its hardware friendliness.

    The OP's pre-edit inquiry focused on speed, citing a metric and presenting a screenie of the benchmark.

    All I did up there is FYI inject the awareness and merits of the hardware acceleration offered by Intel's AES-NI support and threw in my own benchmark.

    While my proc is obviously more powerful than whatever the OP uses, note that Twofish is only 3.5 times faster, Serpent 3.3, while AES is 11.4. With accel disabled, AES is equally impaired as I tested a while back when I built this i7 box. (Producing a benchmark screen shot just for this thread is beyond the scope of my efforts.) Hardware acceleration SMOKES. Period.

    IO, API, trust... not relevant to my #2 post. Cheers!
     
  10. Amanda

    Amanda Registered Member

    Joined:
    Aug 8, 2013
    Posts:
    2,115
    Location:
    Brasil
    Oh, that's fine then. That's what I use.

    Tell me: If the processor has AES acceleration, can we disable it on the BIOS so that TC/VC use their own API?

    Thank you :thumb: But I apologize so people don't think I'm trying to be the smartass or whatnot ;) Some people in this forum really hate me and would use anything against me.

    Correct. IIRC Twofish is twice more secure, though it's performance isn't a match to AES. I do look forward to see what Threefish will bring.

    Sorry for not responding, I just don't have an Intel processor (since 2006) so I can't comment on that :)

    May I ask which processor you have?
     
  11. Palancar

    Palancar Registered Member

    Joined:
    Oct 26, 2011
    Posts:
    2,402
    Could not agree more. I would say that most users of TC/VC are only protecting against theft and general privacy/security. The aspects to which I referred above are only applicable if your adversary carries a "badge" or wields similar powers. For those against such an adversary, I maintain that hardware acceleration (while many times faster) is not worth the additional risk due to the encrypted closed source API.

    I share some others' opinions and I am quite fond of twofish. On my linux machines I build the LUKS headers to custom twofish specs and really attempt to harden the headers.

    amarildojr --- he is using the i7 proc, or at least that is what is depicted in his post.
     
  12. Lagaa

    Lagaa Registered Member

    Joined:
    Dec 30, 2014
    Posts:
    10
    This is all nonsense. AES is deterministic algorithm so output from AES-NI and open source version would be identical. If they aren't the encryption would be corrupt as you wouldn't be able to decrypt. It makes no sense to not use AES NI when that option is available and much faster.

    In fact if anything AES NI version would be more secure as it would be secure against timing attack, unlike the open source software implementation.

    And there is no reason to believe twofish is more secure. If anything it's far more susceptible to timing attack, as Twofish uses even more lookups table than AES
     
    Last edited: Dec 18, 2016
  13. Palancar

    Palancar Registered Member

    Joined:
    Oct 26, 2011
    Posts:
    2,402
    Your response is only accurate if in fact you fully trust the closed source M$ API, which VeraCrypt and TrueCrypt use for their hardware acceleration option. The TrueCrypt team expressed concerns over what could be done within an encrypted API if the designer wanted to create a sinister internal environment. Of course on the surface the output file is going to match the open source counter-part. In the same way, metaphorically, you wouldn't create a RED dollar bill on the surface. Your counterfeit "actor" is not going to look anything but genuine on the surface, and so its determinable output will reflect accuracy. The TC coders realize that our users are "adults" and so they were given the option to trust the M$ API on equipped hardware, or turn it off and use the open sourced software API provided. Let me be clear; I am not accusing M$ of sending out a backdoor'd API, I am only saying there is no way to make that determination. If THEY would willing release an un-encrypted version it would end the controversy, but for some reason they don't. Go figure!

    Responding to the portion of your post regarding the AES selection of R. over Twofish or Serpent would be pages of content here. We have a few things down in the linux forum covering some discussion. Personally for my needs and uses, and in my opinion, they got it wrong! I only use serpent and twofish when given a choice for my needed to be kept secure data. Usually I cascade and use both, gladly taking the cascade performance "hit" to affect what I perceive as a security bump. If you differ that is OK. I don't intend to be "herded" into an AES selection which I feel is weaker.
     
  14. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    @Palancar - good summary. The thing that influences me more is that I'd assess there are many easier and less risky approaches than messing with the MS API, given that you are using an MS OS in the first place. The obvious thing would be a little KSL somewhere. Of course, that doesn't mean that a tweak is not available for the TLAs, it's just that that would likely be used as a last resort by which time you'd have been owned in so many other ways.....
     
  15. Palancar

    Palancar Registered Member

    Joined:
    Oct 26, 2011
    Posts:
    2,402
    I know we agree on so many things. I always want to just type away on these type threads. There are those that will always trust M$ and defend that OS supremely. Cleverly (on their part) many corporate software applications are reliant upon that OS to even function. It is clearly planned and one of the reasons many are in effect forced to "hang on". I am not going to expand on this much further. Forensic examination of that OS demonstrates to me how innumerable the ways to get PAWN'D are.
     
  16. Lagaa

    Lagaa Registered Member

    Joined:
    Dec 30, 2014
    Posts:
    10
    Once again, AES is a deterministic algorithm, so for a given key, IV and message, the encrypted output would be identical, regardless if it's a closed or open source software/hardware that actually did the encryption.. If the output were not identical (every single bit), encryption would be corrupt. This is not a random number generator where you don't know whats happening if you don't have the source code. AES is a deterministic algorithm. Do you understand that part? The key and IV are generated randomly by TrueCrypt. In this case, hardware accelerated version is definitely more secure than open source version as hardware accelerated version would be secure against side channel attacks (like timing attacks) which is far weaker part of the system than the primitive (AES, Serpent, Twofish) itself.

    There has been a lot said in past 16 years on how Serpent and Twofish are more secure, but most of these claims are nonsense. There is no mathematical proof for that. Serpent has more rounds so people claim it's more secure as security margin is larger. Twofish was hugely promoted by Bruce Schneier who wrote the whole paper promoting it during AES competition. Again, all nonsense. Twofish by design has more lookup tables so it could be open to more timing attacks. How do you know someone doesn't have such software that can extract Twofish key on a system that is running Twofish encryption? It's certainly very possible. Twofish was also harder to implement in hardware, one of the reason it scored worse than both Serpent and Rijndael.

    If I had to put money, I would say AES with hardware acceleration (remember that the key is generated randomly by Truecrypt) would be more secure than Twofish and Serpent combined as at least AES with hardware encryption is likely to be more secure against side channel attacks. That's one of the key advantages of hardware acceleration (aside from speed) as it eliminates all kind of timing attacks (and things like analyzing power consumption) that are theoretically possible when the system is doing the encryption.

    Note: if AES wasn't deterministic algorithm different browsers and web servers wouldn't be able to communicate with each other as some systems are doing the encryption in software, some in hardware, some are running linux, some cellphones, some Windows. When Truecrypt uses AES-NI, even though it's not open source, for a given key and iv, the output is 100% identical, every single bit, to when it's doing the same encryption without AES-NI and using only open source software. Using AES-NI just adds more speed and more security, without changing the output.
     
    Last edited: Dec 21, 2016
  17. Lagaa

    Lagaa Registered Member

    Joined:
    Dec 30, 2014
    Posts:
    10
    You actually upped your security by making the switch to AES with hardware encryption, not the other way around :)
     
  18. Amanda

    Amanda Registered Member

    Joined:
    Aug 8, 2013
    Posts:
    2,115
    Location:
    Brasil
    Theoretically, yes, because AES receives the most attention and is the most widely tested.
    However, it's the least secure of the AES finalists.
     
  19. Lagaa

    Lagaa Registered Member

    Joined:
    Dec 30, 2014
    Posts:
    10
    Which of course is just an often repeated claim with no mathematical proof except that during AES competition, some people claimed there was less security margin due to less rounds, which ignores the fact that two rounds of Rijndael provide ‘full diffusion’ unlike Feistel ciphers (like Twofish) that need more rounds for ‘full diffusion’

    In practice, AES is most secure as AES-NI eliminates all kinds of side channel attacks (timing attacks, power consumption analysis, etc) . Twofish has more lookup tables which means some implementations could allow more kinds of possible side channel attacks.How do you know that isn't the case? You don't.
     
    Last edited: Jan 7, 2017
  20. Lagaa

    Lagaa Registered Member

    Joined:
    Dec 30, 2014
    Posts:
    10
    Just a simple search on timing attack on Twofish has this November 2016 paper

    https://arxiv.org/pdf/1611.07109.pdf

    "We have shown that the Twofish Encryption Standard is susceptible to a Simple Power Attack that is based solely in the Hamming weights of the Key Schedule Computation. The algorithm successfully obtains the value of the secret with just one run of the algorithm and in the presence of a relatively large amount of noise. Moreover, we have seen that the attack threatens not only 8-bit implementations but any Twofish implementation since the architecture of the cipher forces the key schedule to explicitly compute the byte values that are needed for the described attack. Finally, the worst runtime of the algorithm is under one second, so the attack is not only feasible but also efficient."

    AES and Serpent also had similar attacks. The difference is that all modern CPUs (intel, AMD, and even new phones with ARMv6 chips) have AES instructions which not only make AES much faster but far more important protects against these types of side channel attacks.

    It should be clear now that switch from Twofish to AES in this case increased security, significantly.

    In fact Veracrypt should deprecate Twofish and Serpent and replace these with Chacha20 and AES as two options.
     
  21. 142395

    142395 Guest

    I've been disappointed to see there're too many wrong comments about crypto on the web forums or news sites by seemingly tech savvy, but it seems Wilders is no exception. I wanna correct at least this one.
    The fact AES is deterministic is mostly irrelevant. The concern remains that MS potentially may sniff encryption key w/out affecting its result, tho it's another matter if that is worth worrying.

    In practice AES, Twofish, Serpent are equally secure. But in theory it's AES<Twofish<Serpent and it's proven by security margin, except that probably AES would have been analyzed most thus supposedly have less possibility of unknown attack (can't be proven).

    Given how common user use TC/VC, timing attack is irrelevant. This means you have a malicious process which tries to know your key. But for home machine such attacker had better to use keylogger or direct memory attack like KeeFarce (or rather, steal the contents when decrypted). When certain attack is possible but there're easier attack, it does not decrease security, this is common sense in security field. But timing attack is concern in auth server or where adversary have physical access but for some reason other easier attack is not applicable. Contemplate why KeePass chose Argon2d and not Argon2i.

    "AES w/ AES-NI is more secure than Twofish + Serpent" is clearly wrong. Serpent is quite resistant to timing/cache attack by itself. BTW, there're too many side channel techniques which AES-NI doesn't help, if you really care side channel.

    The fact Feistel needs more rounds than SPN for diffusion is irrelevant to security margin which devs can determine freely. It is calculated by ratio, not difference. In fact, Serpent uses SPN but has more rounds & margin than AES or Twofish.
     
    Last edited by a moderator: Oct 5, 2018
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.