Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2015-11-29T21:22:05Zhttps://gitlab.torproject.org/legacy/trac/-/issues/16229Teach Stem to understand post-prop220 descriptors2015-11-29T21:22:05ZIsis LovecruftTeach Stem to understand post-prop220 descriptorsFor proposal !#220 (#12498), Ed25519-SHA-512 router identity and signing keys were added for relays (and soon for bridges?).
* The Ed25519 identity key may be optionally kept offline, and it is used to sign the Ed25519 signing key.
...For proposal !#220 (#12498), Ed25519-SHA-512 router identity and signing keys were added for relays (and soon for bridges?).
* The Ed25519 identity key may be optionally kept offline, and it is used to sign the Ed25519 signing key.
* The Ed25519 signing key is used to sign everything the normal RSA-based router `signing-key` would sign.
All Ed25519 keys are kept in a _very_ strange certificate (it uses OpenSSL certificate extensions to store the Ed25519 key, among other weirdish things). We'll probably want to reference both §2 of proposal !#220, and probably the code from #12498, to ensure that we're parsing it correctly. This certificate will mean it'll a bit of a PITA to parse in Python, but, personally, I rather masochistically enjoy wrangling with PyOpenSSL's brutish, kludgey internals and am more than willing to help with this part.
They also cross-certify the normal RSA-based identity keys. From proposal !#220:
```
Note that these keys cross-certify as follows: the ed25519 identity
key signs the ed25519 signing key in the certificate. The ed25519
signing key signs itself and the ed25519 identity key and the RSA
identity key as part of signing the descriptor. And the RSA identity
key also signs all three keys as part of signing the descriptor.
```
These new keys and their related fields will be appearing in _both_ the `@type [bridge-]server-descriptor`s and the `@type [bridge-]extrainfo` descriptors, for routers running Tor>=0.2.7.x (0.2.7.1??), and so Stem's parsers for both types of descriptor will need to take these things into account.
We'll also need to decide if it is permissible to bring in a Python dependency to Stem. If so, there are two good Python Ed25519 modules (to my current knowledge):
1. [Brian Warner's Python extension which wraps the SUPERCOP Ed25519 reference code](https://pypi.python.org/pypi/ed25519/):
| **Caveats** | **Benefits** |
|-----------------------------|-----------------------------|
| It has some type/encoding conversions which don't look quite fool-proof. | More Pythonic interface. |
| It also would be somewhat impossible to dig into the internals of it (from Stem's code) should we need to do something weird (we might), since the internals are buried in the underlying C code. | Faster. |
| Very little documentation. | Has tests. |
| No interface for taking advantage of Ed25519 batch signature verification. | Has a notion of string prefixes for signed messages (which would come in particularly handy for Tor's case). |
2. [djb's pure-Python reference version](http://ed25519.cr.yp.to/python/ed25519.py):
| **Caveats** | **Benefits** |
|-----------------------------|------------------------------|
| Slower. | More malleable. |
| Rather "academic" code… entirely undocumented. | It's quite clear what the code is doing, even without documentation. It [has](http://ed25519.cr.yp.to/python/sign.input) [tests](http://ed25519.cr.yp.to/python/sign.py). |
| ([Mostly](http://ed25519.cr.yp.to/python/checkparams.py)) duck-typed/unchecked inputs; we'd have to be careful what we pass to its functions. | |
| Rather poor exception raising/handling. We'd likely have to to `except Exception as error` and then parse the message to figure out where something went wrong. | |
| No interface for taking advantage of Ed25519 batch signature verification. | Has some functions for low-level point and curve operations. |
Despite the above caveats and benefits, on a cursory reading of both, the latter looks of better use for parsing-only (i.e. not for signing or key creation).
**Related Tickets:** #12498 #15054 #16227Damian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/10816Don't exclude NTE_BAD_KEYSET error for windows2020-06-13T14:34:00ZcypherpunksDon't exclude NTE_BAD_KEYSET error for windows```
if (!provider_set) {
if (!CryptAcquireContext(&provider, NULL, NULL, PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT)) {
if ((unsigned long)GetLastError() != (unsigned long)NTE_BAD_KEYSET) {
log_wa...```
if (!provider_set) {
if (!CryptAcquireContext(&provider, NULL, NULL, PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT)) {
if ((unsigned long)GetLastError() != (unsigned long)NTE_BAD_KEYSET) {
log_warn(LD_CRYPTO, "Can't get CryptoAPI provider [1]");
return -1;
}
}
provider_set = 1;
}
```
According to http://msdn.microsoft.com/en-us/library/windows/desktop/aa379886%28v=vs.85%29.aspx NTE_BAD_KEYSET is
```
The key container could not be opened. A common cause of this error is that the key container does not exist. To create a key container, call CryptAcquireContext using the CRYPT_NEWKEYSET flag. This error code can also indicate that access to an existing key container is denied. Access rights to the container can be granted by the key set creator by using CryptSetProvParam.
```
Such error code can't be returned for used parametrs, but if something gone wrong in system then current processing this code blocks any next tries to get random data and hides real reason for any next CryptGenRandom failures.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8897Faster curve25519 implementation for ntor2020-06-13T14:29:13ZNick MathewsonFaster curve25519 implementation for ntorFloodberry's curve25519 implementations at https://github.com/floodyberry/curve25519-donna are mostly C, and claim to be faster still than the ones we're using now, especially on intel cpus. We should evaluate them and consider switchin...Floodberry's curve25519 implementations at https://github.com/floodyberry/curve25519-donna are mostly C, and claim to be faster still than the ones we're using now, especially on intel cpus. We should evaluate them and consider switching.
Also, if we find an ed25519 implementation we like and wind up using it, we should evaluate using its component pieces to build an optimized curve25519 implementation for calculations on the base point as per http://www.imperialviolet.org/2013/05/10/fastercurve25519.html ; Adam has some example code based on one of the amd64 assembly implementations.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6143Implement server-side of proposal 198 ("Restore semantics of TLS ClientHello")2020-06-13T14:20:26ZNick MathewsonImplement server-side of proposal 198 ("Restore semantics of TLS ClientHello")In Tor 0.2.3.17-tbd, we implement the client side of proposal 198: our ClientHellos can now be taken seriously.
Early in Tor 0.2.4.x, we should have servers start recognize the new ClientHellos, and take them seriously.In Tor 0.2.3.17-tbd, we implement the client side of proposal 198: our ClientHellos can now be taken seriously.
Early in Tor 0.2.4.x, we should have servers start recognize the new ClientHellos, and take them seriously.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4008Identify safe, common, useful openssl engines to enable by default2020-06-13T14:13:13ZNick MathewsonIdentify safe, common, useful openssl engines to enable by defaultEver since f0d4b3d1 (svn revision r5829) , all of our crypto acceleration is off by default, since we can't trust any given openssl engine to be secure, stable, and to run without crashing.
We should identify engines which it would be s...Ever since f0d4b3d1 (svn revision r5829) , all of our crypto acceleration is off by default, since we can't trust any given openssl engine to be secure, stable, and to run without crashing.
We should identify engines which it would be safe and useful to turn on by default, and have them be on-by-default. IMO the criteria should be:
* It needs to be pretty common for a user to have the requisite hardware but not know about it. IOW, anybody who has bought a special-purpose board can configure it themselves, but people with CPU or chipset support for acceleration are likely not to have thought about it.
* It needs to be really stable.
* It needs to be pretty well distributed.
* It needs to be using a recent version of openssl.
* It needs to make an actual improvement to Tor's performance or security.
* We need to be able to test it.
Good candidates to look at for a start IMO are aes-ni instructions.
We'll also maybe need a UI change to let people disable default engines and add extra ones.Tor: unspecified