openssh-portable VS pyNTRUEncrypt

Unless I'm misunderstanding what this is about RFC5647 merely points out that the sequence number is included as AAD due to RFC4253 requirements. The [email protected] specification is not exactly the most rigorous thing I've ever seen (https://github.com/openssh/openssh-portable/blob/master/PROT...) but reading it, the sequence number is only included in the IV, and not as AAD, which directly runs afoul of the RFC4253 section 6.4 requirement for it to be included in the MAC.

The key layout is described in https://github.com/openssh/openssh-portable/blob/master/PROT... and you can view it pretty easily via

cat private_key_here | head -n -1 | tail -n +2 | base64 -d | xxd

One I created in 2016 is using aes256-cbc with bcrypt for the kdf, which isn't awful at all.

Interestingly, it looks like ssh-agent disables core dumps[1], but I don't see similar usage for sshd

1: https://github.com/openssh/openssh-portable/blob/694150ad927...

There's a current pull request for adding AF_UNIX support, which should make all kinds of exciting forwarding possible, since it will make it easy to proxy ssh connections through an arbitrary local process which can do anything to forward the data to the remote end.

https://github.com/openssh/openssh-portable/pull/431

OpenSSH server (allows connecting to containers)

It doesn't, at least not for generic/unmodified cryptographic applications.

WebAuthN signatures are of a very specific challenge/response format that applications need to explicitly support. For example, SSH had to add new key and signature formats [1] to support it.

Theoretically, a blockchain/cryptocurrency application could adopt the WebAuthN signature format as its canonical or an alternative signature format, but I'm not aware of any popular one having done so.

[1] https://github.com/openssh/openssh-portable/blob/master/PROT...

I just tested it and looked at the code briefly; the client fortunately does seem to remove all keys not provided by the server: https://github.com/openssh/openssh-portable/blob/36c6c3eff5e...

It seems like at least a `known_hosts` compromise would be "self-healing" after connecting to the legitimate github.com server once.

And OpenVAS and OpenSSH and OpenBSD and OpenNN and OpenAFS and on and on and on

I have a really old (college) implementation of plain old NTRU in Python, if you'd like a little insight into what NTRU is and how it works at a superficial level (kind of like how RSA is never textbook RSA). There are also some slides explaining the math, but you have to be comfortable with some college level group theory (even reading my own slides is hard because I haven't used it since then).

The short answer is that NTRU uses convolution polynomial lattices. Breaking the cryptosystem requires finding a "short" basis for a lattice described by the private key. There are efficient algorithms for this in R^2, but not for high dimensional convolutional polynomial spaces (LLL Reduction is the best I'm aware of, which is greater than O(d^5) where d is the number of dimensions https://en.wikipedia.org/wiki/Lenstra%E2%80%93Lenstra%E2%80%...).

Do note the impl I did is absolutely terrible and probably subtly buggy but might get the idea across. Also, it splits the message into blocks and encrypts that instead of just wrapping a symmetric encryption algorithm because I was young and naive. :)

https://github.com/logannc/pyNTRUEncrypt