{"action":"created","issue":{"url":"https://api.github.com/repos/diasdavid/webcrypto/issues/1","labels_url":"https://api.github.com/repos/diasdavid/webcrypto/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/diasdavid/webcrypto/issues/1/comments","events_url":"https://api.github.com/repos/diasdavid/webcrypto/issues/1/events","html_url":"https://github.com/diasdavid/webcrypto/issues/1","id":107510454,"number":1,"title":"\"Elliptic curve crypto in IPNS\"","user":{"login":"diasdavid","id":1211152,"avatar_url":"https://avatars.githubusercontent.com/u/1211152?v=3","gravatar_id":"","url":"https://api.github.com/users/diasdavid","html_url":"https://github.com/diasdavid","followers_url":"https://api.github.com/users/diasdavid/followers","following_url":"https://api.github.com/users/diasdavid/following{/other_user}","gists_url":"https://api.github.com/users/diasdavid/gists{/gist_id}","starred_url":"https://api.github.com/users/diasdavid/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/diasdavid/subscriptions","organizations_url":"https://api.github.com/users/diasdavid/orgs","repos_url":"https://api.github.com/users/diasdavid/repos","events_url":"https://api.github.com/users/diasdavid/events{/privacy}","received_events_url":"https://api.github.com/users/diasdavid/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2015-09-21T13:22:55Z","updated_at":"2015-09-28T00:00:51Z","closed_at":null,"body":"Ian and I started chatting recently about the idea of using Tweetnacl for the crypto operations on libp2p and we agreed to move the discussion to a github thread so everyone could participate:\r\n\r\nEmail thread:\r\n\r\n-----\r\nHi David,\r\n\r\nIt was great to meet you at container camp yesterday. The crypto library I mentioned is:\r\nhttp://tweetnacl.cr.yp.to/ \r\nThere is a Javascript port at:\r\nhttps://github.com/dchest/tweetnacl-js \r\nI've independently verified the results of the JS version against the origninal C version and my own Java version. \r\n\r\nTweetnacl is the only elliptic curve crypto that I would consider using. DJB is a legend, and the NSA had no hand in authoring it. One of the best demonstrations of its strength is that Tor uses it, and thus a lot of organisations have put a lot of effort into cracking it. \r\n\r\nYou said you were using the default node crypto. I understand it uses openssl under the hood, which doesn't appear to have curve25519 yet:\r\n https://github.com/openssl/openssl/issues/309\r\n\r\nI'd love to hear your thoughts,\r\nIan\r\n\r\n-----\r\n\r\nHi Ian!\r\n\r\nI share the same feeling, it is always good to put a face to the people we meet and work on the Internet :)\r\n\r\nI’ve looked at tweetnacl in the past with Max Ogden because we wanted to have a standard module to upgrade any stream to a encrypted stream, but haven’t touched it since then.\r\n\r\nThe points you make are extremely valid and the first question I have in my head is that we need more than the crypto library from Node.js, because after all we need it to run in the browser, so what I started doing/drafting is a `WebCrypto` module that works both in Node.js and in the Browser, using the crypto module and the WebCryptoAPI. Would it be good to have a way to shim tweetnacl and expose it using the same interface? So that the users could pick the best crypto module for their case? This gives me the idea of creating an abstract-crypto, following the idea of https://github.com/diasdavid/abstract-stream-muxer and https://github.com/diasdavid/abstract-record-store.\r\n\r\nWhat do you think! Also, maybe we can move this email thread to a github issue? ipfs/ipfs would be a good point, let me know if you are ok with it.\r\n\r\nCheers!\r\nDavid\r\n\r\n-----\r\n\r\nYep, feel free to start an issue, and include some of my suggestions. Certainly exposing tweetnacl, but I was suggesting more, use it by default wherever you need a crypto choice. Apart from \"post quantum\" crypto (which have enormous keys) curve25519 wins on every metric against RSA and other ECC curves. Faster encryption, decryption, signing, unsigning, harder to crack, simpler to implement, smaller keys. \r\n\r\nIan\r\n\r\n----\r\n"},"comment":{"url":"https://api.github.com/repos/diasdavid/webcrypto/issues/comments/143605714","html_url":"https://github.com/diasdavid/webcrypto/issues/1#issuecomment-143605714","issue_url":"https://api.github.com/repos/diasdavid/webcrypto/issues/1","id":143605714,"user":{"login":"jbenet","id":138401,"avatar_url":"https://avatars.githubusercontent.com/u/138401?v=3","gravatar_id":"","url":"https://api.github.com/users/jbenet","html_url":"https://github.com/jbenet","followers_url":"https://api.github.com/users/jbenet/followers","following_url":"https://api.github.com/users/jbenet/following{/other_user}","gists_url":"https://api.github.com/users/jbenet/gists{/gist_id}","starred_url":"https://api.github.com/users/jbenet/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jbenet/subscriptions","organizations_url":"https://api.github.com/users/jbenet/orgs","repos_url":"https://api.github.com/users/jbenet/repos","events_url":"https://api.github.com/users/jbenet/events{/privacy}","received_events_url":"https://api.github.com/users/jbenet/received_events","type":"User","site_admin":false},"created_at":"2015-09-28T00:00:51Z","updated_at":"2015-09-28T00:00:51Z","body":"> but if you are building a new system, use nacl. \r\n\r\nI really, really dislike statements like this. nacl is one _great_ way to abstract out all crypto (maybe even the best, i sure think so!) -- it's sane, good, fast, well written, safe, etc -- but it simply _cannot_ be the only one for any serious systems aiming to get massive, widespread adoption. You will inevitably run into users with _requirements_ outside your bounds.\r\n\r\n> Hint: all the Three Letter Acronyms protocotols have bugs that can bite you if you don't use them correctly (RSA, SHA, AES, TLS, SSH, etc... note that NACL is 4 letters ;)\r\n\r\nOh no! \"ECC\", \"DHE\", \"BLS\", \"OTP\", .... even \"DJB\"!!\r\n\r\n> SHA\r\n\r\nWhat's the bug in SHA? just that you should use >SHA2?\r\n\r\n> The other important factor is speed\r\n\r\nIndeed! ed25519 should be pretty fast anywhere though-- even \r\n\r\n> CurveCP\r\n\r\nBy the way, i looked into CurveCP perf this morning-- turns out all benchmarks show its perf in real networks isn't very good yet. The best benchmarks I found show it getting orders of magnitude worse perf than regular TCP. \r\n\r\nAlso, CurveCP (like TCP) will likely cause buffer bloat. {TLS, ...}/{uTP, LEDBAT} should not, though uTP will yield too aggressively to TCP flows, so it may not be a good solution for low latency applications (inc web requests). \r\n\r\nMy confidence is redoubled on QUIC-- it's really fast, sane, doesnt have head-of-line blocking (except for HTTP headers-- but i don't care about that), has ECC support, has both symmetric and asymmetric auth, can be used with all the right ciphers (sane AEADs), etc. Re buffer bloat, i'm not sure where QUIC stands on this, but the pluggable congestion control is much more promising than having to recompile kernels, or assuming \"Chicago is right\". In particular, i'm pretty stoked about pluggin something like Remy into QUIC."}}