galadran

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!

"This scheme also provides nonrepudiation since it proves that Alice sent the message; if the hash value recovered by Bob using Alice's public key proves that the message has not been altered, then only Alice could have created the digital signature."

This is a common misconception.

Just because a signature verifies under Alice's public key, it does not necessarily imply Alice generated the signature. For many common signature schemes, if Bob makes a signature using their public/private key, Alice can produce a different private/public key such that Bob's signature will verify under Alice's key.

Paper (we) wrote on the impacts of this: https://eprint.iacr.org/2019/779

> What remains open for future work is checking for cross-protocol attacks. [...] I can't see such an attack, but if you can, let me know on Twitter.

So we know using the same key for signing and encryption is catastrophic for general public key schemes. We don't know of any attacks in the Curve25519 case. Does anyone know of any proofs or partial results that might apply? Proof by absence of tweets feels a tad unsatisfactory.

Interesting!

Google's Project Zero team investigated WhatsApp's and Facetime's video conferencing last year:

"Overall, WhatsApp signalling seemed like a promising attack surface, but we did not find any vulnerabilities in it. There were two areas where we were able to extend the attack surface beyond what is used in the basic call flow. First, it was possible to send signalling messages that should only be sent after a call is answered before the call is answered, and they were processed by the receiving device. Second, it was possible for a peer to send voip_options JSON to another device. WhatsApp could reduce the attack surface of signalling by removing these capabilities."

"Using this setup, I was able to fuzz FaceTime calls and reproduce the crashes. I reported three CVEs in FaceTime based on this work."

WhatsApp: https://googleprojectzero.blogspot.com/2018/12/adventures-in...

Facetime: https://googleprojectzero.blogspot.com/2018/12/adventures-in...

In both cases, the close source nature of the applications stymied their efforts. Looks like NSO was willing to spend more time and resources!

This would be illegal in the EU under the GDPR which would require positive consent from the individuals monitored (simply walking into a space would not be enough). However, individual countries are allowed to alter this aspect of the Regulation themselves, so effectively countries may now "opt in" to the use of facial recognition in more settings. Quite different from the opt out relationship of the US States.

Source: https://www.lexology.com/library/detail.aspx?g=c0714997-42b1...

It's very neat and well worked out, but in hindsight it seems kind of obvious. If the "judge" trusts an "uncorruptible" witness then deniability can't hold.

Now if only Intel could actually build a secure TPM! :P

tl;dr - QUIC doesn't have kernel or hardware support (yet).

These aren't intrinsic problems with QUIC, they're common to all new protocols.

I would highly recommend mailbox.org. Based in Germany, their offering is similar but cheaper than ProtonMail. They are much more flexible as well, and allow for better security.

If you want to use the webmail client with javscript PGP (a la ProtonMail), that's supported, but they also allow you manage your own PGP keys and support using Thunderbird or Mailvelope. Additionally you can connect via a Tor Hidden Service if you want and they can PGP encrypt incoming plaintext messages if you want them to.

> Actually, the boxes can also MitM the entire SSL connection. This just happens to be a much more efficient system. It can easily be turned off without affecting the connection, and it doesn't introduce extra latency. Moreover, this system allows for post-hoc DPI rather than requiring that it happens on-line.

Great point! As you say, it scales much worse and introduces additional points of failure though.

> There are reasons beyond 'market dominance' for not wanting to do this on the end-points. End-points are numerous, heterogeneous, occasionally and occasionally difficult to access. This makes actually implementing this system on all endpoints very hard. Let alone keeping all end-points up-to-date.

Absolutely true, but this does lead to a qualititve advantage for open standard / open source solutions where you externalise the costs of additional implementations.

> In general, which sounds like the nicer approach to take: "drop in solution" or "solution that affects all endpoints and needs to support all endpoints".

I don't think this is quite the right distinction, looking at the deployment issues middlesboxes have caused for TLS1.3 and QUIC... I think it might be better phrased as:

"do you want to deploy some static hardware which has to support all endpoint network protocols correctly and upgrade when new protocols come along or do you want to write/use the software for each endpoint you choose to use?"

My point is that software is much cheaper and more flexible (in the long run) than hardware.

> The discussion is a lot more about 'Is PFS an acceptable loss for getting DPI' with a very large side discussion about whether DPI should even be possible.

I agree this is what most of the discussion is about, but I don't think its the real issue. Here are the NIST comments that were posted a few days ago:

https://csrc.nist.gov/CSRC/media/Publications/sp/800-52/rev-...

Check out the NSA's comments on page 21!

> With respect to TLS it seems better to deprecate all non-forward secure cipher suites, not just RSA key transport

This isn't just "we support PFS in TLS1.3", this is actually "please take non-PFS TLS1.2 modes away from people"!

Sorry if my point wasn't clear. I do mean that there should be DPI software running somewhere external, the point is just that you don't need dedicated hardware to do it. I completely agree doing everything on the endpoint isn't going to end well.

The real story here is not about security, it's about markets and profit (as always). Currently, there's a huge market in DPI boxes for inspecting TLS traffic, which are often poorly implemented, tied to expensive support contracts and super flakey.

These boxes can only work with a single static secret, which is shared between the DPI boxes and the actual servers. If the servers are using a forward secret mode, this is no longer enough, you have to share a secret for every session.

This necessitates some kind of software running on each endpoint to transmit these secrets. But wait, the moment you have to have software running on every endpoint, why do you need a special box? Why not do it all in software?

This represents a huge threat to the DPI market. No box means no lock in, no mandatory upgrades, no support contracts. Sure, software can have these things too, but it's inherently a more open, competitive market where you are vulnerable to open source invasion. Solutions like eTLS are just a last ditch gnashing of teeth from DPI box sellers, trying to prevent a lucrative market from disappearing.

