I am tired of my build being red just because of some random issue with
Arch linux that I don't have the time to investigate.
Also, tweak name of the MacOS workflow.
Delete roadmap section. The P2P item is basically done. P2P has its own
roadmap. We have the issues list, and all of those items are things we
want to do. I don't think having the roadmap is useful, or accurately
conveys priorities.
Go into just a bit more detail about the P2P basics in the main feature
summary.
Added some notes about symmetric connect mode, which is a really useful
and unique API feature.
It was a good experiment to show that our reference code for
ed25519/curve25519 was slow. Now we just need to move to OpenSSL for
25519.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
Also tweak the way that the per-packet IV is constructed. Previously,
64 bits were the packet number. This meant that the attacker knew 64-bits
of the IV, while the other 64-bits were secret, generated by key exchange.
Now, the IV is adjusted by the packet number, so that all 128 bits are
unknown to an attacker, although he does know that the relationship
between one IV and the next.
This introduces a breaking wire incompatibility, so I bumped the protocol
version number as well as the minimum required version for the peer. We
still have luxury of doing this sort of thing, but we won't once we make
the first release. We'll need an exceedingly good reason to break backward
compatibility with older peers. (Although, for example, if a security
vulnerability is detected, we may allow the application to control whether
it wishes to allow conneections from peers using the version with the
vulnerability.)
Fixes#43
Update roadmap section with note about plans are for the current (FIRST!) release.
Delete comments about OpenSSL bloat. That referred to a bunch of stuff that was being loaded in by opensslwrapper. We still do have some cleanup to do here. In particular, we'd like to be able to get OpenSSL to work for the 25519 stuff, and get rid of our reference code. Another potential project is to use libsodium for everything, which may be leaner and faster -- however, that might require us to switch to AES-GSM. That would be a fine idea, but it would introduce a wire incompatibility. (We might end up doing this for the first release, to avoid having to deal with compatibilty issues.)
Also delete comments about STL container bloat. I have converted almost all of the ordered maps to hashmaps, which do not do seperate heap allocations per item. There are 2 or 3 remaining std::maps in the reliability layer, but those are constrained to a max size (to protect against a malicious peer), so I don't think this is high priority. It would be good to fix this to limit the use of the heap to an absolute minimum, but for now tehre are more important issues.
This features a robust ack model inspired by Google QUIC,
which allows for minimal retransmission of reliable data.
It should also allow for the rate calculations to be done
by the sender, but that has been temporarily broken.
The wire framing has also been significantly optimized.
Mentioned "protobuf" in the OpenSSL section. Seems a redundant word here
anyway, just going to call them "packages" unqualified.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
Fletcher Dunn
Hussein Ait-Lahcen
Cyprien AUGIER
Steven Noonan
NielsAD
Cory Hutchison
Roger
Kyle Kukshtel
Joakim Hellsén
Rainer Eli
Arseniy Shestakov