1. 18
  1.  

  2. 7

    Useful info beyond the medium post….

    https://github.com/chicks/aes/issues/5

    1. 7

      Blaming the developer is not my point, and the cryptography community is trying hard to advertise the better and appropriate tools, but as a reminder:

      If You’re Typing the Letters A-E-S Into Your Code You’re Doing It Wrong

      https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2009/july/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing-it-wrong/

      1. 3

        As an encryption-aware person (as in “I’m aware I want encryption, but aware how little I know about it”), I’ve been slowly bumping up the percentage of my life covered by such. This included recently upgrading my CPU specifically so that I could re-install my OS (GNU/Linux) with full-disk encryption (dm-crypt with LUKS).

        I upgraded my CPU because I was “aware” I wanted one that supported AES-NI.

        Your comment (and the attached article) leads me to ask some questions. You may not know the answers, but I would appreciate being educated by any of the fine Lobsters who read this:

        1. The default cipher for dm-crypt is aes-xts-plain64, presumably involving AES as it is in the name. Is it therefore a terrible idea per the article?
        2. If despite the name it is not AES, and the supporter ciphers (default or otherwise) for something like dm-crypt use a non-AES-based algorithm, are they then not actually benefiting from the AES-NI x86 extension?
        3. Am I mis-interpreting what AES-NI represents, and being that is simply a set of instructions, they can be used as primitives upon which useful acceleration for other, non-AES ciphers?
        4. Am I barking up the wrong tree entirely? Perhaps misunderstanding the failings of AES described in the article, and that it is acceptable/appropriate for disk encryption but not for the purposes in the article (i.e. authentication)?

        Any explanation or even just useful links to related reading is appreciated. I did about an hour of searching and reading before deciding to dump such a long list of questions here.

        1. 3

          The statement isn’t that you should not use AES, it is that you shouldn’t use it directly. It is OK to use AES if the only way it gets used is through something well-audited from crypto implementation point of view.

          1. 2

            Thanks for the clarification. I was indeed taking away the wrong lessons from my layman’s interpretation of the article.

      2. 5

        I think its prudent if you are using any encryption library to have tests for failure cases. This blog post does a great example of proving why.

        1. 5

          https://github.com/chicks/aes/network/dependents?type=application

          You can use GitHub’s new dependency graph feature to see open source projects that depend on this vulnerable gem.

          1. 2

            well this is vaguely terrifying

          2. 2

            String#hex in Ruby converts hexadecimal strings into an integer and if it fails, zero is returned:

            Oh seriously, Ruby, what were you thinking?

            1. 1

              This would appear to be a holdover from Perl;

              kahekkass ~$ perl -e "print hex '14'"; echo
              20
              kahekkass ~$ perl -e "print hex '1f'"; echo
              31
              kahekkass ~$ perl -e "print hex 'zxy'"; echo
              0