zimmerfrei

Yes, and it didn't go unnoticed that KangarooTwelve (which - mind - does not belong to the SHA-3 family right now) is not included on that prominent comparison diagram, while it is considered in the BLAKE3 paper.

This is a bit pointless, since it does not say on which platform the comparison is made.

In any case, KangarooTwelve [1][2] (on AVX-512) is also 10x faster than SHA-256.

KangarooTwelve is a fast hash function of the Keccak family (from which the SHA-3 derives from), and it is clearly what BLAKE3 tries to catch up with.

However, KangarooTwelve probably benefits from the more extensive scrutiny that SHA-3 has received and will receive, and (from a performance standpoint) from future HW extensions that will speed it up even more (the first one appeared on ARMv8.2).

[1] https://keccak.team/files/KangarooTwelve.pdf

[2] https://www.cryptologie.net/article/393/kangarootwelve/

Will the GDPR kick in?

The keyword is "center" (though something may have been lost in translation): the same treaty conditions against double taxation exist between other EU countries and what matters is always what is the country you have the tightest relationship with.

Sending home money is definetly secondary compared to pay for bills, rent, groceries, etc in the country you are actually living in.

Are SIM-based IoT devices at risk too? Say a connected car?

>> And pyca/cryptography instead of something terrible like pycryptodome!

pycrypto is terrible. The pycryptodome fork fixes most problems in it.

Also, maybe worth sharing you are listed as fourth contributor [1] to the cryptography library, and your web book is prominent on the project homepage, so this piece of opinion may be biased.

>> Concrete suggestion: use Fernet

Please don't. Don't use boutique protocols with informal specs and without test vectors generated by a sufficient number of independent implementations. Stick to RFC-backed protocols. Use JWT with rigid parameters. Even other cryptography author states that just supporting JWT and not Fernet would have been better [2].

[1] https://github.com/pyca/cryptography/blob/master/AUTHORS.rst

[2] https://github.com/pyca/cryptography/issues/2900

Is there any?

>> Firstly, GHASH is replaced with POLYVAL, a hash that is almost exactly the same but reverses the order of some bytes because it turns out that's more efficient on most platforms.

The GHASH/GCM bit twiddling is so awful and slow and side-channel insecure to do in software, that most people just blindly copy the obscure code full of clever optimization that smart specialists come up with [1].

Then other smart specialists [2] have to reverse engineer said clever tricks (now widely used everywhere), because no explanation exists and it is not clear why they work in the first place.

Once done, a third group of smart specialists tweak the algorithm in an incompatible way to gain 10% speed on specific platforms and forcing people to pull in even more obscure code.

Simply put, I wish AES-GCM-SIV had just used GHASH as GCM and helped keeping complexity of crypto libraries down...

[1] https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pd... [2] https://blog.quarkslab.com/reversing-a-finite-field-multipli...

>> All Android devices certified by Google will have a hardware security module which should keep the keys secure.

Source? I understood that having a HW-backed key store is still entirely optional for the purpose of Android certification.

On top of that, I noticed some ambiguity on whether a TEE like ARM TrustZone qualifies as a hardware-grade protection mechanism in the same way a discrete and dedicated crypto processor is (I think the two technologies provide very different assurance levels).

That sounds like bad software engineering to most, but if each OpenSSL copy was actually in a separate Docker image, reactions would suddenly be much milder I suspect.

One reason this cannot be translated into a portable C version while retaining its compactness (and readability) is the lack of support for carry/borrow chains.

In Go, bits.Add64 takes as input and returns the carry.

In C, there are some constructs that modern compilers will recognize as patterns people use to extract the carry, but it is a hit-and-miss.

Even compiler-specific intrinsics are a few and far between, inefficient or even broken.

You have just described IRMA (I Reveal My Attributes) which is an experimental non-profit implementation of a subset of Idemix, a type of ABC (attribute-based credentials) system:

https://privacybydesign.foundation/irma-en/

https://privacybydesign.foundation/irma-explanation/

https://petsymposium.org/2017/papers/hotpets/irma-hotpets.pd...

edit: links

>> also, no mention of masking techniques!

> Out of scope. Those are hidden behind magical constant time routines.

