Krzysztof Kotowicz

_From [[email protected]](https://code.google.com/u/[email protected]/) on July 24, 2014 01:18:49_ That looks very much better! Re 1: Closure pull request is here: https://github.com/google/closure-library/pull/322 Re 2: Nope. No need to limit length in this...

_From [[email protected]](https://code.google.com/u/[email protected]/) on July 24, 2014 18:21:04_ And...a link to the aforementioned prescheduling code. More of a performance impact than I had thought, it appears. https://github.com/coruus/e2e/commit/909622dcfef2fbf0bf4aa047d813f7dfd1527e44

_From [[email protected]](https://code.google.com/u/[email protected]/) on July 24, 2014 18:24:40_ Just as a note, it depends on the latest Closure SHA-256 patch here: https://github.com/coruus/closure-library/tree/sha1-sha2_32b

_From [[email protected]](https://code.google.com/u/[email protected]/) on July 25, 2014 11:31:58_ By the way, two relevant changes I pushed recently: 1) The initial repeated passphrase array. This gives a 50% performance improvement: https://code.google.com/p/end-to-end/source/detail?r=a89c6d160505ad76f0aa8da76e9896e97a91ee91 2)...

_From [[email protected]](https://code.google.com/u/[email protected]/) on July 29, 2014 09:05:20_ And, finally, precomputed message schedules for SHA2-256. About ~3.5x faster for SHA2-256, for c=255. Patch attached. Performance test in s2k_test.html For deriving a...

_From [[email protected]](https://code.google.com/u/[email protected]/) on July 30, 2014 21:30:08_ Thanks! After the Closure pull is accepted, please let us know so we can accept your new s2k patches.

Any updates on this?

_From [[email protected]](https://code.google.com/u/[email protected]/) on July 10, 2014 12:46:35_ Just a note here. Our defaults are the same as GnuPG's for s2k algo and iteration count. We use S2K to: - encrypt...

_From [[email protected]](https://code.google.com/u/[email protected]/) on July 11, 2014 10:11:03_ 1. GnuPG's defaults haven't been updated in years. Please don't use GnuPG doing something stupid as an excuse to do the same thing....

_From [[email protected]](https://code.google.com/u/[email protected]/) on July 17, 2014 17:10:09_ we need to check how long c=255 takes in slow hardware, but if it works out, then I agree that's the right solution...