I wish they had at least made an effort to link to RFCs[0][1][2][3][...] that define SSH2 protocol and that also explain the handshake portion more accurately and in more detail (found one link to rfc4253 from article).
I also hope they didn't decide to roll their own SSH2 stack for their product (article doesn't mention if they did or did not).
Another thing I wish people would do is to include a link to .pcap of the network traffic they are trying to explain. Found one[pcap].
I found out recently that OpenSSL is not just for securing network connection. It has a whole library of ready made encryption code that can be used for other purposes.
Probably best not to do this, OpenSSL has the mindset of a collector. Rather than "Here are six things you might want to actually do" OpenSSL says "Here are four hundred things somebody has at some point proposed to do". This is already bad enough in its core competence where OpenSSL historically made it very easy to do stupid things like forget to check the certificates you were given are for the name of the host you were trying to connect to. It's much worse once you start calling APIs somebody last worked on ten years ago.
Also, since it is thinking like a collector, OpenSSL won't even nudge you if you start trying to do something that is inherently a terrible idea, like using an RSA key for encrypting data. It's possible, OpenSSL can help you do it, but you definitely shouldn't.
Libraries focused around solving real problems, such as Tink are less likely to inadvertently allow you to start doing something that everybody who cares already knew was a bad idea before you even began work.
I can’t agree with this post enough. Not only does OpenSSL have a grab-bag of ciphers of varying quality, but it also has an exceedingly confusing and under-documented set of APIs to access them. It is far easier to build something insecure on top of the OpenSSL library than it is to build something secure.
If at all possible, you should use something that directly implements the high-level constructs you need. libsodium does a good job here (and has bindings for most languages), but there are other tools for more nuanced requirements (e.g., the noise protocol suite for bi-directional communication).
In my experience, OpenSSL's API is not bad. It's overwhelming because it includes a lot, but most people just focus on one or two aspects and that API is pretty simple. E.g. for symmetric encryption, it's just couple functions, with fairly high-level constructs.
In term of using it wrong, I don't find it any worse than other libraries. You have to know what you are doing when using crypto API.
Tink has some nice things, like AEAD as a standard interface or the KetSet concept to bundle all the crypto info in one object. But its key management is cumbersome and restrictive. Dealing with keys seems like a headache.
Looking at the doc and browsing the code a bit, I don't see how to do key derivation. Is there a way to do simple key derivation via pbkdf2, scrypt or the variants?
This is quite poor article, which you can grasp after reading it. Few examples:
* quote: "generates ___something___ referred to as the exchange hash H" - in article which tries to sound technical and in fact in some parts goes into much details, this ___something___ is really funny :)
* copy pasta description of forward secrecy, wrongly explaining why it is forwardly secure
* wrong chain of events with lack of important diagram, while adding boilerplate :(
p.s. amount of upvotes shows these days a lot of us click up before reading _whole_ article.
Not a fan of documents which use a table (rows and columns) to format what is actually just several distinct columns as is done here for the list of primitives in each category.
If the author is reading this, consider how you might make it clear that the rows don't relate things across the columns.
I also hope they didn't decide to roll their own SSH2 stack for their product (article doesn't mention if they did or did not).
Another thing I wish people would do is to include a link to .pcap of the network traffic they are trying to explain. Found one[pcap].
[0] https://tools.ietf.org/html/rfc4251 [1] https://tools.ietf.org/html/rfc4252 [2] https://tools.ietf.org/html/rfc4253 [3] https://tools.ietf.org/html/rfc4254 [...] https://tools.ietf.org/html/rfc4250 (and others) [pcap] https://packetlife.net/captures/protocol/ssh/