📅 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>;
William Yager [ARCHIVE] /
npub1mt…qzgqk
2023-06-07 15:15:16
in reply to nevent1q…mdgq
Author Public Key
npub1mtzsyxnmqze93rehd90508tdg7k4mwktknmtamqam55446tkaq7qnqzgqkPublished at
2023-06-07 15:15:16Event JSON
{
"id": "845e51cb4eb208d60cdb003e6428c54e3e9d1ea376976d58c63c913f0cb4e467",
"pubkey": "dac5021a7b00b2588f37695f479d6d47ad5dbacbb4f6beec1ddd295ae976e83c",
"created_at": 1686150916,
"kind": 1,
"tags": [
[
"e",
"e2b06c13dda090fd765a6fae17847c84821995c150a37c86a1dca89140911552",
"",
"root"
],
[
"e",
"1ba3dd853666c3cd6657c8c9b959ebe8e06f1025e591934ca71f47964051bef7",
"",
"reply"
],
[
"p",
"7631397e469f47f3535567311f5f7c17129e0ff2cb253df015e3d92ddfd92c63"
]
],
"content": "📅 Original date posted:2014-03-12\n📝 Original message:On Wed, Mar 12, 2014 at 3:24 PM, Pavol Rusnak \u003cstick at gk2.sk\u003e wrote:\n\n\u003e On 03/12/2014 09:10 PM, William Yager wrote:\n\u003e \u003e implement this is to allow semi-trusted devices (like desktop PCs) to do\n\u003e \u003e all the \"heavy lifting\". The way the spec is defined, it is easy to have\n\u003e a\n\u003e \u003e more powerful device do all the tough key stretching work without\n\u003e \u003e significantly compromising the security of the wallet.\n\u003e\n\u003e By disclosing \"preH\" to compromised computer (between steps 4 and 5) you\n\u003e make further steps 5-9 quite less important.\n\u003e\n\u003e\nYes, that was my chief complaint as well. A compromised computer removes\nmost of the extra security offered by key stretching (should you choose to\noutsource the bulk of your key stretching).\n\nHowever, I think we have a good compromise, which is the inclusion of a\nnumber of PBKDF2-HMAC-SHA512 based KDFs. For anyone who doesn't want to\ntrust any external device, but also wants to use memory-contrained devices\n(that group of people includes me), PBKDF2-HMAC-SHA512 is very easy to\nimplement even on devices that only have a few kB of RAM, and even though\nour number of rounds is very aggressive (2^16 and 2^21), it will still run\nin reasonable time even on very slow embedded ARM processors.\n\nWill\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/7fa33c79/attachment.html\u003e",
"sig": "a4a76ec50d941b2af4483b584c3021a5ddf501e7fd16e81c12a70de634e07353c980b6cbf7b5a5f6f881f2e1ab6ff07e27f2710e38de7c7dfd008c9de74c6afe"
}