galadran

In effect, yes it does.

The Recommended flag is set for X25519MLKEM768. It is not set for any of the pure PQ key exchanges.

https://www.iana.org/assignments/tls-parameters/tls-paramete...

I'm afraid you've misunderstood. These codepoints are for the pure MLKEM key establishment that DJB is railing against.

All of these libraries also support the hybrid forms, which have different codepoints and are used by default. Nothing in the IETF process has any bearing on this.

This is garbage from start to finish.

There are already codepoints assigned for MLKEM 512/768/1024 (0x0200, 0x0201, 0x0202) and nearly every major library supports it already:

  - OpenSSL (ML-KEM-512/768/1024)
  - BoringSSL (ML-KEM-1024)
  - NSS (ML-KEM-1024)
  - AWS-LC (ML-KEM-512/768/1024)
  - Rustls (ML-KEM-768/1024)
  - s2n-tls (ML-KEM-1024)
  - Bouncy Castle (ML-KEM-512/768/1024)
  - Botan (ML-KEM-512/768/1024)
  - GnuTLS (ML-KEM-768/1024)
  - WolfSSL (ML-KEM-512/768/1024)

If nothing changes, users will increasingly be forced to choose between their privacy and their access to the web

Shorter post: https://blog.mozilla.org/en/privacy-security/keeping-the-web...

More details: https://blog.mozilla.org/en/privacy-security/keeping-the-web...

EU Commission FAQ (emphasis mine):

Recognition means that web browsers are required to ensure support and interoperability for the QWAC for the sole purpose of displaying identity data in a user-friendly manner. *Recognition of QWACs implies that browsers shouldn't question the origin, integrity or data in the certificate*.

However, the requirement to recognise QWACs does not affect browser security policies and leaves web browsers free to preserve their own procedures and criteria for encryption and authentication of *other certificates*.

https://ec.europa.eu/commission/presscorner/detail/en/QANDA_...

As I commented there, you've misunderstood this change.

There's a difference between certificates distributed with the OS and certificates added to the OS by a user. Right now Firefox ignores both.

This change ONLY picks up the certificates added to the OS by a user. Firefox will continue to ignore the certificates included with the OS store by default.

There's a difference between certificates distributed with the OS and certificates added to the OS by a user. Right now Firefox ignores both. This change ONLY picks up the certificates added to the OS by a user.

"Agreed behind closed doors" would probably be better than "Secret Law" but I guess its a question of brevity.

https://en.wikipedia.org/wiki/Formal_trilogue_meeting

https://eidas-open-letter.org

The open letter signed by 300+ researchers, professors and experts.

Title should probably be: "Last Chance to fix eIDAS: Secret EU law threatens Internet security"

https://last-chance-for-eidas.org/

This isn't the right summary. Firefox uses it own root store still and ignores any certificates distributed by default in the OS. However, if the user installs their root to the OS, Firefox will also pick it up. This is how other browsers work.

Mozilla's launch earlier this week: https://blog.mozilla.org/en/products/firefox/encrypted-hello...

I believe CF and others buckled under pressure from major websites which didn't want to be used as fronts for other website's traffic. ECH fixes this because individual sites get to opt-in to using it.

Any provider can deploy ECH, it's standardized at the IETF. Cloudflare are just first.

The point is that network operators can't tell which website the user is visiting, as it could be any of the sites hosted by the ECH provider.

In this case, Cloudflare are acting as the ECH provider and as they already host the websites, they already see the connection plaintext.

The disclosure and test cases: https://www.openwall.com/lists/oss-security/2021/12/01/4

More details: https://www.openwall.com/lists/oss-security/2021/12/01/4

It is not fun but frustrating to work in Rust.

Deeply subjective. Rust has been the most loved language on Stack Overflow for 5 years in a row now.

add a new huge dependency

Sure, but setting up Rust is much much easier than GCC with all the trimmings.

As an exemple, there is a common package in python that decided to start having their module in Rust instead of C. Now a lot of users of the module are pissed off, with good reason, because you can't build/install the module anymore in a little bit older or non conventional distributions.

Assuming you are referring to pyca, you are mistaken and there has been a lot of misinformation about the change. Rust support is needed to build the module, but not install it. Pyca works just fine for users without rust and works everywhere rust does. Users on niche CPU architectures which haven't been sold commercially for 15+ years were the only ones impacted.

1. Of the literally hundreds of maps on his site, there are only two which are actually based on Middle Earth.

2. 'Style' is not copyrightable. No one owes royalties to Picasso for Cubism.

3. Plagiarism is representing someone else's work as your own. The tag line of his site is literally "Tolkien Inspired Cartography". He's very clear that he's following Tolkien's style.

4. Tolkien borrowed from previous cartographers, his own style evolved considerably over time and what you probably think of as the iconic Tolkien map, was actually by Pauline Baynes.

The associated paper [1] summarises the information revealed by Signal succinctly:

