1,137 karma · joined June 5, 2016
However if you want things toolkits don't provide then you need to talk to the underlying API yourself.
My distro ships both plain Firefox and firefox-wayland. I've been using it for... At least a year. No noticeable difference to normal Firefox.
However we do actually know quite a bit on how to design hash functions to make this hard to do in practice. The latest cryptanalysis (to actually find a collision) either requires a vastly reduced number of rounds or is is computationally infeasible. There's no clear flaw like there was with SHA1, where the path to finding a collision has been known since ~2004.
Length extension "attacks" sure, that's an unfortunate design choice. But it doesn't impact at all on collision resistance, which is what is implied by suggesting SHA1 is vulnerable then SHA2 is.
In the end, if you can use BLAKE3 or BLAKE2, great, I probably would as well. There isn't always a choice (e.g. there's no blake3 support in most crypto hardware) and if there isn't, sha3 or sha2 are fine choices.
> Unlike SHA-1, SHA-2 algorithms aren’t broken and are unlikely to ever be.
There's also the fact NIST themselves deprecated SHA-1 in 2011 (https://csrc.nist.gov/news/2017/research-results-on-sha-1-co... not mentioned, but otherwise nice timeline here: https://crypto.stackexchange.com/a/60655), yet SHA-2 is still OK. Wiki has a table of cryptanalysis of SHA-2: https://en.wikipedia.org/wiki/SHA-2#Cryptanalysis_and_valida...
The summary is that either you attack a very reduced round variant and you get "practical" complexity for the attack, or you attack almost a full round variant and you get an entirely practical attack.
So I think your interpretation of the subtext is entirely correct.
* SHA-2 fixes the problems with SHA-1. SHA-1 was a step up over SHA-0 that did not completely resolve flaws in SHA-0's design (SHA-0 was broken very quickly).
* JP Aumasson (one of the B3 authors) has said publicly a few times SHA-2 will never be broken: https://news.ycombinator.com/item?id=13733069 is an indirect source, can't seem to locate a direct one from Xitter (thanks Elon).
Thus it does not necessarily follow that SHA-2 is a bad choice because SHA-1 is broken.
Perhaps the best "big name" distrusted CA would be Symantec: https://blog.mozilla.org/security/2018/03/12/distrust-symant...
Others include WoSign and StartCom.
The problem with eIDAS is that browsers can no longer police these CAs, as they are legally mandated to carry them. There needs to be a mechanism whereby such a CA can be distrusted, doubly so if it is issuing "qualified" certificates (if it cannot get the basics right it should not attest to someone's legal identity).
On the flip side to this there is nothing stopping Europe distributing additional roots that install themselves in browsers. I work in finance and we operate several closed CAs. Our clients install our CAs all the time. It just would not be on by default nor pop up the EV bit.
But that does not stop the digital wallet software (the motivation for this) peering into the certificate itself and making sure it is a qualified certificate.
This is a very cool project, author, love it!
It's limited ports wise (has a single nvme slot, but a ton of networking) and if you want to use it for a desktop you need to replace the noisy fan that comes with it. But I can actually be done.
It's the only board I'm aware of though.
Foreign nationals don't meet the "Unquestioning loyalty to the US" criterion for security clearance, meaning it is much less likely they might collaborate willingly with the US. They're also less exposed to pressure from the US Government, especially if they are not resident/GC holders.
I personally think it is quite paranoid to assume that any US resident or national cryptographer is in cahoots with the NSA but if we are strictly considering risks, then this process is open to scrutiny by world-wide participants, many of whom may not sit on a vulnerability at the behest of the US GOV - actually, for many of them, finding such a vulnerability would likely mean a top tier paper at CRYPTO/EUROCRYPT probably with best paper awards and all the plaudits that make an academic career for life.
You can read the original report on the candidates: https://nvlpubs.nist.gov/nistpubs/jres/106/3/j63nec.pdf
To save you some time, one software evaluation is on page 531. Serpent performs worse in software than Rijndael (AES) just about everywhere (note they use categories rather than precise metrics, but you can dig into that if you want). By contrast, one hardware evaluation is on page 539. Serpent has the highest throughput for the lowest "area" i.e. required. These results repeat on p541.
So it depends on whether you are comparing a software or hardware implementation.
The evaluation criteria are, naturally, in a state of constant evaluation. It would make no sense to fix them in 2019, and never update them in response to research.
It seems that DJB is not necessarily representing what NIST is saying honestly with regards to security levels: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/4MBu... , https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/4MBu... - It also seems that the improved dual lattice attack from MATZOV (Israeli spooks) isn't actually as practical as thought: https://eprint.iacr.org/2023/302 (this paper was published in CRYPTO, which is purely run by academia, and top-tier academic at that). What actually the answer should be depends on various cost models, but the overall conclusion seems to be there is not a lot between Kyber and SNTRUP - on the other hand, it may be an open problem (https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/4iaf...).
Security bounds, however, are not the only reason to pick an algorithm. To take Curve25519, the prime order subgroup has order 2^252 + a bit, so it falls just short of the 128-bit security level. Should we reject it for this? Absolutely not: X25519 is excellent from an implementation perspective. This is more qualitative than quantitative, but such considerations also count.
Pointing out further notes by Peikert on SNTRUP, here is a detailed risk analysis: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/G0Do... with responses from others: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/G0Do... - to summarize: a) it seems the patent risk of Kyber might also apply to SNTRUP, and b) SNTRUP makes modifications over plain NTRU that are not clear. DJB also tried to argue against Kyber's performance: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/ik1p... . It is not clear that SNTRUP is necessarily a better choice either; quoting directly from NIST IR 8413 (note that the SIKE section is out of date; SIKE is definitively broken pre-quantum now):
> The current version of NTRU Prime has performance and concrete security estimates > (e.g., quantitative estimates of the computational resources required for usage and > cryptanalysis) that are roughly comparable to other lattice-based cryptosystems.13 As a > result, the current version of NTRU Prime is notable more for its unusual design features, > and claims that it offers higher security in a qualitative sense. > > One particular issue is the choice of the NTRU Prime ring (rather than a cyclotomic > ring), which is claimed to eliminate the possibility of certain kinds of algebraic attacks. > To date, most work on the cryptanalysis of algebraically structured lattices (see Appendix > C) has focused on cyclotomic rings, because they are widely used and simpler to analyze. > Relatively little is known about the security of cryptographic schemes that use the NTRU > Prime ring.
As for the involvement of NSA employees - they show up to NIST forums on standardization and take part in the process, and if you go, it isn't exactly hard to work out who they are. NSA also has an information assurance mission. If we take what is said in https://www.youtube.com/watch?v=qq-LCyRp6bU (Richard George, an NSA targeting retrospective) to be accurate then NSA Suite-A are almost drop-in replacements for NSA Suite-B (the algorithms mandated for use across US FedGov) so the NSA team have an interest in the outcome, because future choices of cryptography suites will follow on from what is standardized.
As for FOIA: if the NSA does know about a backdoor they don't think anyone else does, don't you think they'd classify it? Wouldn't that make it exempt from any FOIA lawsuit you care to raise? If we are attributing competence to them beyond what is available publicly, then surely they wouldn't be so careless as to discuss the backdoor they'd discovered in FOIA-able channels, would they?
I'm 100% for scrutinizing the process to make sure neither the NSA (nor anyone else) can sneak in a backdoor either deliberately or by allowing it to pass through unremarked. I am not convinced by DJB's writeup: I agree that NIST have a preference for Kyber, but I do not currently see any evidence that this is an unreasonable conclusion to arrive at, or that they have substantially ignored serious flaws in the design.
> Is NIST trying to derail his work by standardizing crappy algorithms with the help of the NSA? Who knows. But to me it does smell like that.
"Crappy" algorithms that were designed by well-regarded cryptographers, none of whom work for NIST or the NSA, many of whom are not US nationals.
BUT. On security margins, you could argue the Serpent designers were too conservative: https://eprint.iacr.org/2019/1492 It is also true that cryptanalytic attacks appear to fare slightly better against AES than Serpent. What does this mean? A brute force attack has the same number of operations as the claimed security level, say, 2^128 for 128-bit. An attack is something better than this: fewer operations. All of the attacks we know about achieve slightly less than this security level - which is nonetheless still impossible to do - but that comes at a cost: they need an infeasible amount of memory. In terms of numbers: 9000 TB to reduce 2^128 to 2^126 against full-round AES according to a quick check of wikipedia. For reference, the lightweight crypto competition considered 2^112 to be sufficient margin. 2^126 is still impossible.
In practice, the difference between Serpent and AES in terms of cryptanalytic security is meaningless. It is not an example of NIST picking a weaker algorithm deliberately, or I would argue, even unintentionally. It (AES) was faster when implemented in software for the 32-bit world that seemed to be the PC market at the time.
I'll believe he invented the term - I have a 2009 book so-named for which he was an editor surveying non-DLP/non-RSA algorithms. Still, the idea that he's "the only one who can produce the good algorithms" and literally everyone else on the pqc list (even if we subtract all the NIST people) is wrong is bonkers.
1) single-handedly killed US government crypto export restrictions - Bernstein certainly litigated, but was not the sole actor in this fight. For example, Phil Zimmerman, the author of PGP, published the source code of PGP as a book to work around US export laws, which undoubtedly helped highlight the futility of labelling open source software as a munition: https://en.wikipedia.org/wiki/Pretty_Good_Privacy#Criminal_i...
2) Bernstein "founded" the field of post quantum cryptography: Uh. Ok. That's not how academia works. Bernstein was certainly an organiser of the first international workshop on post quantum cryptography, but that's not the same as inventing a field. Many of the primitives that are now candidates were being published long before this, McEliece being one of the oldest, but even Atjai's lattice reductions go back to '97.
3) The dual_ec rng was backdoored (previously read was and is fishy, poor wording on my part), but nobody at the time wanted NIST to standardize it because it was a _poor PRNG anyway_: slow and unnecessarily complicated. Here is a patent from Scott Vanstone on using DUAL_EC for "key escrow" which is another way of saying "backdoor": https://patentimages.storage.googleapis.com/32/9b/73/fe5401e... - filed in 2006. In case you don't know Scott Vanstone, he's the founder of Certicom. So at least one person noticed. This was mentioned in a blog post as a result of the Snowden leaks working out how the backdoor happened: https://blog.0xbadc0de.be/archives/155
NSA have been caught in a poor attempt to sabotage a standard that nobody with half a brain would use. On the other hand NSA also designed SHA-2, which you are likely using right now, and I'm not aware of anyone with major concerns about it. When I say NSA designed it, I don't mean "input for a crypto competition" - a team from the NSA literally designed it and NIST standardized it, which is not the case for SHA-3, AES or the current PQC process.
DJB is a good cryptographer, better than me for sure. But he's not the only one - and some very smart, non-NSA, non-US-citizen cryptographers were involved in the design of Kyber, Dilithium, Falcon etc.
So I run my own email server for family (mostly) but a couple of friends. As the GP points out, the DKIM keys do not identify the user and in particular I can produce a validly signed email for any user of any of the domains my server hosts. Only CMS oblique S/MIME would provide non-repudiation in the cryptographic sense, and only meet e.g. eIDAS requirements if stored on a hardware token (i.e. in the EU, if I sign a PDF with the USB token I have, it is a "qualified signature" and it can be interpreted as legally binding).
On the other hand, there's a question as to what extent courts would understand the distinction between a valid and invalid/no DKIM signature. I guess what I'm saying is if it came down to a contractual dispute, "strong evidence" would not be good enough. If it came down to "this person organised a protest and that's a crime" I think even invalid DKIM would be fine. From what I've seen of court proceedings, mostly stuff shared here and so US stuff and not my native jurisdiction, but I have yet to see anyone cast doubt on an email's provenance based on DKIM. I'm going to go out on a limb and say in strongly democratic jurisdictions an email recovered from a server in someone else's inbox will likely be treated as valid unless there is something like an unusual sender IP to cast doubt on it. So "strong evidence of authenticity" probably won't come from DKIM.
In jurisdictions where protesting means you disappear, I doubt "check the DKIM keys!!!" is going to help - at least in part the police/courts might not be so worried about whether you are guilty or not.
Agree completely with the sibling comment that e-mail isn't suitable for secure messaging.
It's the same for the Talos II using IBM's POWER. It costs a lot because a) it is designed as a workstation and b) the volume just isn't there.
Economies of scale basically.
The COD book I recommended was recommended to me by an EE undergrad who took it on one of their courses, and I think it is suitable as an introduction to how computers actually work, with plenty of real-world examples and mentions of architecture features that indicate specific tradeoffs. Of course, whether that is suitable is really going to depend on the person reading it.
The Packt book looks like it might be attempting to do the same thing - except I am slightly worried it likely digresses a bit into virtualization, self driving cars and quantum computers (based on the Packt TOC and github repo). I'm going to say this is scope creep - I don't know how deep it goes into virtualization, but personally I think understanding how x86 does virtualization is much less useful than understanding the wider problem of how to partition hardware. If it doesn't say LPAR somewhere in there or discuss mainframes, I'd be disappointed. Self-driving cars do not, in my opinion, belong in a book on how modern computers work, and I'm not sure the author's experiments with IBM's quantum computer cloud thingabob are really what I want out of such a book either.
That said, I've not read the Packt book and I can't say anything about the earlier content. I have read the COD book - but I wish I'd come across it earlier than I did. Still, I got something out of it.
Some graduate textbooks are highly specialized and for niche fields - my formal education is in mathematics and I can definitely say this about some graduate maths books - but this is not one of them. I think it is widely applicable to anyone who a) wants an introduction to how computers do their stuff or b) already broadly knows, but has some gaps and wants to fill them in.
It isn't like the average hard disk permits padding oracles and chosen plaintext/ciphertext attacks to be mounted easily, except of course if you are storing disk images in the cloud, but then you're using the wrong tool anyhow - do crypto at the file level where you aren't constrained by sector sizes.
Thing is, pkg-config would've picked up the dependencies just fine - they were literally all there. I even built Rust from source on my weird machine with musl variant, before realising musl has some issues on my architecture.
I suspect Bazel may work well inside of Google for infra/server side stuff (never worked there). I'm a lot more skeptical of more complex builds, like desktop applications across various platforms. Chrome still uses "gn" to generate ninja files, and then ninja to build. For my own stuff, I won't touch it.
I probably wouldn't have commented, except that, to my surprise it seems the Anki developers have also decided life is too short https://github.com/ankitects/anki/commit/5e0a761b875fff4c9e4...
> Apparently everything online about how operating systems and CPUs work is terrible.
Unfortunately finding good information is not easy, but it is out there - you've proven it by synthesizing some of that hard to find information into a better form. My degree is in mathematics, but my computing knowledge is self taught. Knowing how to learn in this way and to be able to communicate highly technical information in an approachable manner are incredibly important skills and not to be underestimated.
I have two links to share - I limited myself to two because we could be here a long time otherwise:
1. https://git.lain.faith/sys64738/airs-notes.git (TOC for linker part here: https://lwn.net/Articles/276782/) - you've scratched the surface of ELFs and linking. This is a 20-article blog series by Ian Lance Taylor plus miscellaneous extra topics containing everything you ever wanted to know about ELFs and quite a bit that will likely make you wonder how any of your commands are actually even working! There's even a brief mention of ELF's companion, DWARF, which amongst other things is a virtual machine used every time a C++ exception is triggered.
2. Have you seen this excellent project? https://0xax.gitbooks.io/linux-insides/content/ - essentially a human-readable walkthrough of how the Linux kernel does stuff. Has almost certainly been shared on HN before.
The previous Labour government (1997-2010) introduced the Regulation of Investigatory Powers Act 2000 (https://en.m.wikipedia.org/wiki/Regulation_of_Investigatory_...), which amongst other provisions includes key disclosure rules (https://en.m.wikipedia.org/wiki/Key_disclosure_law#United_Ki...). The burden of proof in key disclosure is inverted (the accused must prove non-possession of the key or inability to decrypt), which was somewhat controversial amongst people who cared at the time (activation, i.e. actual use if RIPA III provisions, began in 2007).
The same Labour Government ran the Interception Modernisation Programme (https://en.m.wikipedia.org/wiki/Interception_Modernisation_P...) (you may recognise this or "mastering the internet" from the Snowden leaks, although IMP was not a secret) and proposed legislation to enact part of it: https://en.m.wikipedia.org/wiki/Communications_Data_Bill_200.... This never made it into law.
I think Labour are on board with this, and the senior civil service (those at the top levels who work with ministers or close to those who do) don't change in the same way US administrations do. It might be the case that this bill runs out of time in the current parliament and is not picked up by the next government (this can happen even if the same political party holds office) but the idea will be back in some form one way or another and I suspect will make it into law.
I was slightly confused when I first read the title as well :)
> The AEADs defined in this document calculate fresh AES keys for each nonce.
I guess write an RFC for extended nonce only?