1. 1

    An authenticated, local attacker could modify the contents of the GRUB2 configuration file to execute arbitrary code that bypasses signature verification.

    If the attacker can do this, they can also overwrite the whole bootloader with something that bypasses signature verification. If you can do this, your system is already compromised.

    1. 2

      No they can’t. Or rather they can, but if Secure Boot is on the UEFI firmware will refuse to load the modified grub.efi image, so the system won’t boot.

      1. 1

        So, this vulnerability allows jailbreaking, but does not affect security against attacker without a root password?

        1. 3

          How about an attacker armed with a local root privilege escalation vulnerability aiming to achieve persistence?

          1. 1

            https://xkcd.com/1200/

            To do what? They already have root for plenty of persistence. I mean, yeah, they can penetrate deeper. They can also exploit a FS vulnerability or infect HDD or some other peripheral.

            But that’s just not economical. In most cases, it’s the data they are after. Either to exfiltrate then or to encrypt them.

            In other cases they are after some industrial controller. Do you seriously believe there to be anyone competent enough to catch the attack but stupid enough not to wipe the whole drive?

            The only thing I can imagine TEE being used for is device lockdown.

          2. 1

            Not sure what you mean by jailbreaking - can you clarify? We’re talking about a laptop/desktop/server context, not mobile. Secure Boot does not necessarily imply that the system is locked down like Apple devices are. See Restricted Boot.

            If the attacker cannot write to /boot, then they can’t exploit this vulnerability. If the attacker has physical access this probably doesn’t hold true, regardless of whether they have a root password. If the attacker is local and has a root password or a privilege escalation exploit then this also doesn’t hold true, and can be used to persistently infect the system at a much deeper level.

      1. 18

        I have nothing but admiration for your work and the dedication it took to educate yourself well enough to produce what is apparently a good working crypto library. I also think you are literally one in a million for not only being able to do that, but investing the time and effort to actually do it. You are nowhere near the target for the advice to not roll your own crypto.

        In other words, replacing the advice “don’t roll your own crypto“ with “don’t roll your own crypto unless you can spend years learning how to do it properly” is not a significant change to the advice.

        Not to mention that even if you do know what you’re doing, at any moment you might find out you don’t know what you’re doing. Remember when everyone seemed to suddenly realize constant timing was important? Cryptography is a continuous study, not like a data structure you learn once.

        1. 10

          One fear I have is that some people might be discouraged to even start because of the negativity. Though my bigger fear is that the wrong kind of people end up charging ahead.

          1. 11

            I’m just not sure discouraging people is a bad thing. Cryptographic code is extremely unusual, perhaps even unique, in that it can fail catastrophically and silently, years after a perfect test suite passes perfectly. The gap between amateur and professional quality is huge, yet nearly invisible by normal code quality standards. Even the normal tools don’t work: I mean, have you ever seen a unit test framework that automatically tests timing attacks in addition to inputs and outputs? So if you’re going to propagate a one-liner meme about “rolling your own”, there are very good reasons to make it a discouraging one.

            1. 3

              How you discourage people is important in my opinion. One way to do it is to show the gap between casual and professional. Takes more than a one liner, though.

          2. 5

            suddenly realize constant timing was important?

            Suddenly? There were papers at least as early as 1996 (Kocher’s Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems that appeared in CRYPTO 1996). AES was standardized in 2001. The writing was on the wall if anyone had cared to look.

            1. 11

              That’s why I said people “suddenly realized it was important”, not “it was suddenly important”. It was always important, but the news seemed to take a while to reach a lot of implementors who had thought they knew what they were doing (and probably continued to think that).

              1. 7

                Yep. As late as 2017 (maybe later, that was when I checked), the most popular Java bcrypt library did not compare the hash in constant time when verifying passwords.

          1. 10

            Wasn’t there an article the other day explaining that GNU crypto projects have a lot of issues regarding security?

              1. 7

                The products criticized were developed at different times, by completely different teams, and their perceived insecurity differs. The greatest issue with GnuPG seems to be its poor usability, but that didn’t stop the author from spouting off about it. The only thing that these projects have in common is their attachment to GNU.

                As far as I can remember, GnuTLS has had a poor reputation - I remember one issue involving it using zero-terminated strings for binary data. Which is why OpenSSL was seen as the ‘serious’ choice.

              1. 11

                Oh cool, I opened Lobste.rs to find something to read and saw this headlining the site! It was a pleasure to work on this audit.

                1. 3

                  I couldn’t let your work go unseen after all. :-)

                  1. 3

                    But now for the question burning under everyone’s nails: How much did it cost?

                    1. 3

                      Looking at my application, it cost $7.000, all paid by the OTF.

                1. 1

                  May I be debunked around post-quantum proof cryptography: Is it something to bother this early? I feel like this is up to CryptoPeople to tell to NonCryptoPeople about that rather than the other way around.

                  I have the impression that it is more about studying well how ciphers face the threat than finding the Golden Bullet.

                  1. 3

                    Should we be bothering with research and serious implementations? Yes. Quantum computers are an inevitability and it’d be nice to be ready when they’re there.

                    Should we be putting them in production? Probably not. Many NIST post-quantum cryptography candidates are still getting attacked left and right. And there’s a non-zero chance that the result will still either be impractical, patent-encumbered or both.

                    1. 2

                      Being able to build large enough quantum computers to break current asymmetric cryptography is definitely not inevitable. There are many issues that may end up making it physically impossible to make such a computer that runs long enough to do such a computation. Of course, it is prudent to assume it will happen and develop resistant cryptography in the meantime.

                  1. 1

                    As a non-cryptographer, I am curious about the promises blake3 offers, and whether it is worth considering it instead of blake2. I saw blake2 in monocypher?

                    Given it is a crypto primitive, it may not work as simply as bumping a dependency from version 2 to 3 (unique output length, variant…) or it may! Any major change like this one could also require a new audit (no idea).

                    1. 3

                      Blake3 is Blake2s, with 2 differences:

                      • The core loop can be run in parallel. That enables vector instructions, making it much faster on modern processors.
                      • The number of rounds is reduced. This reduces the security margin, but it is also faster.

                      Personally, the reduced rounds make me a little nervous. The parallelisation however is a killer feature. This allows Blake3 to stay 32-bits and fast on big processors. That makes it a one-size fits all algorithm, much like Chacha20.

                      Bumping from Blake2b to Blake3 would not require a new audit in my opinion. Blake3 is a symmetric primitive based on a RAX design (Rotate, Add, Xor), which makes it easy to implement, and very easy to test: just try every possible input length from zero to a couple block length then compare the results with a reference implementation.

                      Now if I were to redo Monocypher now, I would consider Blake3. There’s just one problem: Argon2i, which is based on Blake2b. I could repeat the shenanigans I did for EdDSA (allow a custom hash interface, provide Blake3 by default, as well as a Blake2b fall back), but that would mean more optional code, a more complex API, all for a limited benefit. I believe Blake2b makes a slightly better trade-off for now, even though many of my users are embedded programmers.

                      1. 4

                        and very easy to test: just try every possible input length from zero to a couple block length then compare the results with a reference implementation.

                        There are machine-parseable test vectors that test various edge cases as well.

                        The existing BLAKE2b API in Monocypher would need to be broken anyway because of the mandated API design with a context string.


                        Edit: Also, why is Argon2i an issue? As far as I’m aware, Monocypher implemets it from spec, which is notoriously incompatible with the reference implementation. So if Monocypher is already incompatible with every other implementation under the sun (which are all just derivatives of the reference implementations), why would you bother caring about the hash function used in Argon2i?

                        1. 2

                          Monocypher is compatible with both the reference implementation and Libsodium. The divergence with the spec is explicitly noted in the source code.

                          Also, one of authors said the specs “will be fixed soon”, so that’s a clear sign that everyone should conform to the implementation error of the reference specification. (And yeah, he made that promise over 3 years ago, and the specs still have not been fixed.)

                        2. 1

                          Thank you for the overview. I understand the balance better now.

                          And obviously, thank you for Monocypher!

                      1. 1

                        Would there be benefits on using it for existing projects? Such as the classics (TLS, SSH, PGP…). Or is the benefit only noticeable for new projects, for which there is not yet a (too) large crypto code base in use?

                        1. 2

                          Monocypher is focused on a small number of modern primitives. That makes it incompatible with most of what those old standards need. No AES, no RSA… So I’d say new projects only.

                          In addition, Monocypher is a low level crypto library. A toolkit with which you can build higher-level protocols For instance, I’m currently working on authenticated key exchange with Monokex. Or you could build Noise.

                          1. 2

                            Forgive the possibly ignorant question, but would Monocypher be useful for encrypting traffic between two servers? I’m in need of encryption in a distributed system where SSL certificates would be unreasonably expensive and self-signed is not acceptable.

                            1. 3

                              It would be, but you’d need to implement an existing protocol (such as a suitable Noise pattern) that provides the security guarantees you want.

                            2. 1

                              I like the idea of small, strongly built, loosely coupled building blocks on top of which implement higher-level parts.

                          1. 2

                            Congrats!

                            Aside from it being a good best practice (which I guess implies a higher level of trust by security-conscious people?) are there any other benefits of being audited? Does this make it eligible to be run in some environments? Or make it a viable option for some standards?

                            1. 9

                              Thanks :-)

                              As far as I know, eligibility tends to increase with the user base: the more users use it, the more people feel safe using it. An audit certainly increases confidence, and with it, eligibility. Personally, the audit is a big reason why I now feel confident recommending Monocypher in a corporate setting. Before the audit, my own conflict of interest (choosing the best option vs choosing my option) always gave me pause.

                              Standards are different. Monocypher only implements existing standards & specifications. It could be used as a reference implementation, but that’s about it.

                              1. 6

                                Does this make it eligible to be run in some environments?

                                The audit is unfortunately relatively meaningless in that context. Highly regulated environments tend to insist on either ISO or NIST standards and require specific certification for them. Monocypher does not implement any of them (though Ed25519 may become part of FIPS 186-5 the way things have been going).

                                1. 3

                                  Yeah, there tends to be a fairly long delay between “good” and “standard”. I get the vibe that standardisation bodies don’t trust themselves to assess cryptographic primitives and constructions. Being overly conservative is the only rational choice in this circumstance.

                              1. 7

                                The section “Finite Field Definition” is unfortunately imprecise. The right way to look at algebraic structures is that you have a fixed set S and then define operations on it:

                                • A nullary (0-ary) operation is just a fixed element of S.
                                • A unary operation is a function S -> S.
                                • A binary operation is a function S x S -> S.
                                • A ternary operation is a function S x S x S -> S.
                                • And so on.

                                The way the author phrases the “closed property” makes it seem as though operations could, at least in principle, return things that are not elements of S. This is not a very good way to look at algebraic structures. Math is not like programming, where a function that “supposedly returns int” could have, ahem, “interesting results” like throwing an exception, or your program remaining stuck in an endless loop, or even returning a string if you are using a funny enough programming language.

                                In addition to a set and a bunch of operations, we need axioms, or else there is not much that one can do with the resulting structures. The list of field axioms is a little bit long (I think it has about 10 axioms, although it can be shortened at the price of using even heavier abstraction), and very few of them are mentioned in the article. Sadly, the axioms are not something you can omit, because they are a part of the definition of the structure. Without the axioms, you do not get the theorems, and the theorems are precisely what you need to justify that the algorithms actually work.

                                The way the examples are presented is also a bit iffy. Sadly, here ring theory has a history of abuse of notation that makes its conventions hard to explain. (Ring theory is not particularly bad. Other parts of mathematics are worse.) The symbols -2, -1, 0, 1, 2, 3, etc. do not mean the usual integers, but rather their images under the canonical ring map Z -> A (where Z is the ring of integers and A is an arbitrary ring). So, in general, it does not make sense to say “1 + 2 = 3, hence the set {0,1,2} is not closed under addition”. If you have a ring of characteristic 3, then 3 = 0 and 4 = 1 in that ring, hence 1 + 2 = 0 and 2 + 2 = 1, hence the set {0,1,2} is closed under addition in that ring! In particular, all finite fields are rings of characteristic p for some prime number p.

                                The author’s assertion that the order of a finite field is always a prime number is incorrect. For every prime p and every positive integer n, there exists a field of order p^n. (And it is unique up to isomorphism.) But maybe it is the case that only fields of order p are of interest in cryptography.

                                Back to proper programming concerns, I do not think it is particularly useful to declare specific data types for doing modular arithmetic. Types (both static or dynamic) are supposed to give you automated checking that you are only passing around arguments that make sense. However, in number-theoretic routines, the proposition “passing this argument makes sense” is usually a much deeper theorem than what a normal type system can prove. So there is no substitute for clear documentation, and actually understanding why and how the algorithms work.

                                1. 2

                                  But maybe it is the case that only fields of order p are of interest in cryptography.

                                  Prime-order fields are of primary interest for elliptic curve cryptography, yes. However, extension fields (BLS signatures and other pairing-based cryptography) are sort of popular in some niches recently. Binary fields are also found on occasion for elliptic curve implementations (though the current speed winners are all GF(p) curves).

                                1. 3

                                  This is probably not the reason, but it’s still something worth keeping in mind: X.509 certificates are in their default state large because RSA keys are large. These examples use DER since PEM is just a thin base 64 wrapper around DER.

                                  $ openssl req -nodes \
                                      -newkey rsa:2048 \
                                      -keyout x.key -out x.crt \
                                      -days 365 -outform DER -x509 \
                                      -subj '/CN=API client #1337'
                                  $ ls -l x.crt
                                  -rw-r--r-- 1 xh xh 795 MMM DD TT:TT x.crt
                                  

                                  And you have that overhead on every connection, even more if you have a certificate chain. Plus the overhead of actually doing the asymmetric cryptography, which may or may not be faster or slower than whatever people do on the OAuth backend depending on the exact loads involved. OAuth tokens are substantially smaller.

                                  You can at least alleviate this to some extent by using elliptic curve keys, but then you’re off the beaten path. What’s more, ECDSA is notoriously fragile.

                                  $ openssl genpkey -genparam \
                                      -out ec.param \
                                      -algorithm EC \
                                      -pkeyopt ec_paramgen_curve:P-256
                                  $ openssl req -nodes \
                                      -newkey ec:ec.param \
                                      -keyout x.key -out x.crt \
                                      -days 365 -outform DER -x509 \
                                      -subj '/CN=API client #1337'
                                  $ ls -l x.crt
                                  -rw-r--r-- 1 xh xh 399 MMM DD TT:TT x.crt
                                  

                                  The actual public key is just 65 bytes (04 to indicate uncompressed key, 32 bytes of x-coordinate and 32 bytes of y-coordinate); compression isn’t widespread either due to patent issues that only somewhat recently got resolved by patent expiry. This means that there are 334 bytes of overhead, a lot of which is related to ASN.1/DER encoding and other X.509 metadata.

                                  RFC 7250 lets you use raw public keys in place of certificates (RFC 8446, section 2, p. 13 for TLSv1.3), but support is not very widespread, you’re very much off the beaten path and have no way to indicate expiry other than manual revocation. And you want to be on the beaten path because otherwise you’ll probably run into some issue or another with implementation support. Certificates for EdDSA keys (yay!) theoretically exist, too (RFC 8446, section 4.2.3, p. 43), but you can basically pack it up if you need to interoperate with anything using either an off-beat TLS library, anything in FIPS mode or anything older than two years.

                                  1. 5

                                    This means that there are 334 bytes of overhead

                                    I have a solution: remove all the tracking cookie junk we’re getting forced on us and add this instead, win-win! Browser-controlled session cookies for first-party connections only could be so very good…

                                  1. 4

                                    Interesting read, but I don’t understand one detail of the argument: what makes Perl more secure than the other scripting languages mentioned?

                                    1. 13

                                      Taint checking comes to mind, and Perl has it. I think OpenBSD folks prefer tech where it’s easier to do the right thing; doing the right thing in shell or php can require more effort, with painstaking, error-prone effort to avoid pitfalls.

                                      1. 2

                                        ruby might be an interesting alternative, but I would assume it doesn’t support nearly as many platforms or architectures as perl.

                                        EDIT: huh. Apparently ruby removed taint checking in 2.7.

                                        1. 10

                                          Ruby code ages poorly compared to perl, though. I’ve been on too many projects where code written in ruby a year or two earlier at most had already been broken by language or dependency changes.

                                          1. 2

                                            To be fair, OpenBSD controls base, so they could keep a check on the dependency changes. Language changes are rarely breaking with Ruby, when was the last one?

                                            1. 5

                                              Now, you’ve got to start auditing upstream for bug and security fixes, and backporting them, rather than just updating when needed.

                                              Forking is a bunch of work – why do it when there’s a suitable alternative?

                                              1. 1

                                                We may be talking past each other here. I said that they could keep a check on the dependency changes, by which I meant that they would author code in such a way that it does not require external dependencies (or at least not few enough that they couldn’t vendor them), which wouldn’t be any different from what they’re doing with Perl already. This means that this downside of the Ruby ecosystem could be mitigated. And language changes they’d just have to accept and roll with, but I hold that Ruby rarely introduces breaking changes.

                                                OpenBSD will have to vendor $language_of_choice in any case because that’s how the BSDs’ whole-OS approach works.

                                                1. 2

                                                  Yes. I thought you meant essentially forking the shifting dependencies instead of fully avoiding them.

                                                  In any case, perl is there and in use, so switching would be a bunch of work to solve a non-problem.

                                            2. 1

                                              Yeah, you’re not wrong. Excellent point.

                                        2. 4

                                          Maybe the “use warnings” and “use strict”?

                                          1. 3

                                            That doesn’t bring any security though: it may give you a bit of safety, catching bugs earlier than in some other script languages.

                                            1. 6

                                              What would bring any security then, as opposed to just helping catch bugs? Barring “legitimate” cases of correct algorithms outliving their usefulness (e.g. the math behind crypto algorithms getting “cracked” to the point where it’s feasible to mount attacks on reasonably-priced hardware) virtually all security issues are bugs. Things like shell injections are pretty easy to miss when writing shell code, no matter how careful you are.

                                              1. 1

                                                Probably the taint mode that the other commenter mentioned

                                                1. 3

                                                  But that’s exactly what taint checking does: it helps you catch bugs that occur due to executing stuff that’s under the user’s control. Some of these can be exploited for security reasons, but security isn’t the only reason why you want this – it’s just as good at preventing a user enumeration attack as it is at preventing accidental “rm -rf /”

                                              2. 2

                                                I thought the same. I figure the OpenBSD people know what they are talking about but I am still not really clear on what Perl has over Tcl, for example. Hopefully a Perl monk will show up and clarify.

                                          1. 9

                                            you need something under and acceptable licence, so python is out.

                                            What’s wrong with python’s license? This is the first time I’ve heard anyone say there’s issues with it.

                                            Also, I think he forgot to mention Rust. Must definitely rewrite everything in Rust. /s

                                            1. 2

                                              Marc Espie elaborates a bit on this in another post on the openbsd-misc mailing list:

                                              As for the license, python’s license appears fairly similar to Perl’s artistic license. I would worry a bit about the strong terms in

                                              1. This License Agreement will automatically terminate upon a material breach of its terms and conditions.

                                              for which no equivalent is visible in Perl’s license.

                                                1. 12

                                                  That was fixed in Python 2.0.1, released in June 2001…

                                              1. 1

                                                Are you sure you want to be handling passwords yourself? Shouldn’t you be using a third-party authentication provider? That way, you run no risk of getting compromised and leaking (reused) passwords.

                                                1. 11

                                                  Handling passwords is really not that complicated. There are libraries around to do it, and quite frankly, it’s not magic. Just use bcrypt or something similar.

                                                  1. 2

                                                    I would note that it’s not so much just the handling of passwords, but getting all of the workflows for authentication and session management right too. That’s why I like libraries like Devise for Rails that add the full set of workflows and DB columns already using all best-practices to your application, with appropriate hooks for customization as needed.

                                                    1. 2

                                                      It’s not only the password in the database, but also the password in transit. For example, Twitter managed to log passwords:

                                                      Due to a bug, passwords were written to an internal log before completing the hashing process.

                                                      The risk remains, it’s just more subtle and in places you might not immediately think of instead.

                                                      1. 3

                                                        If anything that’s an argument against “just let someone else do it”.

                                                        You can review your own systems, you can organise an audit for them.

                                                        How do you plan to review Twitter’s processes to ensure they do it securely, given that they already have precedence for screwing the pooch in this domain?

                                                        1. 1

                                                          It’s easier in smaller systems.

                                                          1. 1

                                                            Well, there’s a risk with anything you do when dealing with secrets; you can leak tokens or whatnot when using external services too.

                                                            As I mentioned in another comment, the self-host use case makes “just use an external service” a lot harder. It’s not impossible, but I went out of my way to make self-hosting as easy as possible; this is why it can use both SQLite and PostgreSQL for example, so you don’t need to set up a PostgreSQL server.

                                                        2. 2

                                                          you run no risk of getting compromised and leaking (reused) passwords

                                                          You still have to handle authentication correctly, and sometimes having an external system to reason about can expose other bugs in your system.

                                                          I recall wiring up Google SSO on an app a few years ago and thinking configuring google to only allow people through who were on our domain was sufficient to stop anyone being able to sign in with a google account. Turns out in certain situations you could authenticate to that part of the app using a google account that wasn’t in our domain (we also had Google SSO for anyone in the same application, albeit at a different path.) Ended up having to check the domain of the user before we accepted their authentication from google, even though google was telling us they’d authenticated successfully as part of our domain.

                                                          1. 1

                                                            If password hashing is a hard task for your project, I’d argue that’s because your language of choice is severely lacking. In most languages or libraries (where it isn’t part of the stdlib) it should be one function call to hash a new password, or a different single function call to compare an existing hash to a provided password.

                                                            This idea that password hashing is hard and thus “we should use X service for auth” has never made any sense to me, and I don’t quite understand why it persists.

                                                            I have never written a line of Go in my life, but it took me longer to find out that the author’s project is written in Go, than it did for me to find a standard Go module providing bcrypt password hashing and comparison.

                                                            1. 1

                                                              And salting! So many of these libraries store the salt as part of the hash, making comparison easy but breaking hard.

                                                              1. 1

                                                                I would consider it a bug for a library/function to (a) require the developer to provide the salt, or (b) not include the salt in the resulting string.

                                                            2. 1

                                                              Problem is what provider do you choose to use? Do you just go and “support everyone”, or do you choose one that you hope all your users use, and that you are in support of (I don’t support nor have accounts at Facebook, Twitter, and Google), which narrows it down quite a bit. And what about those potential users that aren’t using your chosen platform(s)? Are you gonna provide password-based login as an alternative?

                                                            1. 4

                                                              An actual in-progress rewrite in Rust of GNU coreutils (obviously, GNU != POSIX, but evidently the world has just stopped caring about anything that isn’t GNU on Linux anyway, much to my personal dismay) can be found at https://github.com/uutils/coreutils

                                                              1. 2

                                                                Back in 2017, I wondered if Twitter’s alt text could be (ab)used to store message metadata like a PGP signature. Sadly, the limit was 420 characters per image.

                                                                For the reference: A detached signify/minisign signature even with an untrusted comment is only “untrusted comment: verify with [public key file name]\n[100 char base 64]”.

                                                                1. 1

                                                                  I was testing minisign for this earlier and I got ~290 character output. signify did give me 140 character output though.

                                                                1. 3

                                                                  +1 for the tag. Mainly so that i can filter it because I’m not interested in it.

                                                                  1. 4

                                                                    I bet there will be companies offering a “Python 2 LTS” which will have bugfixes and security updates for years to come, similar to what railslts.com does for Ruby on Rails 2. Actually, looks like ActivePython is already planning to do this.

                                                                    I don’t think that’s a bad thing. If you have an existing Python 2 codebase you invested a lot of money in and that works well, then updating to Python 3 could be a costly and risky operation. Especially if the codebase isn’t being developed very actively then it would be an extremely poor ROI. Don’t fix it if it ain’t broken and all that.

                                                                    I think this would be a good opportunity for the Python Foundation to raise money, although the community probably wouldn’t be too happy about a subscriber-only Python 2 (so ActivePython steps in and does it, which seems like a worse option to me for Python).

                                                                    1. 2

                                                                      There’s a limit of how far you can go with that, however; backporting Python 3 and calling it Python 2.8 will likely paint a target on you for a trademark lawsuit. Keeping it maintained forever, however, might fly. That’s definitely something that’ll (also) need to be figured out with the Python trademark holder though.

                                                                      1. 4

                                                                        ActivePython has been around for ages though, so I assume it’s okay with the FSF trademark-wise (ActivePython is a trademark on its own). Reading through that article and the GitHub issue, it seems the main issue people have is that “Python 2.8” could cause confusion that it’s an “official” Python release, which strikes me as a fairly reasonable concern.

                                                                        1. 3

                                                                          I can’t speak for the PSF (which holds the trademark for Python).

                                                                          However, I’ve been heavily involved in the Django project for many years. And there have been multiple efforts – some commercial, some not – over Django’s history to provide extended support for older versions EOL’d by the Django developers. Generally the only obstacle to overcome there is the name: Django’s trademark policy, for example, allows the use of the name “Django” in projects that distribute under an OSI-approved open-source license, but does not allow the use of the name for commercial products (or in the name of a company).

                                                                          I know of at least one entity currently offering paid extended security support for EOL’d versions of Django. Way way back in the day I used to help maintain an extended-support branch that also included non-security bugfixes for Django 0.91 (people wanted extended support of Django 0.91 because it was the last version with the original Django ORM – 0.95 completely rewrote it and in the process changed a ton of APIs, and Django was already popular enough at that point for it to be a problem).

                                                                      1. 18

                                                                        Not the most important points, but I spotted even more mistakes in the criticised “Why not WireGuard” post. This paragraph specifically is full of approximation & minor errors:

                                                                        ChaCha20 is a stream cipher which are easier to implement in software. They encrypt one bit at a time. Block ciphers like AES encrypt a block of 128 bits at a time. That would need many more transistors when implemented in hardware, so larger processors come with AES-NI - an instruction set extension that performs some tasks of the encryption process to speed it up.

                                                                        Let’s break it down piece by piece:

                                                                        • ChaCha20 is a stream cipher. It is. No error there.
                                                                        • which are easier to implement in software. This strongly suggests stream cipher in general are easier to implement in software. This is false. What makes Chacha20 easy to implement in software is its RAX (Rotate, Add, Xor) design, which (i) exclusively relies on widely available CPU instructions, and (ii) is naturally constant time on those CPUs.
                                                                        • They encrypt one bit at a time. An easy approximation to make, but no. Stream ciphers are deterministic random number generators, that generate an (almost) arbitrary amount of random bytes, which you can then simply XOR with the plaintext message. You can indeed cut the stream at any one bit. But the stream is not, in general, generated one bit at a time (or even one byte at a time). A Chacha20 block is 512 bits (64 bytes), and Chacha20 will generate the stream 512 bits at a time. Moreover, actual implementations often use vector units, and thus process 4, 8, or even 16 blocks at a time. Such meta-blocks can go up to a kilobyte.
                                                                        • Block ciphers like AES encrypt a block of 128 bits at a time. Okay.
                                                                        • That would need many more transistors when implemented in hardware, No. If I recall correctly, AES was selected for its hardware performance. Even if it required more hardware than Chacha20, this has little to do with the block size: Chacha20’s blocks are 4 times bigger, remember? And if I were to implement Chacha20 on hardware, I would likely use 16 adders instead of just one so I can parallelise the core loop (and that’s before I even consider processing several blocks in parallel). I can’t say for sure, but I currently guess that efficient AES hardware may require less transistors.
                                                                        • so larger processors come with AES-NI - an instruction set extension that performs some tasks of the encryption process to speed it up. Well, first, thank you for providing this email from Chacha20 designer, that note that Chacha20 also benefit from hardware accelerators: vector units. Which makes it perform well within a factor of 2 of AES in most cases. The reason we need AES-NI is not just speed, it’s timing attacks. Naive optimised implementations are prone to easily exploitable timing attacks even across the network. Implementing AES in a constant time manner without loosing too much speed is hard: bit slice implementations are no picnic. (And of course Chacha20 blows bit sliced AES out of the water).
                                                                        1. 2

                                                                          Block ciphers like AES encrypt a block of 128 bits at a time. Okay.

                                                                          If we’re nitpicking here, then that’s not okay: A block cipher just has a fixed block size that should be at least 128 bits, but the block size varies between ciphers. For example, DES and SKIPJACK had 64-bit block sizes, SPECK has a 64-bit block size specification, and then there’s Threefish which can go up to 1024-bit block sizes (but I think it’s only ever used as an internal part of the Skein hash).


                                                                          AES rant inbound:

                                                                          That would need many more transistors when implemented in hardware, No. If I recall correctly, AES was selected for its hardware performance.

                                                                          According to Report on the Development of the Advanced Encryption Standard (AES) on p. 53:

                                                                          Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael’s very low memory requirements make it very well suited for restricted-space environments, in which it also demonstrates excellent performance. Rijndael’s operations are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael’s performance. Rijndael is designed with some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require further study and are not being considered at this time. Finally, Rijndael’s internal round structure appears to have good potential to benefit from instruction-level parallelism.

                                                                          Interestingly, p. 50 gives Twofish shit because it uses addition (though it also used an S-box), which is “somewhat difficult to defend against timing attacks and power analysis attacks”. I’m not sold on the timing attack part outside dedicated hardware implementations, but the power analysis part definitely got a point there.

                                                                          Going back to p. 39, table lookups were declared “not vulnerable to timing attacks”, which suggests that timing attacks in software were not on NIST’s radar at the time, but they seemed to at least eyeball software implementations as well given that they looked into “instruction-level parallelism”. You’re probably right when you say they focused on hardware implementations though.

                                                                          1. 2

                                                                            Thank you for the corrections.

                                                                            This report puzzles me, especially this idea that there would be no software implementation. Even if you could expect hardware support soon after the adoption of the standard, we could imagine partial support that doesn’t touch the cache (and in particular doesn’t force the look up table to stay in L1 cache).

                                                                            Addition is constant time in most CPUs, but it is harder to have it resist power analysis. In general, carry propagation means addition is not very energy efficient. Overall, addition is excellent in software, crappy in hardware. Chacha20 was optimised for software, so…

                                                                            My own opinion of AES: the s-box was a bad idea, and AES is obsolete because of it. It’s just too easy, too tempting, to write software that’s vulnerable to cache timing attacks. More generally, new general purpose ciphers today should probably not ignore software implementations. Though I confess hardware-only solutions like Keccack do have their appeal in some settings, and hybrid solutions like Gimli aren’t quite there yet.

                                                                            1. 1

                                                                              My understanding is as follows:

                                                                              1. Dedicated hardware implementations will always beat out cipher implementations in software in terms of speed. If a primitive becomes ubiquitous, Intel, AMD and ARM will add dedicated instructions anyway, making software performance on non-embedded irrelevant. (Ubiquity is only evaluated for the West, no matter how much SM and GOST standards may be used in China and Russia, respectively, because the relevant chipmakers are all U.S. companies and thus appear to care little for Chinese and Russian standards.)
                                                                              2. There will always be demand for fast software-only ciphers in embedded because (1) is difficult and/or expensive. And there’s a niche of people who are portability snobs who refuse the idea that source code should be platform-dependent even in the face of significantly better performance numbers.
                                                                              3. The two camps cannot unite unless either (a) everyone agrees on a magical threshold of accepting a certain penalty and somehow getting the required speed on ARM and x86, (b) someone comes up with an ingenious cipher design that is both easily expressible in hardware and software, yet arrives at the same result, at approximately equal speeds.

                                                                              Therefore, AES cannot become obsolete unless it is badly broken: New competitions would focus at least partially on software as well, which causes a design that only evaluates hardware performance to never be adopted as a standard, which it would have to become ubiquitous, which it would have to be in order to be adopted as a primitive added to the instruction sets of x86 and ARM.

                                                                        1. 1

                                                                          OP, since you seem to be the author: Is it just me or is the TLS certificate on the website expired?

                                                                          1. 1

                                                                            I get the same message. Certificate issued by Amazon, expired 2020-04-26 @hwayne.

                                                                            1. 1

                                                                              Ugh, this is weird. Amazon is saying that both certifications were renewed on 2020-04-20. But the old certificates expired two days ago. Is there some way to “refresh your cache”? I don’t know certificates very well :(

                                                                              1. 1

                                                                                I had the issue the first time I opened the article, but it’s gone now.

                                                                                1. 1

                                                                                  Clearing the cache of my browser (Firefox, macOS) did the job for me (actually I just opened the devtools, checked “disable cache”, refreshed the page, closed devtools pane and that’s it because I’m a browser nerd).

                                                                            1. 5

                                                                              I’m polishing Monokex, a Noise fork. The advantages over Noise are:

                                                                              • It’s even simpler (Noise is close to maximum simplicity already).
                                                                              • It supports Elligator, so handshakes are fully indistinguishable from random. (For censorship circumvention, plausible deniability, minimising metadata leaks…)
                                                                              1. 1

                                                                                Do you mean https://noiseprotocol.org/? Your link to https://noiseprotocol.com/ seems dead.

                                                                                1. 2

                                                                                  Oops, my bad. Edited, thanks.

                                                                                2. 1

                                                                                  “working C code”

                                                                                  I like that part. I thought it would be great for someone to port Noise to a safer language or at least one with tons of analyzers/testers. C++ is incredibly hard to analyze.

                                                                                  1. 1

                                                                                    Honestly, much could be gained for Noise if you could somehow compress the spec some more so you don’t have to be deeply into it before it starts making sense, like getting the central ideas out early on and giving a concrete example rundown of one protocol for illustration, perhaps. The PURB paper actually did a fantastic job building up to the whole protocol and it really helped understanding along.

                                                                                    1. 1

                                                                                      I’m not sure we can compress the Noise specs. We could have the Noise Explorer or equivalent write specific specs for any given pattern, though. In general, though, Noise does have some avoidable complexity:

                                                                                      • It has two separate tracks of hash mixing: one for the transcript, and one for keys. I believe the idea is to avoid potential information flow from secrets to public output. In my opinion, this precaution is overkill.
                                                                                      • It uses both HMAC (transcript hashing) and HKDF (key derivation), which are overkill with modern hashes like Blake2 or SHA-3. And even with SHA-2, HMAC is enough.
                                                                                      • It uses a separate AEAD scheme to encrypt data, in addition to mixing it into the hash. With a single track that mixes transcript and keys together, we could just derive a MAC from the hash after mixing.
                                                                                      • It handles the symmetric session after the handshake, instead of just returning a session key. I believe the symmetric session is simple enough that we can handle it separately.

                                                                                      Okay, the last point isn’t really fair. The first three however probably makes Noise about twice as big as it needs to be. There’s room for simplification, even without going all the way to Disco: we just need a cipher, a hash, and key exchange (and an authenticator for the symmetric session afterwards, but we can use the hash to do that).

                                                                                      And if you don’t need to handle arbitrarily long payloads, there’s even a way to use Chacha20 to perform key derivation (though the exact security properties are more fiddly than that of a regular hash).