{"comment":{"url":"https://api.github.com/repos/maqp/pynacl/comments/15228612","html_url":"https://github.com/maqp/pynacl/commit/a89b862a703353fd536951eea574ef4305030a11#commitcomment-15228612","id":15228612,"user":{"login":"maqp","id":7425650,"avatar_url":"https://avatars.githubusercontent.com/u/7425650?v=3","gravatar_id":"","url":"https://api.github.com/users/maqp","html_url":"https://github.com/maqp","followers_url":"https://api.github.com/users/maqp/followers","following_url":"https://api.github.com/users/maqp/following{/other_user}","gists_url":"https://api.github.com/users/maqp/gists{/gist_id}","starred_url":"https://api.github.com/users/maqp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/maqp/subscriptions","organizations_url":"https://api.github.com/users/maqp/orgs","repos_url":"https://api.github.com/users/maqp/repos","events_url":"https://api.github.com/users/maqp/events{/privacy}","received_events_url":"https://api.github.com/users/maqp/received_events","type":"User","site_admin":false},"position":null,"line":null,"path":"","commit_id":"a89b862a703353fd536951eea574ef4305030a11","created_at":"2016-01-02T06:27:17Z","updated_at":"2016-01-02T06:27:17Z","body":"Since making changes to crypto libraries is generally not a good idea, here is documentation that explains why each change was made and how they do not weaken security.\r\n\r\n1. Added a getter shared_key() to extract the ECDHE shared secret from key exchange; This allows Tx.py to generate two separate symmetric keys by generating them using PBKDF2-HMAC-SHA256, each key salted with a different public key. While nonce-based crypto would be secure with two parties using the same key, it would have no forward secrecy.\r\n\r\nTFC generates forward secrecy with cyclic hashing of key through PBKDF2-HMAC-SHA256 between every message. Using only one key would mean any offset in state of key would lead to retrospective decryption of messages between the two states. \r\n\r\nTl;dr Adding this is the only way to enable forward secrecy.\r\n\r\ngenerate(ext_e):\r\nTFC has always included an option for Raspberry Pi and HWRNG generated keys. This edit allows user to mix in entropy the device during private key generation. External entropy is XORed with standard entropy -- it has no adverse effects and can only add entropy to keys. \r\n\r\nSimple proof of this is assume the external entropy is malicious. It could try to generate a keystream based on nacl.utils.random(), aiming to produce a final output that is a bit string of zeroes. This is not possible as external entropy is loaded **before** random() is called. \r\n\r\nAlternatively, the external entropy can be malicious, predictable bit sequence that provides no additional entropy. This is in no way different from XORing the random() function's output with arbitrary number of times with any completely predictable string, e.g. a bit-string of 0s, that has no effect on entropy of what random() returns. Therefore, the external entropy can not weaken the overall security.\r\n\r\nThis property is used when no external entropy is provided. In those cases, the output random() is in fact XORed with bit-string of zeroes, and it will lead to exact same output as that of random(). Since constant time XOR operation is performed for every generation time, it introduces practically no timing attacks. Also, in the case of TFC, adversary is unable to exploit TxM behind data diode, and obtain information about when the key generation started, but will first learn about the key generation when TxM outputs the public key."}}