William Yager [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-12 📝 Original message:On Wed, Mar 12, 2014 at ...
📅 Original date posted:2014-03-12
📝 Original message:On Wed, Mar 12, 2014 at 3:24 PM, Pavol Rusnak <stick at gk2.sk> wrote:
> On 03/12/2014 09:10 PM, William Yager wrote:
> > implement this is to allow semi-trusted devices (like desktop PCs) to do
> > all the "heavy lifting". The way the spec is defined, it is easy to have
> a
> > more powerful device do all the tough key stretching work without
> > significantly compromising the security of the wallet.
>
> By disclosing "preH" to compromised computer (between steps 4 and 5) you
> make further steps 5-9 quite less important.
>
>
Yes, that was my chief complaint as well. A compromised computer removes
most of the extra security offered by key stretching (should you choose to
outsource the bulk of your key stretching).
However, I think we have a good compromise, which is the inclusion of a
number of PBKDF2-HMAC-SHA512 based KDFs. For anyone who doesn't want to
trust any external device, but also wants to use memory-contrained devices
(that group of people includes me), PBKDF2-HMAC-SHA512 is very easy to
implement even on devices that only have a few kB of RAM, and even though
our number of rounds is very aggressive (2^16 and 2^21), it will still run
in reasonable time even on very slow embedded ARM processors.
Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/7fa33c79/attachment.html>;
📝 Original message:On Wed, Mar 12, 2014 at 3:24 PM, Pavol Rusnak <stick at gk2.sk> wrote:
> On 03/12/2014 09:10 PM, William Yager wrote:
> > implement this is to allow semi-trusted devices (like desktop PCs) to do
> > all the "heavy lifting". The way the spec is defined, it is easy to have
> a
> > more powerful device do all the tough key stretching work without
> > significantly compromising the security of the wallet.
>
> By disclosing "preH" to compromised computer (between steps 4 and 5) you
> make further steps 5-9 quite less important.
>
>
Yes, that was my chief complaint as well. A compromised computer removes
most of the extra security offered by key stretching (should you choose to
outsource the bulk of your key stretching).
However, I think we have a good compromise, which is the inclusion of a
number of PBKDF2-HMAC-SHA512 based KDFs. For anyone who doesn't want to
trust any external device, but also wants to use memory-contrained devices
(that group of people includes me), PBKDF2-HMAC-SHA512 is very easy to
implement even on devices that only have a few kB of RAM, and even though
our number of rounds is very aggressive (2^16 and 2^21), it will still run
in reasonable time even on very slow embedded ARM processors.
Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/7fa33c79/attachment.html>;