Re: [cryptography] Designing a key stretching crypto that maximize use of WebCrypto?
On Mon, May 4, 2015 at 2:10 AM, Fabio Pietrosanti (naif) - lists li...@infosecurity.ch wrote: Hi all, testing the lovely slowness of a pure scrypt implementation in javascript running into the browser, i was wondering anyone ever tried to think/design an cryptosystem for key stretching purposes that leverage only existing webcrypto API (https://www.chromium.org/blink/webcrypto) with the goal to use let's say 80% of cpu time on native-crypto-code rather than JS code? In the browser native crypto code trough WebCrypto API works obviously much faster than JS crypto code (how much?)! Just bike shedding, but I don't think that's fair to WebCrypto. WebCrypto provides a standard set of primitives, like hahses. But the selected hashes are designed to be fast, and not slow or memory hard. So comparing a WebCrypto PBKDF based on SHA-X is akin to comparing apples and oranges. Also see https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0706.html. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Designing a key stretching crypto that maximize use of WebCrypto?
On 5/14/15 2:29 PM, Jeffrey Walton wrote: Just bike shedding, but I don't think that's fair to WebCrypto. WebCrypto provides a standard set of primitives, like hahses. But the selected hashes are designed to be fast, and not slow or memory hard. So comparing a WebCrypto PBKDF based on SHA-X is akin to comparing apples and oranges. I agree, i understand, but my point is as that given a specific constraint (ie: waiting 10s for number crunching in a browser with some JS code to do key-stretching) what's best? a) an entirely non-native javascript based scrypt for 10s b) design something new re-using existing fast native-webcrypto-primitives with some non-native javascript code running for the same 10s achieve a better security strength improvement ? For example, can we achieve an scrypt-like approach re-using for the most computational intensive operations the existing native-crypto-primitives available from webcrypto? Also see https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0706.html. Lovely, but that sounds like to be a long path. I will subscribe to the mailing list and support it! Fabio ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
