21–30 of 565 posts
Author here. I've tried to keep the article as apolitical as possible, while giving some context to provide the setting. Anyway, I'm very interested in knowing if the used crypto is sound or not, and stirring a discussion around possible alternative approaches. Ask me anything if you want to know further!
(I think your math on bits is wrong: I'm getting that log2(1010 * 23 * 365 * 4) = 33.4, not 28.)
A few notes on the crypto off the top of my head:
1. 1714 iterations of SHA-256 seems really low given that you're going to be looking this up approximately once per person. My 2010-era laptop can compute about a million hashes per second according to `openssl speed sha256`. A second or two to look this up is definitely comparable with what a human would expect the UX to be for a dynamic website run by a government; honestly I wouldn't complain about up to a minute as long as there was a clear progress bar. So you could easily change it from 1,714 hashes to 1,714,000 without impacting UX, and you should probably do that given the relatively small key space, which would give you a factor of 1000x on the brute force attack.
2. AES-256-CBC with no IV smells funny to me. I guess every message is encrypted with a different key, but the keys themselves are easily derivable (they're just a single SHA-256 hash of the lookup key, and those are all in the public filesystem). I cannot think immediately of an attack against this but maybe someone else can.
3. Your brute-force estimates are what's needed to enumerate the entire lookup key space. The practical attack here is what you've outlined, that you know someone's date of birth and zip code (which are likely in public records). and want their national ID for some identity theft. You're not trying to find some arbitrary person to steal the identity of. That means that the date of birth and zip code are fixed, and you only need to brute-force the DNI portion, which has only 10^5 * 23 possibilities. That's extremely realistic: I can compute 10^5 * 23 * 1715 hashes on my 2010 laptop in a little over an hour.
I guess they do the right thing by only using a part of the DNI string, so you still have three unknown decimal digits, and zero information about what they might be.
It seems shocking that Spain a member of the EU is resorting to these tactics. Can you discuss some of their justifications for doing so?
Author here. I've tried to keep the article as apolitical as possible, while giving some context to provide the setting. Anyway, I'm very interested in knowing if the used crypto is sound or not, and stirring a discussion around possible alternative approaches. Ask me anything if you want to know further!
> Catalan officials can just distribute the hash of the main page file, and everyone else can be sure that all content linked from that file has been published by the catalan authorities. How does the hash of the main page guarantee that content linked from that page is authentic?
It seems shocking that Spain a member of the EU is resorting to these tactics. Can you discuss some of their justifications for doing so?
Same with some Aboriginal communities (who in some ways control vast areas of land, greater in size that many European countries!)
They were quickly denied the right to do so on a legal basis.
It never came to fistycuffs, but it could possibly have.
Independence movements are a tricky thing.
It seems shocking that Spain a member of the EU is resorting to these tactics. Can you discuss some of their justifications for doing so?
Maybe Mozilla should even get involved early in IPFS so that it can shape the protocols the way it would prefer them to work in its browser later on (while still ensuring the censorship-resistance vision of the project remains intact).
Author here. I've tried to keep the article as apolitical as possible, while giving some context to provide the setting. Anyway, I'm very interested in knowing if the used crypto is sound or not, and stirring a discussion around possible alternative approaches. Ask me anything if you want to know further!
The situation is very similar to password storage, where you want to not make it trivial to brute-force moderate-entropy passwords even if your database gets breached. We have functions designed specifically for that: scrypt, argon2 etc. https://www.npmjs.com/package/scryptsy is a pure JS implementation of scrypt for example.
Even with scrypt the situation is not great, but using sha for this kind of thing is no longer state of the art. If people are willing to (a) download and run a program rather than rely on the browser and (b) willing to wait half a minute or so for the result then you could easily tune the scrypt/argon parameters up to 11 but at the cost of quite a bit in the way of usability. If "must work on smartphones without extra app downloads" is a requirement you're pretty limited in what you can do this way.
Another solution might be to use real servers but host them on the "dark web" - get Tor a bit of publicity in Catalunya!
EDIT: in response to a few posts that briefly appeared and then disappeared again - IPFS is fine. SHA256 for authenticating a page is fine. I'm only objecting to using raw SHA-anything as a key derivation function as in the section "A static database".
I recognize that ax symbol from somewhere.
Author here. I've tried to keep the article as apolitical as possible, while giving some context to provide the setting. Anyway, I'm very interested in knowing if the used crypto is sound or not, and stirring a discussion around possible alternative approaches. Ask me anything if you want to know further!
Alternative approach: Instead of using the IPFS2HTTP gateways (that can easily be censored, as gateway.ipfs.io has already been censored in Catalunya), run a IPFS daemon locally that cannot be censored (but is not anonymous either). I live in Catalunya and wrote this tool for doing just that, in a easy way. It 1) starts a go-ipfs daemon locally, 2) opens up the referendum website in your default browser, via localhos…
I am not familiar with IPFS internals, but is there no pattern to the IPFS traffic that the ISPs can shape/block?
Too bad about the entire IPFS domain being blocked, because besides the host, HTTPS traffic has safety in numbers. If only there was a way to proxy through google.com or some other popular domain too important to block.