Re: [Bitcoin-development] BIP38 Encrypted Address Discussion

[Gregory Maxwell]

On Mon, Jun 9, 2014 at 11:13 AM, Richard Moore  wrote:
> Hey all again,
>
> I am implementing BIP38 wallets right now, and had another idea I would like 
> to put out there for discussion.
>
> Right now the scrypt pbkdf is (16384, 8, 8) for (N, r, p), but I was 
> wondering if it would make sense to include an extra byte in the address 
> which would encode the parameters used? For now, they are fine, as it takes 
> over 3 minutes to to hash once in my pure-Python implementation in CPython (3 
> seconds in pypy). But with all the latest scrypt mining ASICS hitting the 
> market, and the difficulty rising of the scrypt alt coins, it may become more 
> profitable in the future to try hacking wallets to gobble up their funds. 
> Currently all the hardware is tuned for (1024, 1, 1) and with adaptive-N, it 
> only targets upgrading the N value, so having p =r = 8 certainly means that 
> hardware won’t affect BIP 38… But who knows in the future if they start 
> making Adaptive-N-r-p ASICS.
>
> It also provides a way to vastly secure more important master keys… Maybe for 
> a key that is cold storage of millions of dollars that won’t be touched for 
> multiple years, I don’t mind waiting an hour on commodity hardware to decrypt 
> it.

See the not yet finished proposal at
https://bitcointalk.org/index.php?topic=258678.0

It's generally a lot more sound and well thought out than BIP38.
Though right now I believe it's being revised to support secret
sharing.

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] BIP38 Encrypted Address Discussion

[Richard Moore]

Hey all again,

I am implementing BIP38 wallets right now, and had another idea I would like to 
put out there for discussion.

Right now the scrypt pbkdf is (16384, 8, 8) for (N, r, p), but I was wondering 
if it would make sense to include an extra byte in the address which would 
encode the parameters used? For now, they are fine, as it takes over 3 minutes 
to to hash once in my pure-Python implementation in CPython (3 seconds in 
pypy). But with all the latest scrypt mining ASICS hitting the market, and the 
difficulty rising of the scrypt alt coins, it may become more profitable in the 
future to try hacking wallets to gobble up their funds. Currently all the 
hardware is tuned for (1024, 1, 1) and with adaptive-N, it only targets 
upgrading the N value, so having p =r = 8 certainly means that hardware won’t 
affect BIP 38… But who knows in the future if they start making Adaptive-N-r-p 
ASICS.

It also provides a way to vastly secure more important master keys… Maybe for a 
key that is cold storage of millions of dollars that won’t be touched for 
multiple years, I don’t mind waiting an hour on commodity hardware to decrypt 
it.

I was thinking, for example, if we used 1 byte, c, we could use a formula:

N = 2 ** (c + 11)
r = 2 ** c
p = r

Although, even a full byte is overkill… Maybe we can use the top three bits for 
something else? With 5 bits, the space becomes:

c = 0 => (1024, 1, 1)  (same as scrypt mining, albeit requires twice the 
dkLength)
c = 3  => (16384, 8, 8) (current specs)
c = 31 => (219902322,2147483648, 2147483648) (highest difficulty, requiring 
(5.6 * 10 ** 12) Gigabytes of memory per hash)

Anyways, just thinking out loud… I think even this space is too large… We could 
also use the top 5 bits for N and lower 3 bits of r, p, if more granularity 
seems more useful (maybe somebody *wants* their passwords easy to parallelize 
but still difficult to break?)

N = 2 ** (10 + ((c >> 3) & 0x1f))
r = p = 2 ** ((c & 0x07) * 3)

Would put N = [1024, 2048, ..., 219902322] and r = p = [1, 8, 64, 512, ..., 
2097152]

The biggest issue would be backwards compatibility. The 6P should obviously 
stay the same, as it “requires something extra” and the thing required is a 
passphrase. But maybe we could use one of the reserved bits to indicate that 
the address is adaptive? The decoded length of the address will also change 
though, which could pose issues if, for example, bounds checks aren’t being 
done (bad, but it happens) or in the case of things like python 
implementations, might assume the length correct an use derived_half2 = 
decoded[23:] which would now come back with the last byte of derived_half1 and 
be one byte too long, unchecked, passed into AES, an exception is raised 
because it is not one 16-byte block. These however seem assumptions that the 
developer should guard against.

