Does NTRU provide Perfect Forward Secrecy if the world would use it in an HTTPS connection?
Properly speaking, forward secrecy is a property of a protocol. The protocol is forward secret if compromise of the long term keys does not allow an attacker to decipher any past communications.
(Occasionally a distinction is made between that and perfect forward secrecy, with the latter secure when the attacker also knows e.g. all other session keys.)
You can build a key exchange protocol that provides forward secrecy from any authenticated public key encryption, including NTRU:
- Assume the parties have exchanged long term keys.
- A generates an ephemeral key-pair and sends the public key to B, using the long term keys for authentication.
- B generates a session key, encrypts it for A's ephemeral keys and sends it to A.
- A deletes the ephemeral key-pair after decrypting the session key.
However, if you mean the old draft protocol I linked in a previous answer, then, no. Unless I'm missing something, that protocol just encrypts a random secret using the long term keys. That does not provide forward secrecy.
There is a very easy way to get Perfect Forward Secrecy with the Post Quantum Security of NTRU (if you believe NTRU is secure). However it requires TWO exchanges of information.
During Exchange 1 both parties generate and exchange ephemeral NTRU keys.
During Exchange 2 both parties generate random numbers and encrypt their random numbers with the other sides ephemeral pubic key and send the resulting cipher to the other side.
Each side then decrpts the message they receive which yields the other sides random number. They add or xor the random numbers together and they have produced a shared secret key with perfect forward secrecy and quantum safety
So yes, you can get PFS with NTRU but at the cost of an additional exchange. Other Post Quantum algorithms like the Ring-LWE scheme of Peikert or the Supersingular Isogeny algorithm of Defeo can achieve quantum safety and PFS in one exchange.
Yes. I'm not sure why others are saying "no". Forward secrecy is usually done by simply creating ephemeral keys for each connection. Thus, you will simply require a different NTRU keypair for each connection.
Another, related, question is "how fast is NTRU keypair generation?" Since forward secrecy requires the frequent creation of ephemeral keys, this should be an efficient operation. According to one benchmark, some parameter sets generate about 7000 keypairs / second on a modern 4-core i5 processor. That seems plenty fast enough.
No, as a plain public key algorithm it cannot provide PFS on its own. It is comparable to RSA in that both can be used to achieve PFS with the help of e.g. Diffie-Hellman Key Exchange. Running the key exchange for every session/connection leads to an ephemeral session key which can be used as a key for a symmetric algorithm like AES.
- NTRUEncrypt only ensures confidentiality of the Diffie-Hellman Key Exchange.
- NTRUSign only ensures authenticity of the Diffie-Hellman Key Exchange.
- The actual payload will be encrypted with AES or similar.