The Signal messenger is primarily focused on user privacy, and thus exposes almost no information about users through the contact discovery service. The only information available about registered users is their ability to receive voice and video calls. It is also possible to retrieve the encrypted profile picture of registered users through a separate API call,if they have set any. However, user name and avatar can only be decrypted if the user has consented to this explicitly for the user requesting the information and has exchanged at least one message with them.

So Signal comes out excellently from this, yet is mentioned in the title. However, the paper does find that Telegram reveals to the world, in real time, exactly how many Telegram users have a particular phone number in their address book...

Can we change the title from the (click baiting) university press release to one which more accurately reflects the content of the paper?

[1] https://encrypto.de/papers/HWSDS21.pdf

Some high level observations on their design:

They use Bluetooth identifiers that last for 24 hours, which breaks Wifi/Bluetooth MAC rotation and allows 3rd parties to track users.

They require a connection to be established between each pair of devices and need to ping the same device again and again to check you are still in proximity. That's going to be alot of wakeups for each person you come into contact with.

They broadcast a country code in plaintext, so any international deployment would reveal the probable nationality of nearby users.

It requires NCSC / the NHS to hold a master key which they can use to reveal the identifier of any individual using the system. I think that poses a real risk of mission creep, where they start using contact tracing data for criminal investigations etc.

They also make a number of misleading claims about the decentralised solutions being deployed by Estonia, Germany, Switzerland, etc:

Claim 1: Decentralised systems without authenticated diagnosis reports can't manage malicious notifications. This is true, but all the proposed decentralised systems use authenticated diagnosis reports. Interestingly, its totally unclear how they plan to manage "anonymous" unauthenticated reports in their centralised systems. How do you distinguish between a supermarket worker or a nurse visiting homes who came into contact with a lot of people and a relay attack? Surely any centralised post-hoc verification is going to be highly invasive to individual privacy?

Claim 2: Decentralised systems introduce delays in the reporting of symptoms. This just isn't true.

Claim 3: Second Order Contact Tracing isn't possible in a decentralised system. Again, just not true. It is actually easier in a decentralised system than in a centralised one, where it carries much more difficult privacy trade-offs.

GCHQ's technical design document is here: https://www.ncsc.gov.uk/report/nhs-covid-19-app-privacy-secu...

Some observations on their design:

They refresh the identifiers broadcast by each device every 24 hours. So any 3rd party can track an individual using the app for 24 hours before they rotate their identifier. No privileged access required.

The payloads look huge (>100 bytes), so it looks like every interaction needs to be connection based (i.e. pairwise) rather than broadcast based (one to many). That's going to be hell on the battery.

They broadcast a country code in plaintext, so any international deployment would reveal the probable nationality of nearby users. Can't see that ending well.

They hold a master key which they can use to reveal the identifier of any individual using the system. Significant risk of mission creep e.g. a warrant / subpoena to reveal who was near person X during the time period Y.

Hi,

The attack described in the blog post dates from 2015. The ACME challenge protocol has been updated a few times since then. You are completely correct that signatures aren't really needed for the challenges, yet this was the initial design and it is a property of the signatures that leads to the described attack.

The trick of Andrew Ayer's attack is that the various challenges were just a particular signature under the account's public key, with the assumption that the signature uniquely identifies the public key (of the Let's Encrypt account) which controls the website. Unfortunately, this isn't true.

If you make a signature for some message and your public key. I can pick my own public key such that your signature verifies under my public key. This is maybe a little counter intuitive.

So when someone uploaded their challenge, an attacker could make a new public key and claim "hey, that challenge works under my public key!" and Let's Encrypt would then issue them with a certificate. Deleting the challenge after use would partially help, but in practice DNS is pretty slow to update and HTTP challenges might also be cached.

Disclosure: I'm an author on the paper linked in the latter half of the blog post.

https://eprint.iacr.org/2019/779 - Paper on the fun things you can do with signatures, including a write up of the Let's Encrypt Attack discovered in 2015 and some more recent attacks.

The latter. The tools in question (Tamarin and ProVerif) use a model of signatures that goes back to 2000/2001 which is around when these key substitution properties were discovered. Consequently, they were missed from the models and because the properties themselves aren't that well known, it took a while before it was noticed.

It depends what you consider to be non-repudiation!

With key substitution, you have a signature that can verify under multiple public keys. However, each key was either honestly generated and used to sign the message, or was maliciously generated and intended to appear to have signed the message.

In this sense, the party associated with each public is indisputably associated with the corresponding signature.

However, this gets a bit more confusing with message key substitution (two public keys, two messages, one signature) or colliding signature (one public key, any number of messages, one signature). For example, a malicious party might produce a signature which is valid for any message. Does the fact that they've "signed everything" mean they can repudiate having signed anything? (The connection between intent to sign and the signature has arguably been lost).

We do discuss these other properties in the paper, but we don't really delve into non-repudiation in the informal sense.

We discuss this exact attack (and blog post) in Section 5.1 of the paper :).

IIRC: it was missed by both an academic analysis of LE and a 3rd party audit of their crypto design. Thankfully Andrew spotted it a few weeks before they went live in major browsers!