William Yager [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-02-21 to 2014-08-23
💬 Posted a total of 14 messages
📚 Participated in the following categories: Bitcoin-development, RFC
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:25:25

- reply

📅 Original date posted:2014-08-23
📝 Original message:On Sat, Aug 23, 2014 at 12:50 PM, Troy Benjegerdes <hozer at hozed.org> wrote:
> they can hire a hacker who will
> find a misplaced (} in your crypto code, and all the work you did to
> encrypt wire protocols becomes silently worthless.
>
Not to mention encrypting basically non-sensitive inter-node traffic is
almost completely worthless in providing anonymity anyway...
Seriously, I have not heard a strong justification for this proposal yet. I
have heard some people talking about Tor-ifying communications, but that is
a completely different issue and should not be confused with just
"encrypting bitcoin messages".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140823/bb85aa06/attachment.html>

2023-06-07 15:25:23

- reply

📅 Original date posted:2014-08-19
📝 Original message:On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd <pete at petertodd.org> wrote:
>
> Don't let perfect be the enemy of good.
>
I'm not. I don't think this proposal is even good.
> You realize that by your own definition even the NSA is mostly a "weak
> passive attacker" They do *not* have the ability to attack more than a
> small, targeted, subset of connection for both technical and political
> reasons. For starters, MITM attacks are easily detected - "Bitcoin network
> attacked by unknown agents! Has your ISP been compromised?" would make for
> great headlines and would soon see the problem fixed both technically and
> politically.
>
>
Again, the NSA might get an absolutely trivial amount of data from
monitoring connections on the Bitcoin network. A bit of publicity is *not*
worth drastically increasing the software complexity of the client.
> In any case, my suggestion of enabling hidden service support by default
> adds both encryption and reasonably good authentication.
Enabling hidden service support by default would introduce an insanely huge
attack surface.
And you're conflating two different things; using Tor is valuable to
Bitcoin because it would provide some anonymity. The encryption aspect is
pretty much useless for us.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140819/ce8073c6/attachment.html>

2023-06-07 15:25:22

- reply

📅 Original date posted:2014-08-19
📝 Original message:What, exactly, do we hope to achieve from having end-to-end encryption?
Even if it worked perfectly, it wouldn't be very useful.
But it won't work perfectly, because we don't have any method of
authentication. The bitcoin network is trivially MITMable. It's designed to
work even in the face of that, but any encryption we implement will just
get blown away by anyone who cares enough to stand in the middle of two
nodes.
As far as I can see, we get a microscopic obfuscatory advantage over a very
weak passive attacker, at the cost of hugely increased software complexity
(and possibly increased CPU time).
So again; what do we hope to achieve? Why bother? Not a lot of sensitive
information is transmitted in the clear. The little information that might
be considered sensitive is better protected by anonymization (a la Tor),
not encryption.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140819/1be9d73c/attachment.html>

2023-06-07 15:24:22

- reply

📅 Original date posted:2014-07-25
📝 Original message:On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell <gmaxwell at gmail.com>
wrote:
>
> Is breadwallet tamper resistant & zero on tamper hardware? otherwise
> this sounds like security theater.... I attach a debugger to the
> process (or modify the program) and ignore the block sourced time.
>
>
It's an iOS application. I would imagine it is substantially more difficult
to attach to a process (which, at the very least, requires root, and
perhaps other things on iOS) than to convince the device to change its
system time.
That said, the security benefits might not be too substantial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140724/b24595d2/attachment.html>

2023-06-07 15:19:16

- reply

📅 Original date posted:2014-04-24
📝 Original message:Gmaxwell pointed out that we could safely front-load all the key
pre-stretching. The spec has been updated to take advantage of this.
The user's password is now protected by 10,000 rounds of salted
PBKDF2-HMAC-SHA512, as well as the main KDF (which ranges from scrypt
2^14/8/8 to scrypt 2^18/16/16 and PBKDF2-HMAC-SHA512 2^16 to 2^21).
Will
On Mon, Apr 21, 2014 at 7:05 PM, William Yager <will.yager at gmail.com> wrote:
>
> The idea is that more powerful devices (mobile phones, laptops, etc.) can
> do all the key-stretching on their own, whereas weaker devices with access
> to another device with more computing power (like Trezors) do a fair amount
> of key-stretching on their own, but can safely export the rest of the
> key-stretching to the other device.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140424/22603d98/attachment.html>

2023-06-07 15:19:16

- reply

📅 Original date posted:2014-04-21
📝 Original message:The spec has been updated a bit.
Even if the bulk of the key-stretching work has been outsourced to another
device, and that device is compromised, the passphrase is now protected by
minimum 8192 rounds of salted PBKDF2-HMAC-SHA512.
The idea is that more powerful devices (mobile phones, laptops, etc.) can
do all the key-stretching on their own, whereas weaker devices with access
to another device with more computing power (like Trezors) do a fair amount
of key-stretching on their own, but can safely export the rest of the
key-stretching to the other device.
Will
On Tue, Mar 11, 2014 at 10:17 PM, Jean-Paul Kogelman <
jeanpaulkogelman at me.com> wrote:
> Hi everyone,
>
> We've been hard at work updating the spec to include features that were
> requested. We've removed the Scrypt dependency that was present in the
> initial drafts, added new KDFs, added plausible deniability and have a
> reference implementation.
>
>
> Kind regards,
>
>
> Jean-Paul Kogelman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140421/2c96e31b/attachment.html>

2023-06-07 15:15:17

- reply

📅 Original date posted:2014-03-12
📝 Original message:On Wed, Mar 12, 2014 at 4:08 PM, Jean-Paul Kogelman <jeanpaulkogelman at me.com
> wrote:
>
> Agreed, this is a valid concern. This could possibly allow a 3rd party to
> crack the password, but then again, they would not gain access to any key
> material. So yes, you could expose your password, but your key would still
> be safe.
>
> If people feel strongly about this vulnerability, we can revisit step 4
> and adjust it to make password recovery more expensive.
>
>
Just to clarify on J.P.'s comments:
*If* you choose to outsource StrongH calculation, and *If* that machine is
compromised, then the security of your password is reduced to a single
round of salted PBKDF2-HMAC-SHA512. Your private key remains on the trusted
device, no matter what.
Regrettable, but not catastrophic.
Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/1929a5bc/attachment.html>

2023-06-07 15:15:17

- reply

📅 Original date posted:2014-03-12
📝 Original message:On Wed, Mar 12, 2014 at 3:42 PM, Pavol Rusnak <stick at gk2.sk> wrote:
> On 03/12/2014 09:37 PM, William Yager wrote:
> > (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.
>
> To give you some numbers: TREZOR (120MHz ARM) does 1024 rounds of
> PBKDF2-HMAC-SHA512 in around 1 second.
>
> So 2^16 is around one minute, 2^21 is around half an hour.
>
>
Precisely. And since the target of this BIP is generally storage wallets
(just like BIP 0038), we figured these were reasonable time scales for
encryption/decryption on slow devices.
Let's say you're implementing a Raspberry Pi based cold wallet printer.
Having the user wait 10 seconds to several minutes is not unreasonable for
a one-time activity, especially when at least this much time is used to
generate entropy, print the wallet, etc.
The same goes for phones. If you're importing a heavily encrypted wallet
into your device, the user won't mind waiting a few seconds or even a few
minutes.
Plus, as an added bonus, the amount of time it will take to encrypt/decrypt
is highly deterministic, so it's easy to add a nice progress bar to a UI.
Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/4bd9b204/attachment.html>

2023-06-07 15:15:16

- reply

📅 Original date posted:2014-03-12
📝 Original message:On Wed, Mar 12, 2014 at 3:04 PM, Pavol Rusnak <stick at gk2.sk> wrote:
> On 03/12/2014 08:55 PM, William Yager wrote:
> > The proposed BIP uses a bloom filter, so it has both plausible
> deniability *and
> > *typo checking. The bloom filter is optimized for two elements and will
> > catch something like 99.9975% of typos, despite allowing two different
> > passwords.
>
> Ok, I see. So the spec allows one real and one fake password. That is
> something I don't consider plausible deniability. I am not saying that
> this solution is wrong, I find it quite interesting, but it's not
> plausible deniability. ;-)
>
It's a little more nuanced than that. There are *always* at least two
passwords. If the user doesn't want a second password, a random one is
generated for them. A wallet with two known encryption keys and only one
known encryption key are indistinguishable. If compelled to decrypt, there
is no way to prove that the user actually knows a second password.
>
> >> I'm afraid one would end up with code generated in one client that is
> >> unusable in a different client, because the client's developer thought
> >> that using fancier algorithm instead of the proposed ones was a good
> idea.
> >>
> >>
> > This is clearly in violation of the spec.
>
> Ah, I misunderstood. I thought that outsourcing the KDF means allowing
> the 3rd party to use any KDF instead of the specified ones. What would
> be the reason to outsource if this is not possible, anyway?
>
>
Yes, the "outsourcing" terminology is a little confusing. The idea is this:
You have a little device, like a Trezor. It has very little RAM and very
little CPU power. However, you want to use a powerful key-stretching
algorithm (like the maximum Scrypt KDF defined in the spec). One way to
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.
Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/437c157a/attachment.html>

2023-06-07 15:15:16

- reply

📅 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>

2023-06-07 15:15:15

- reply

📅 Original date posted:2014-03-12
📝 Original message:On Wed, Mar 12, 2014 at 2:39 PM, Pavol Rusnak <stick at gk2.sk> wrote:
> On 03/12/2014 08:26 PM, Jean-Paul Kogelman wrote:
> > So upon entering a password with a typo, the user will not be notified
> of an
> > error, but be presented with a wallet balance of 0, after the blockchain
> has
> > been scanned. I'm sorry, but that's not the kind of experience I would
> want to
> > present to my users.
>
> Sure, you can have either plausible deniability or typo checking, not
> both at the same time.
>
>
The proposed BIP uses a bloom filter, so it has both plausible deniability *and
*typo checking. The bloom filter is optimized for two elements and will
catch something like 99.9975% of typos, despite allowing two different
passwords.
> Would you care to elaborate how optional outsourcing of the KDF breaks
> > compatibility?
>
> I'm afraid one would end up with code generated in one client that is
> unusable in a different client, because the client's developer thought
> that using fancier algorithm instead of the proposed ones was a good idea.
>
>
This is clearly in violation of the spec. You could argue this about
anything in Bitcoin. What if a developer decided to replace SHA256 with
SHA3 in their implementation of a Bitcoin client? Obviously this would
cause issues.
Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/46fa5b6b/attachment.html>

2023-06-07 15:15:14

- reply

📅 Original date posted:2014-03-12
📝 Original message:This spec offers a lot of benefits over BIP 0038:
* Multiple KDFs (I think the chosen list is reasonable and fits all
required use cases)
* Multiple seed lengths
* Explicit BIP 0032 support
* Creation date field
* Plausible deniability (via the multiple-password mechanism)
I don't think it makes any sense to compare this to BIP 0039. BIP 0039 is
for key import/export, but it doesn't deal with anything like encryption,
wallet creation date, etc. The use cases are completely different.
I don't think we should let BIP 0039 (which is perfectly good for its
intended use case) hold us back from improving on BIP 0038 (which is also
good, but could use some changes).
Will
On Wed, Mar 12, 2014 at 11:49 AM, Gary Rowe <g.rowe at froot.co.uk> wrote:
> Jean-Paul, it may be worth noting that the BIP39 word list is integrated
> into Bitcoinj so will likely become the de facto standard for Android,
> Trezor web and several desktop wallets. Anyone deviating from that word
> list would likely find themselves in an isolated pocket.
>
> Regarding the timestamp, MultiBit HD uses a simple timestamp of "number of
> days since midnight of Bitcoin genesis block in UTC with modulo 97 checksum
> appended". Thus a new seed generated on 27 January 2014 would have
> "1850/01" as its checksum. When creating a new wallet the users are tested
> that they have written the timestamp down along with the associated
> 12/18/24 words.
>
> Modulo 97 was chosen since it catches about 99% of errors.
>
>
> On 12 March 2014 15:55, Pavol Rusnak <stick at gk2.sk> wrote:
>
>> On 03/12/2014 04:45 PM, Jean-Paul Kogelman wrote:
>> > Yes I am. There are some differences between BIP 39 and my proposal
>> though.
>> >
>> > - BIP 39 offers an easy list of words, no gnarly string of case
>> sensitive letters and numbers.
>>
>> Which is better IMO. I can't imagine anyone writing down a long Base58
>> encoded string.
>>
>> > - BIP 39 only offers one fixed length of entropy, always 12 words, no
>> option to increase or decrease the length.
>>
>> Not true, BIP39 supports 12/18/24 words (= 128/192/256 bits of entropy).
>>
>> > - BIP 39 doesn't have a genesis date field, so no optimization during
>> blockchain rescan.
>>
>> This is nice addition, indeed. But we needed to limit the data as
>> possible in order not to increase the number of words needed to be noted
>> down.
>>
>> > - BIP 39 doesn't have password typo detection. No easy way to recover a
>> password if you know most of it.
>>
>> It has a detection. Not correction though.
>>
>> > - BIP 39 does not have a user selectable KDF, only 2048 round
>> PBKDF2-HMAC-SHA512.
>> > - BIP 39 can't outsource the KDF computation to a 3rd party.
>>
>> True, but having one or two solid options are better than having
>> gazillions of possible options.
>>
>> > - BIP 39 wallet implementors can use their own word lists, breaking
>> cross wallet compatibility.
>>
>> True, but they are encouraged to use the list provided. Possibility to
>> outsource KDF outside of your "standard" breaks much more compatibility
>> than this.
>>
>> --
>> Best Regards / S pozdravom,
>>
>> Pavol Rusnak <stick at gk2.sk>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/95b8706a/attachment.html>

2023-06-07 15:14:36

- reply

📅 Original date posted:2014-03-03
📝 Original message:On Mar 2, 2014, at 21:34, Kevin <kevinsisco61784 at gmail.com> wrote:
> Hello. I am a developer and I wish to contribute to bitcoin. Where is
> the best place to start?
>
> --
> Kevin
Reading and learning the reference client’s source code, or doing the same for any number of non-reference-client Bitcoin projects.
Will
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140302/997c3241/attachment.sig>

2023-06-07 15:13:53

- reply

📅 Original date posted:2014-02-21
📝 Original message:Running the network part of the core as a system service might make sense for server implementations, but it’s a pain in the rear for most users.
That said, I think segregating the two processes is a great idea. Let’s just try to avoid some complicated scheme that involves necessarily running things under multiple users.
Will
On Feb 21, 2014, at 0:43, Wladimir <laanwj at gmail.com> wrote:
> The most straightforward way would be to run the blockchain daemon as a system service (with its own uid/gid and set of Apparmor/SELinux restrictions) and the wallet daemon as the user.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140221/65630db5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140221/65630db5/attachment.sig>