How is that? Side-channel resistance is largely a matter of reducing the Signal-to-Noise ratio for traces an attacker can leverage to extract secrets. A constant-time logic reduces the Signal; a masking logic increases the noises. The two are largely independent and at times at odds. For instance, recent fast curves (like DJB's) are good because they can be easily implemented in constant time in software (as far as we know) but they are actually much harder to mask (in software or hardware).

There should some warning note right at the top, given the topic is presented mainly for cryptographic purposes.

There is a huge body of quite diverse side channel attacks against all of these "fast" techniques for scalar multiplication, and the article is too weakly making references to pitfalls for each approach and the importance of constant time logic (also, no mention of masking techniques! Though those are routinely overlooked by way too many speed-obsessed practitioners).

>> - It lets you extract the sealing key and remote attestation. That's about as bad as it gets.

It could have definitely been worse, with the leak of the fused secrets or a breach to integrity of the microcode (the two things that together constitute the TCB, which put simply is the only piece of the system you assume will never be broken).

All in all, assuming a microcode update can counter the attack as Intel claims, sealing and attestation secrets will be rekeyed via the KDF rooted in the fused keys, so that you can start afresh.

Of course, operationally speaking, that is a total pain but it is frankly remarkable to see this kind of deep recovery strategy finally built into consumer devices (and yes, I know DRM is unfortunately the main driver, but there are still some very legitimate use cases).

>> flush L1d (or prevent things from accessing the same L1d via e.g. core pinning) and you're fine

No, you are not fine. As the paper explains, an adversary (which is by definition more privileged than you are) can operate between the moment you use secrets in L1 and the moment you flush them out. Only the CPU (silicon or microcode) can assist you in the flushing of L1 when you exit enclave mode.

Interestingly, the upcoming CPUs with built-in resistance to Meltdown (new MSR bit RDCL_NO set to 1) will also be immune to L1TF already.

I think that is mostly the case for BIOS and platform firmware. CPU microcode can be loaded by the OS (if the OS allows you to, as Linux does - https://www.cyberciti.biz/faq/install-update-intel-microcode...).

That enables mutually-authenticated TLS connections between servers.

>> Disney can probably copy what Netflix has today, but by the time they’ve done that, Netflix will have updated their platform hundreds of time

Last year Disney acquired BAMTech (a spun of MLB Media) - though less known, their technical chops when it comes to video streaming are already in Netflix territory.

https://www.theverge.com/2015/8/4/9090897/mlb-bam-live-strea...

On the same topic, PyPI has recently moved to a new backend, and in the process all end-to-end PGP signatures (created by the package owner upstream, proving that no tampering happened on the online servers) have disappeared from the UI, and that is seen as a "feature":

https://github.com/pypa/warehouse/issues/3356

You can still get them through some obscure API and you still need to know the right PGP key for verification, but this really signals the lack of consensus and awareness on the path toward a secure software supply chain.

EDIT: typos

The European Commission is actually trying to address that problem right now, at least for high-performance computing (which includes autonomous cars):

https://ec.europa.eu/digital-single-market/en/news/european-...

A budget of 120 million euros is quite low though.

My comment is no more speculative than those blaming the new microcode for causing reboots. The real bad quality, bad update process and unjustified binary nature of OEM firmware is too often overlooked.

To be fair, it can well be that some sloppy OEM drivers take too many assumptions on reserved bits in registers (which the new microcode may be legitimately changing) or on undocumented timing side-effects related to some instructions (which the new microcode may affect, being that the root problem in the first place!).

These symptoms are also the classic ones you get when you install an OS on a new-generation, well-functioning CPU.

In the simplest Meltdown case, the offending instruction is really executed and a General Protection Fault occurs. That is handled in the kernel which at that point could (simply?) flush all caches to remove the leaked information.

The real problem with Meltdown seems to occur when: 1) The offending instruction is NOT really executed because it is in a branch which is not actually taken. 2) The offending instruction is executed but within a transaction, which leads to an exception-free rollback (with leaked information left in cache though).

AFAIK neither is (or can be made) visible to the kernel (which could explain the very large PTI patch), but I do wonder if they are events that can be hanlded at the microcode level, in which case a microcode update from Intel could mitigate them.

The bug seems to be about the processor leaving speculatively read privileged data in some of the caches, even if execution failed [1].

If so, clearing all caches upon a failed privilege check sounds like something within the capabilities of microcode and without unreasonable performance penalties.

Unfortunately, that would not explain the complex in-kernel fix...

[1] https://plus.google.com/+KristianK%C3%B6hntopp/posts/Ep26AoA...

EDIT: what remains in cache is not "speculatively read privileged data" but more "unprivileged data whose address is correlated to speculatively read privileged data". Retrieving later such address allows one to infer what the privileged data was. Still, the point about clearing all caches as countermeasure holds...

It depends on how long it takes for Intel to go through all regression tests for all affected platforms. If it takes several months to complete, a countermeasure in the kernel update may still be the better stopgap.

Or maybe it could be that Intel privately disclosed already that no backport will be done to firmware of older CPUs, in which case the kernel update is the stopgap for newer generation and the solution for older generations.

Could this be possibly fixed with a microcode update in the future (at least for most recent models for which Intel is still bound to some kind of warranty)?

Not very long. Flip Feng Shui does exactly that: a malicious program in a VM can affect another one co-hosted in the same cloud server if the hypervisor uses deduplication:

https://www.vusec.net/projects/flip-feng-shui/

> LoRaWAN architecture, I learned every trick of one open source implementation[1]

> [1]: https://github.com/brocaar/loraserver

How does that compare to the TTN stack [2]? I thought that was the most popular choice by a large margin.

[2] https://github.com/TheThingsNetwork/ttn

Maybe I am being too harsh, but it is clear the author does not have a formal education in the subject [0] nor any track in breaking non-toy crypto implementations [1]. This alone makes me a bit wary of any recommendation one may read in the material.

There seems to be more attention to listing all the beasts in the cryptographic zoo than to the few fundamental tools required to really understand the mechanics (e.g. birthday paradox, PRFs, some prime number theory).

Sure, I can't spot anything fundamentally wrong and it all reads pretty smoothly, but calling this a "course" is highly misleading. If the intention is to guide people in selecting good crypto primitives, then maybe "guide" is a more honest word?

For those interested, I would strongly recommend to bite the bullet and dedicate time to Boneh's course on Coursera.

[0] I don't have any either [1] Ditto