It's already possible to identify people running Tor relays. Tor relays are publicly listed in the Tor consensus. They need to be for clients to build paths through the network.
Some relays are used as entry points to the network, and are unlisted to prevent them from being blocked by censors like many American universities, Iran, and China. These are called bridges, and they are not listed in the consensus. Since they aren't listed in the consensus, OnionTip can't be used to donate to them.
As someone who regularly writes RTL for FPGAs during their day job, I like the idea, but am skeptical about the follow through.
For years now, various companies have tried to make cross compilers to be able to synthesize C style code into RTL. The name for this basic idea is "High Level Synthesis" (HLS). For applications like digital signal processing, HSL is actually decent. Having a stream of data moving through some transform is easy to express in C (and OpenCL), and easy to translate into a relatively efficient data pipeline in RTL when compared with making one "by hand". But this isn't the only thing that is going on within the FPGA. It is clunky and inefficient to create state machines or controllers, interact with inbuilt memory blocks, or interface with other modules not built in the HLS language.
Since inefficiencies cost resources, you end up trading your decreased development time through using HLS for possibly increased device costs, and some ambiguity in terms of the architecture of the hardware your synthesize. Since these tools haven't been broadly embraced by the FPGA coding community, the support for them doesn't tend to last long either.
I would guess that the interesting comparison isn't this vs. alternate FPGA approaches, but this vs. alternate OpenCL targets (GPUs, especially). For people that already have OpenCL written to solve their problem, they're going to want to know if the performance will be better per unit cost as compared to whatever they're running it on now, and it sounds like at least in some cases the FPGAs will do better than GPUs, so it's still a net win even if you could do it even faster by writing Verilog.
Obviously it won't work for every problem, but the problem classes you mention being a poor fit (state machines, etc.), nobody is using OpenCL for anyway... super-branchy code like state machines performs badly on GPUs, which are currently the main OpenCL targets.
My understanding is the FIPS requires that the SSL library implements a certain suite of protocols (including the Dual EC DRBG discussed in the linked mailing list post) which have known cryptographic weaknesses.
FIPS requires that any 'approved' included crypto algorithm implementations are self-tested, and pass a verification program (just a big bunch of somewhat poorly conceived known answer tests).
It also has a list of 'allowed' algorithms, which don't need to be tested but can be offered by a FIPS crypto module.
The CSPRNG used for key generation must be of an approved construction, but there are a number of choices ranging from stupid shit nobody sane would choose (Dual EC DRBG) to ones which are trivial variations on hashes, HMAC or block ciphers in OFB or CTR mode. Sadly, it says nothing about the quality or construction of actual entropy sources.
Naturally, everything not 'approved' or 'allowed' cannot be offered by a FIPS crypto module.
On the plus side, this means vendors can't offer proprietary stupid-shit like LFSR stream ciphers. Unfortunately, the approved and allowed list rarely keeps up with good quality or fixed crypto (you'll not find any eSTREAM finalists, or EdDSA, or deterministic DSA, or curve25519 ECDH, for example).
Also, the rules are pretty poorly enforced: you'll still find new FIPS certificates issued for boxes which do TLS < 1.2. This is a lie: MD5 is not allowed or approved, and is a fundamental (if conservatively used) part of the protocol in those versions.
Source: I used to make FIPS-approved HSMs. AMA? :)
A question if I may:
Could you "accidentally" make a FIPS compliant library? Assuming that the LibreSSL fork where to include ONLY the FIPS approved ciphers and hashing algorithms, it should be possible to have a library that could be passed of a compliant.
If I understand you correctly, the issue with FIPS is that you would have to be able to disable all but a subset of the features, regardless of these feature being worse or better than what is defined in the FIPS documents?
That's a bit more that one question, but I would like to know. Thanks.
It is not just that the library can only contain those specific approved ciphers and hashing algorithms, they also have to be certified through a lab, then that lab has to sign off on it (this costs thousands of dollars). You have to build in a self-test system that verifies the integrity of the FIPS components using known answer tests, and the FIPS module itself has to be able to self-check itself against a known hash, so your linker has to be nice enough to put the FIPS module at a known location (making exploitation simpler).
The whole FIPS canister thing in OpenSSL is a HUGE pain in the behind when you are building a library/product using it, and overall doesn't increase security one single bit. Yes your crypto is now FIPS 140 certified, big whoop.
[Note: I am going off the OpenSSL FIPS canister implementation details here...]
> Could you "accidentally" make a FIPS compliant library?
Let's differentiate between "FIPS compliant" and "FIPS certified".
FIPS complaint: you could get a FIPS certified product if you wanted, without changing your product.
FIPS certified: you paid NIST and a FIPS test lab some money, the lab tested your module, submitted a test report to NIST, and NIST published certificates saying that a certain version of your product (running on a particular OS and CPU architecture, for software modules) is FIPS certified.
So, yes, you could accidentally come up with a FIPS compliant crypto module. But getting certified costs actual money (last time I did it, as I recall just shy of $100k).
> the issue with FIPS is that you would have to be able to disable
> all but a subset of the features, regardless of these feature
> being worse or better than what is defined in the FIPS documents?
To some extent it depends what you mean by 'feature' here. If it's a crypto algorithm offered by your module for external use, there is quite little leeway. If it's a fundamental feature of your product that internally uses exotic crypto, you can often convince your test lab to gloss over it.
Thanks for the correction. I'm on the hardware side of things, so my understanding was that the "allowed" algorithms were actually required, and I'm relieved to hear that's not the case.
Worse than that, AFAIK, the cheapest way to keep up FIPS certification is essentially to change nothing (except as FIPS requirements change, which is "not really often").
I tried blocking some of the relevant IP ranges, but it seemed like it wouldn't fallback or something. Instead of getting perfect streaming quality, I would not be able to load the youtube video at all
FYI, the English word is "Mouthguard"
https://en.wikipedia.org/wiki/Mouthguard