This would retain backward compatibility though, as without the adaptive bit 
set, new and old implementations can decode the address fine (new 
implementations assuming c = 3); new implementations can detect the adaptive 
bit and select the correct kdrf parameters. old implementations on adaptive 
addresses would hopefully fail upon seeing the length is wrong or that the 
reserved bits are not 0, otherwise the checksum should fail… But if it does by 
some 1 in 4 billion chance match, the wallet may successfully import a newly 
created private key and address… Does this seem likely, or are current 
implementations ensuring the decoded length and bits are set to 0?

Otherwise, we *could* if all else fails, use “6A” for adaptive, or “6p”… But I 
don’t really like polluting the namespace for a minor tweak.

Randomly,
RicMoo

.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>

Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ric...@geneticmistakes.com
www: http://GeneticMistakes.com


--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Fwd: Your bit4coin order

[Kf Lee]

hi,

I got the email below out of blue; I an sure it is a con game.  I am not
sure anyone can do anything to stop such fraud but still like to report it.

rgds.  kfl.
-- Forwarded message --
From: "order" 
Date: Jun 8, 2014 6:21 PM
Subject: Your bit4coin order
To: "kflee2000" 

   [image: Logo]

Dear saw strike

Thank you very much for your purchase of bit4coin vouchers!

Your Wallet has been successfully added:


  Item Quantity
Total €100.00 bit4coin gift card 1
€180.00 Shipping and handling

€13.00 *Total*

*€193.00*

  Download 

*Please pay the total amount of €103.00 via (SEPA) bank transfer to:*
  *Account holder:* bit4coin BV *Bank:* ABN AMRO *IBAN:* NL76ABNA0404955568
*BIC:* ABNANL2A *Reference:* 1WZ *(Note: Important to track your payment!)*

We will inform you by email as soon as we have received your payment.




If you have any questions, please send us an email to supp...@bit4coin.net.

Kind regards,
Your bit4coin team
https://bit4coin.net

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://www.hpccsystems.com___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] PSA: Please sign your git commits

[Chris Beams]

An update on this topic:

With the release of Git 2.0, automatic commit signing is now possible with the 
'commit.gpgsign' configuration option [1]. This means that interactively 
rebased or cherry-picked commits are also re-signed on the fly. The absence of 
this ability in prior versions of Git meant that signing every commit wasn't a 
practical policy for anyone using rebase as a regular part of their local 
development workflow. Now it can be.

Merging also works as expected with this feature turned on.

One caveat I've identified thus far is a negative impact on speed when a large 
number of commits are involved. Any time you're signing a commit, you're 
interacting with the gpg-agent daemon, and this is roughly an order of 
magnitude slower than signing without committing.

Speed without signing:

$ echo '' >> README.md; time git commit -am"Test commit speed" --no-gpg-sign
[...]
real0m0.031s

and with:

$ echo '' >> README.md; time git commit -am"Test commit speed" --gpg-sign
[...]
real0m0.360s

For a single commit, this slowdown is negligible as it is still well below 
sub-second. However, if one were rebasing a local development branch with 
dozens of commits, you can see how the time would quickly add up.

Personally, I think that in practice I'll be willing to deal with with a few 
seconds' wait on those relatively rare occasions, and therefore I'm going to 
keep auto-signing enabled for now [2].

- Chris

[1]: http://article.gmane.org/gmane.comp.version-control.git/250341
[2]: https://github.com/cbeams/dotfiles/commit/d7da74

On May 23, 2014, at 12:23 PM, Wladimir  wrote:

> On Wed, May 21, 2014 at 7:10 PM, Wladimir  wrote:
>> Hello Chris,
>> 
>> On Wed, May 21, 2014 at 6:39 PM, Chris Beams  wrote:
>>> I'm personally happy to comply with this for any future commits, but wonder
>>> if you've considered the arguments against commit signing [1]? Note
>>> especially the reference therein to Linus' original negative opinion on
>>> signed commits [2].
>> 
>> Yes, I've read it. But would his alternative, signing tags, really
>> help us more here? How would that work? How would we have to structure
>> the process?
> 
> I think a compromise - that is similar to signing tags but would still
> work with the github process, and leaves a trail after merge - would
> be: if you submit a stack of commits, only sign the most recent one.
> 
> As each commit contains the cryptographic hash of the previous commit,
> which in turns contains the hash of that before it up to the root
> commit, signing every commit if you have multiple in a row is
> redundant.
> 
> I'll update the document and put it in the repository.
> 
> Wladimir



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://www.hpccsystems.com___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development