Once you move everything to software: a) competition in general gets better and b) open source starts to take over, c) security will improve.

NewsGuard gives a red mark for Wikileaks, but a green tick for Fox News. I think we're done here.

https://twitter.com/wikileaks/status/1084876278065446913

On NewsGuard's advisory board, 5 of the 7 slots are taken by people who have held high level posts in US Intelligence and other state affairs.

If NewsGuard was just being rolled out to the USA, I'd still consider it horribly biased, but its a complete joke to make it on by default for the entire world.

It most definitely isn't.

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

Paper: https://arxiv.org/pdf/1712.07962.pdf

Not a physicist, but my summary of the author's point would be:

If you allow for matter with a negative mass and plug it into a n-body simulation. You seem to get what looks like dark matter from first principles. Namely, a halo of non interacting matter around galaxies in just the right "non-cuspy" shape. Their conclusion is that this is worth considering, as almost all mainstream cosmology makes the assumption that mass >= 0, despite the fact mass <=0 doesn't seem to violate any physical invariants we know.

The idea is persuasively simple. Every other force besides gravity is polarised, so why not also gravity? It seems interesting to me, but I'm nowhere near knowledgeable enough to know whether it can be easily refuted.

> The point is, to combine even less powerful elements of each into a package with the functionality Bloomberg describes, it would require amazingly small lithography techniques. I have yet to find someone able to say that adding processing power, signaling interfaces, networking (even a MAC), and memory/ storage onto a package this size is even possible and I have asked folks in the valley that do this at major companies.

Meanwhile at the NSA, in 2008: "Not only can we do that, we'll throw in a high frequency radio as well for beating air gaps, and it will only cost you 10k! Oh, and we'll fit it INSIDE an ethernet port."

https://en.wikipedia.org/wiki/NSA_ANT_catalog#/media/File:NS...

I'm sure the 2018 series is even smaller and even cheaper...

> The illicit chips could do all this because they were connected to the baseboard management controller, a kind of superchip that administrators use to remotely log in to problematic servers, giving them access to the most sensitive code even on machines that have crashed or are turned off.

Obviously this would still be possible without IntelME, but having an always on, highly privileged and remotely accessible baseband definitely makes the modifications easier and smaller...

> The crux of your argument seems to be "it is more valuable to be able to point an IOT device at the wrong IP than it is to get UXSS on a machine on that network". That seems obviously wrong to me for any user, technical or not.

If PiHole is malicious, there is already an attacker on your network, DNS Spoofing is just one example of the possible consequences. The PiHole can also port scan, connect to services etc. I don't think mounting an effective phishing attack on a user would be very hard.

My point is that both scenarios are catastrophic, and its hard to justify choosing one over the other on the grounds "the developer might be malicious". Telling people "don't worry a DNS server can't do much" is massively understating the problem, considering all the local network devices directly exposed to the PiHole device and the fact it is the DNS server.

As I said, I use both and cross my fingers that Mozilla / Open Source code review / the GDPR mitigates the risk of a bad developer

I absolutely agree with you about users already running dnsmasq, but the context here is a malicious developer abusing their position. The actual quality of the software is orthogonal.

I still think you are understating the risk of a malicious DNS server. As you note, many users will have unpatched IOT or network facing devices (e.g. cameras, baby monitors or other smart gadgets). With DNS spoofing they all become vulnerable to a remote attacker...

Maybe we can agree if we consider different types of users? Technically skilled users are likely to stick to secure hardware and have an awareness of their general software vulnerability. They choose their passwords carefully and are concerned about compromise. Less saavy users are more likely to own insecure devices, use the same password everywhere and be less concerned by account compromise.

High skill users have more to fear from a Web Extension, its impact is undetectable and can siphon passwords. Low skill users have more to fear from a malicious DNS server, they won't notice the lack of HTTPS on none-HSTS sites and their hardware will get compromised remotely.

You, and the other commentator, are forgetting that the DNS Server handles all connections, not just those from your browser. Are you confident all the self updating software you use has no vulnerabilities? How about the video games that you play?

Even assuming the use of HTTPS, there are other threats. For example, PiHole redirecting you to a MiTM, who simply observes your connection and can learn sensitive information from the timing and length of your sessions.

I am not arguing browser extensions have strictly less access, just that both PiHole and your extensions have a fairly catastrophic level of access...

> Do you use a popular browser extension? How confident are you that the creator wouldn’t accept a $10k offer to hand it over only to have it then go rogue on you?

What makes the Pi-Hole organization any more trustworthy? (and the software stack it all depends on)

Personally, I'm inclined to trust them both and hope that the long arm of the GDPR will be effective. Optimistic, I know.

This project has so many cryptographic wrong answers, I don't know where to begin.

Glaring problems: - The same unchanging aes key is shared between all nodes on a network. Compromise one, compromise all. Additionally a bad node can impersonate any other node.

    - The 96 bit nonce is derived randomly and there is no rekeying which means sending more than 2^32 messages will leak your (static, unchanging) key to the world. That's 2^32  total between all clients on a network. Hope everyone is manually updating their keys! 

    - Default unchanging password of `hello-world` is set. Everyone remembers to change that environment variable right?

    - The KDF is md5, which means attackers can brute force guess the key incredibly fast. 

    - There's no perfect forward secrecy (aging out of old keys). 

Amazingly, this is still better than their last version, which used AES-CBC and used the same value for both the key and the IV (which is transmitted over the network).

Summary: Stick to Wireguard!

Wow! I've seen artists who hand draw in Tolkien's style (https://www.middleearthsmaps.com/) but I never would have thought it could be done so well automatically!