< gmaxwell>
jcorgan: after reading NIST tests of varrious CDR media I dunno about trusting any of it-- they found two order of magnitude variations in durability of even 'archival grade' media. Seemed like the only way to be confident at all is to have an independant lab test it.
< gmaxwell>
jonasschnelli: probably a short private key with error correction scribed on metal (with a diamond scribe or cryptosteel) is probably the best durability that can be achieved. Most other alternatives are not especially fire/water durable.
< jcorgan>
yeah, it's more a convenience than anything to really trust. the US navy testing report i posted above used fairly good methodology and th mdisc fared well. again, though, it's a convenience and only one part of an overall system.
< jcorgan>
"If it isn't backed up in three different ways and stored in three different places, it is already lost."
< gmaxwell>
yea, thanks for the pointer.
< gmaxwell>
FWIW, I've found in research that CD readers actually have far less reading robustness that in theoretically possible. So for data recovery you could potentially read a lot of unreadable disks with a specialized drive. (there is a project on github to read audio CDs with a USRP bolted to the photodetector output of a laserdisk player).
< gmaxwell>
far less == e.g. they use the inner RS code only as a checksum, and the outer only as an erasure code, and don't do any soft-input or iteration.
< jcorgan>
i don't think the system was designed around archival, only incidental damage (scratches, etc.)
< jcorgan>
so none of the commodity write-once optical systems deal with things like fires or chemical damage, etc.
< jcorgan>
SDR/DSP is magic :-)
< jcorgan>
physical damage aside, i'm still not sure if any proper bip32 hd-wallet seed/hierarchy designs have emerged
< gmaxwell>
jonasschnelli: there are two things I'd like to talk to you about with future hardware wallet stuff.
< gmaxwell>
jonasschnelli: One of them is that we now have a scheme where the host software can protect against a hardware wallet signing maliciously in a way that leaks keys.
< gmaxwell>
jonasschnelli: perhaps you'd have some interest in implementing that. It requires an extra round trip between the host and HW wallet during signing.
< gmaxwell>
jonasschnelli: the other thing is this KDF scheme. Basically, I want to address the problem that you want to enter a password protected seed on a hardware wallet and not expose the password or seed to an untrusted host... but the hardware wallet does not have enough CPU power to do a meaningful KDF (the 2000 rounds in BIP39 is basically pointless)
< gmaxwell>
jonasschnelli: so I would suggest we use a scheme proposed some years ago by Adam Back that would let the host computer do the KDF grinding in zero knoweldge-- it learns nothing about the password entered on the hardware wallet.
< achow101>
just somewhere that they can be easily found in one place is good enough
< meshcollider>
+1
< bitcoin-git>
[bitcoin] MeshCollider opened pull request #11708: Add P2SH-P2WSH support to signrawtransaction and listunspent RPC (master...201711_signrawtransaction_wsh) https://github.com/bitcoin/bitcoin/pull/11708
< meshcollider>
validateaddress is basically an address info call isn't it
< meshcollider>
so should witnessScript and redeemScript be added to its output?
< sipa>
i believe my segwit wallet pr does that
< sipa>
or something similar at least
< meshcollider>
oh cool, thanks :)
< achow101>
meshcollider: yes, and that's why I have a PR to move most of the functionality to a new call getaddressinfo
< meshcollider>
achow101: Ah sweet, will check it out in a second
< jonasschnelli>
[14:24:20] <gmaxwell>jonasschnelli: One of them is that we now have a scheme where the host software can protect against a hardware wallet signing maliciously in a way that leaks keys.
< jonasschnelli>
That is not adam3us's proposal? Right?
< jonasschnelli>
sipa: so your scheme is to protect against possible malicious HWW (and or it's firmware)?
< kallewoof>
What was the configure option to enable deadlock detection stuff again?
< kallewoof>
Got it, I think... (CPPFLAGS=-DDEBUG_LOCKORDER)
< sipa>
kallewoof: indeed
< sipa>
jonasschnelli: indeed
< jonasschnelli>
For now,.. all HWW manufacturer consider the hosts/desktop as compromised.. but it's an interesting perspective (from the user) to get kind of a two factor security between HWW/Desktop
< jonasschnelli>
sipa: is that scheme: (k1+H(k2,R1))*G = k1*G+H(k2,R1)*G = R1+H(k2,R1)*G compatible with BIP32?
< gmaxwell>
it doesn't change anything about the public keys used, it changes the nonces in the signatures.
< jonasschnelli>
gmaxwell: instead of secp256k1_nonce_function_rfc6979 it would use the construction k1+H(k2,R1)?
< jonasschnelli>
interesting... the desktop could verify the signature before broadcasting.. I see
< gmaxwell>
a concern is that hw wallets may actually reduce user security, if I were an /evil/ genius, I'd start making counterfeit trezors and selling them on ebay for slightly under the normal retail price... with evil firmware on them. Backdooring regular computers would be a waste of my resources, but backdooring a hw wallet-- I could be confident that a high percentage of my backdoored devices were g
< gmaxwell>
oing to get cryptocoins on them.
< gmaxwell>
jonasschnelli: yes, the hw wallet sends the original R to the desktop and it can verify. If the HW wallet did something malicious it couldn't get its malicious effect further than the desktop.
< gmaxwell>
So a backdoored HW wallet would only compromise the user (1) through orignial key generation, if it does that (user can avoid by rolling dice or something for the key), or (2) with the cooperation of the desktop; which an evil party selling backdoored hardware wallets hopefully wouldn't have.
< jonasschnelli>
How Digital Bitbox wanted to prevent from that attack was by proving the device authenticity by signing arbitraty data via the HWW device and have the signature verified. But that security model is based on obscurity of the auth-private key inside the device
< gmaxwell>
at least in that kind of setup a HW wallet couldn't make you less secure than your desktop alone.
< gmaxwell>
jonasschnelli: right, which could be compromised, and it doesn't help against bad firmware being made at the maker.
< gmaxwell>
or something like making the compromised devices out of legitimate ones... where it just passes through the tamper detect to the original hardware but intercepts the rest.
< jonasschnelli>
gmaxwell: bad firmware can't be installed because the bootloader only accepts signed firmware
< jonasschnelli>
In the case of proving authenticity with a pinned private key in the device,.. this can be made relatively secure when using a EPROM chip with physical extraction measurements
< jonasschnelli>
It's as hard to extract as the seed on the device
< jonasschnelli>
But I'd say both schemes should be implemented == more security
< sipa>
well this protects against the case where the device creator is complicit
< jonasschnelli>
sipa: Indeed...
< jonasschnelli>
sipa: those key-exchanges would have to be made for each single private key (input)?
< jonasschnelli>
One downside: ability to use the HWW on any (untrusted) computer or cellphone ( == portability) would be lost.
< gmaxwell>
why?
< sipa>
heh?
< jonasschnelli>
gmaxwell: sipa: maybe I'm not getting it. Is the key exchange only used for the nonce?
< sipa>
yes
< sipa>
at signing time
< jonasschnelli>
sipa: it would only protect from leaking private key via signatures?
< sipa>
yes
< jonasschnelli>
What one probably wants is a security that the device have signed the data it has displayed on the device screen... I guess that hard to achieve
< jonasschnelli>
But if we assume the host is not fully compromised, then this is not a big deal...
< jonasschnelli>
Example: Trezor is backdoored. You sign "Send 1 BTC to Bob" (verified with Trezor screen), while it actually signs "Send 1 BTC to Malory". Because your using the online Trezor wallet, it would go undetected.
< jonasschnelli>
sipa: Thanks for that proposal.. I think that is something the Digital Bitbox guys will implement in the next (hardware) version!
< gmaxwell>
well that wouldn't be detected if the host checks the resulting transaction and isn't compromised.
< jonasschnelli>
I'm just worries how easy it is to screw up the implementation. :)
< jonasschnelli>
gmaxwell: the problem is, users just love this browser based apps!.. they are so easy to compromise IMO
< jonasschnelli>
gmaxwell, sipa: by looking at a signature, is it impossible to say wether it has used RFC6979 or if it leaks potential key material?
< gmaxwell>
sure, if the everything the user has is compromised you're out of luck.
< gmaxwell>
jonasschnelli: right you cannot tell.
< jonasschnelli>
gmaxwell: So there is a change that plenty of public signatures leak key material and that someone may have already collected those keys?
< gmaxwell>
Yes, sure.
< jonasschnelli>
I never thought of this... interesting
< gmaxwell>
I think we haven't seen attacks like this because it is not (yet) a low hanging fruit.
< gmaxwell>
Why bother understanding crypto when you can send the user an email that says "click here, you just won a free monkey."
< gmaxwell>
and the user says "oh hey, I like monkies." and then all their bitcoins are gone, no signature trickery required.
< midnightmagic>
I want a free monkey!
< jonasschnelli>
haha
< jonasschnelli>
I mean consider the fact that (I think so) Ledger does program their devices in china... they could have implemented that "change"
< jonasschnelli>
Although a firmware upgrade / verification would reveal that
< jonasschnelli>
gmaxwell: If you self-compile (and have verified that it uses RFC6979) the firmware, you are pretty safe from that attack? right?
< gmaxwell>
how can you tell if it's using the code you think it is?
< wumpus>
yes, the new malware going around on facebook seems to be more subtle psychology than free monkies, "hey I found a video of you", in which the link infects with a malware and auto-sends it to the other friends
< jonasschnelli>
gmaxwell: self compile it?
< jonasschnelli>
gmaxwell: aha.. I see
< wumpus>
so many ways to manipulate people into clicking links, even those that don't like free monkeys :)
< wumpus>
if something like that would include a wallet grabber it'd be pretty terrible
< gmaxwell>
jonasschnelli: if you have signed messages and the private key you can tell if 6979 was used by recomputing the nonces yourself, but thats not a useful way to secure a hardware wallet, since the point is to not have the private key laying around. :P just testing once isn't good enough since an evil wallet could use 6979 for the first N uses or whatnot.
< jonasschnelli>
gmaxwell: At least a special HWW function could recompute all your signatures and the desktop app could verify it agains the public ones...
< jonasschnelli>
I really like the "nonce-leak-prevention"... the cost the implementation if worth the +security one can get
< jonasschnelli>
*is worth
< jonasschnelli>
And IMO there is no UX costs (if done right=
< gmaxwell>
yes, no ux cost, just a little more data between the signer and host.
< gmaxwell>
and some software.
< jonasschnelli>
gmaxwell, sipa: are you going to write a proposal?
< wumpus>
users have been requesting a way to store their wallets somewhere else for ages
< meshcollider>
Yeah and IMO its not safe enough to start separating them all over the show yet
< wumpus>
so let's just add it, we can always add another mechanism later (then walletdir will just be the *default* wallet directory)
< wumpus>
meshcollider: I agree, the other approach just isn't ready yet
< wumpus>
and having a default wallet directory is useful too.
< wumpus>
meshcollider: yes please rebase, I hope I've saved your PR :)
< wumpus>
I'll help testing it
< meshcollider>
wumpus: rebased, thanks :)
< meshcollider>
Ah 1 sec there has been a change to walletbackup.py which I need to fix
< wumpus>
no hurry...
< meshcollider>
Yep travis is passing now, let me know if you want me to squash the last commit into "Create walletdir if datadir doesn't exist and fix tests"
< wumpus>
meshcollider: seems to work as expected here
< wumpus>
I'd hold off on the squashing, still reviewing/testing
< meshcollider>
wumpus: Okay
< wumpus>
I hopefully got someone else to test it as well
< wumpus>
the only problem with getting testers is that people tend to want it on top of 0.15.x, but if it's relevant for backport at all it makes no sense to do so before it's merged into master
< bitcoin-git>
bitcoin/master f6f8d54 Wladimir J. van der Laan: Merge #10920: [qt] Fix potential memory leak in newPossibleKey(ChangeCWallet *wallet)...
< wumpus>
promag: I intend to, but would prefer if it gets stilll some more testing of course
< promag>
I was planning to test it after lunch
< wumpus>
great!
< promag>
ok
< wumpus>
I just tested it quite extensively as I was the person to propose the change in the first place, but I didn't try e.g. multiwallet things (though I don't see why there'd be an issue)
< wumpus>
fanquake: no, your response is clear and to the point, he's on his own there, we can't provide support for all the gazilion forks
< wumpus>
and if he's able to use git enough to trace it back to our repository he's also able to find the person that made the relevant change for his altcoin...
< wumpus>
I get loads of mail about altcoins as well because my mail is in the git log so often
< fanquake>
Yea, I seem to get random messages on Twitter all the time. Get a few emails as well.
< fanquake>
#11621 Should be able to go in now
< gribble>
https://github.com/bitcoin/bitcoin/issues/11621 | [build] Add temp_bitcoin_locale_qrc to CLEAN_QT to fix make distcheck by fanquake · Pull Request #11621 · bitcoin/bitcoin · GitHub
< fanquake>
I might fixup 11222 over the weekend, and the original author doesn't seem to have time for it.
< bitcoin-git>
bitcoin/master a7c949f fanquake: [build] Add temp_bitcoin_locale_qrc to CLEAN_QT to fix make distcheck
< bitcoin-git>
bitcoin/master 1f7695b Wladimir J. van der Laan: Merge #11621: [build] Add temp_bitcoin_locale_qrc to CLEAN_QT to fix make distcheck...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11621: [build] Add temp_bitcoin_locale_qrc to CLEAN_QT to fix make distcheck (master...fix-osx-distcheck) https://github.com/bitcoin/bitcoin/pull/11621
< wumpus>
fanquake: my reply there was a last ping, if he doesn't reply or pick it up again I'll close and add a 'up for grabs' label. But yes feel free to pick it up if it's worth doing so :)
< wumpus>
apparently I stumbled on the issue exactly a month after cfields' last comment
< fanquake>
heh, it's easy for PRs to sit and idle for a long time. Little burst of activity and interest, and then it gets a few rebases out of date, or too far buried in the stream of new PRs
< fanquake>
wumpus Thoughts on new PGP key additions? A few recently seem to be submitting their keys for addition before they've even gitian built. There's not really a rule about adding them?
< fanquake>
I think jonass is right in that there are so few builders you don't want to turn anyone away. Keys can also easily be removed later on.
< wumpus>
fanquake: that tends to happen, it's quite common for open source projects, especially busy ones. Though it can be sad if a certain PR gets no review interest at all, e.g. #10994
< fanquake>
Still not sure about #11526 though. We had discussions about this with an Xcode project a while ago. Ended up in a separate repository, doesn't look like it lasted too long.
< wumpus>
I don't know either. I like the idea of making MSVC build easier, but I don't want to expect from people to maintain two build systems when e.g. adding a file.
< wumpus>
certainly not one that only runs on one platform
< wumpus>
I'm ok with merging it though, the author committed to maintaining MSVC support
< fanquake>
There are some other PRs that need merging first. To fix compilation issues, and "a tonne of warnings" apparently. Should probably get those in fix at least, and see what other issues they turn up. If any.
< bitcoin-git>
bitcoin/master e89adba Matt Corallo: Make default issue text all comments to make issues more readable
< bitcoin-git>
bitcoin/master 5197100 Wladimir J. van der Laan: Merge #11706: Make default issue text all comments to make issues more readable...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11706: Make default issue text all comments to make issues more readable (master...2017-11-shorter-default-issue-redux) https://github.com/bitcoin/bitcoin/pull/11706
< fanquake>
Hopefully now the first line I'll see in issue emails will actually contain some information, rather than 99% of the time it being the template text.
< wumpus>
oh yes that's annoying, almost everyone just kept the template text there, usually without even paying attention to it
< wumpus>
I certainly understand why some bug reporting systems (e.g. bugzilla) make people fill in a form, instead of just offering a free text field
< fanquake>
It's a trade off between capturing everything, and missing some obscure bug being reported by an unmotivated passer by
< wumpus>
a template is apparently not a working substitute for that, well who knows, maybe BlueMatt's cleanups improve it
< bitcoin-git>
[bitcoin] fanquake opened pull request #11711: bitcoin_qt.m4: Minor fixes and clean-ups. (master...bitcoin-qt-m4-cleanup) https://github.com/bitcoin/bitcoin/pull/11711
< promag>
first time run is doesn't use -walletdir right?
< fanquake>
I assume not looking at the comments, if the behaviour is assumed to be the same in either case
< wumpus>
fanquake: I think it's harmless to run it, though maybe unnecessary, I don't know
< wumpus>
fanquake: the test is there to check if there is a collision between protobuf and our bswap primitives, so it will always pass if protobuf is not included
< wumpus>
promag: you mean when it's run when the datadir doesn't exist yet?
< promag>
yes
< wumpus>
promag: that would be bad, let's see
< promag>
it's building here so..
< promag>
wumpus: it creates datadir/wallets but uses the provided -walletdir
< wumpus>
not creating all new data directories (including when running without wallets) with a wallets subdirectory would enormously complicate things
< promag>
yes I saw that. But here I've provided -walletdir no there's no need (and no harm) creating datadir/wallets
< wumpus>
it should still be created if you want to run without -walletdir later
< wumpus>
because if not it's too late - it's no longer a new data directory, so it will use legacy layout
< promag>
MarcoFalke: just a question, I saw the moveonly
< promag>
now it can be cleaned right?
< wumpus>
promag: sure
< MarcoFalke>
promag: Not sure if that single change warrants a pull on its own
< MarcoFalke>
I'd prefer if is cleaned up when the function is touched by other reasons. Though, no strong opinion. Just -0
< meshcollider>
wumpus: re net-specific walletdir subdirectories, what do you think of it just using them if they exist, but defaulting to root dir (so the user has to create the subdirectories themselves if they want them)
< meshcollider>
Would be a much simpler change I think
< jonasschnelli>
wumpus: yeah. Not in CH timezone. Right now in Hawaii
< jonasschnelli>
is there a quick way to compile without tests (without re-configure)? I wish i could speed up compile time of pull requests for a quick test...
< jonasschnelli>
compile time is a main show stopper for testing pulls
< BlueMatt>
jonasschnelli: make src/bitcoind (or maybe its just make bitcoind?)
< jonasschnelli>
BlueMatt: hmm.. yes. That could work (now all pre-built,.. need to test with a new PR)