Re: [cryptography] Designing a key stretching crypto that maximize use of WebCrypto?
I'm curious how PBKDF2 compares. On Sun, May 3, 2015 at 11:10 PM 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?)! Fabio ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] NIST Workshop on Elliptic Curve Cryptography Standards
On Tue, May 12, 2015 at 5:00 PM, d...@deadhat.com wrote: There is a very simple way around this. Block XXTEA introduced a new method [snip] Although for the internet and smart cards, data packets are small enough for 64 bit blocks not to matter as long as you rekey between packets. To paraphrase Bowman: Oh my God. It's full of integer adders! Integer adders don't pass the sniff test for lightweight hardware. Alas, the world isn't just the internet and smart cards. We are throwing crypto on silicon as fast as we can to address the many threats to computer hardware. No one block size is correct. Did you some how miss the suggestion to convert AES to the same method by using XORs? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
