Re: [bitcoin-dev] proposal: extend WIF format for segwit

[Karl-Johan Alm via bitcoin-dev]

Hello,

I made slight modification to the BIP, dropping the 0x80 jump to 0x10:
https://github.com/kallewoof/bips/blob/bip-typed-wif/bip-extended-privkey.mediawiki

I will make the corresponding changes to the reference implementation shortly.

If there are no objections I would also like to request a BIP number.


On Wed, Apr 4, 2018 at 3:06 PM, Karl Johan Alm
 wrote:
> I took the liberty of turning this into a BIP proposal -- the
> formatted version can be seen here:
> https://github.com/kallewoof/bips/blob/bip-typed-wif/bip-extended-privkey.mediawiki
>
> 
>   BIP: XXX
>   Layer: Applications
>   Title: Typed Private Keys
>   Author: Karl-Johan Alm 
>   Comments-Summary: No comments yet.
>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXX
>   Status: Draft
>   Type: Standards Track
>   Created: 2018-04-04
>   License: CC0-1.0
> 
>
> == Abstract ==
>
> An extension to the private key (WIF) format to specify what kind of
> public key the private key corresponds to.
>
> == Motivation ==
>
> There are several types of public keys which can all be associated
> with a given private key: P2PKH (legacy 1... format),
> P2SH-P2WPKH (SegWit public key inside P2SH), P2WPKH (bech32), etc.
>
> While private keys have a 1-byte suffix indicating whether the
> corresponding public key is compressed (0x01) or not
> (0x00), there is no way of knowing what kind of public
> keys were associated with the private key. As a result, when importing
> a private key, the wallet has to assume all kinds, and keep track of
> each possible alternative.
>
> By extending the suffix, we can specify what kind of public key was
> associated with the given private key.
>
> == Specification ==
>
> Currently, private keys are stored as a uint256 (private key data)
> followed by a uint8 (compressed flag). The latter is extended to
> specify the public key types:
>
> {|class="wikitable" style="text-align: center;"
> |-
> !Value
> !Type
> !Compr
> !Clarification
> |-
> |0x00||P2PKH_UNCOMPRESSED||No||Uncompressed legacy public
> key. Unknown public key format
> |-
> |0x01||P2PKH_COMPRESSED||Yes||Compressed legacy public
> key. Unknown public key format
> |-
> |0x80||P2PKH||Yes||Compressed legacy public key. Legacy
> public key format (1...)
> |-
> |0x81||P2WPKH||Yes||Bech32 format (native Segwit)
> |-
> |0x82||P2WPKH_P2SH||Yes||Segwit nested in BIP16 P2SH
> (3...)
> |-
> |0x85||P2SH||  ||Non-Segwit BIP16 P2SH (3...)
> |-
> |0x86||P2WSH||  ||Native Segwit P2SH
> |-
> |0x87||P2WSH_P2SH||  ||Native Segwit P2SH nested
> in BIP16 P2SH
> |}
>
> When a wallet imports a private key, it will have two outcomes:
>
> * the key is using one of the legacy types, in which case all types
> must be accounted for
> * the key is using one of the extended types, in which case the wallet
> need only track the specific corresponding public key
>
> == Rationale ==
>
> TODO
>
> == Compatibility ==
>
> This proposal is not backwards compatible, in that software that does
> not recognize the new types will not understand the compressed flag.
> It would be trivial to change this, by keeping the 'uncompressed'
> state as it is (0) and changing 'compressed' to be 'anything not 0',
> as opposed to 'the value 1'.
>
> The proposal *is* backwards compatible in that new wallet software
> will always understand the old WIF format, however. It will, as it
> does today, assume that any kind of public key is possible, and will
> have to track all of them, as it has to today.
>
> == Acknowledgements ==
>
> This BIP is based on the initial proposal by Thomas Voegtlin
>  on the Bitcoin Dev mailing
> listhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015007.html
> and the Electrum 3.0
> implementationhttps://github.com/spesmilo/electrum/blob/82e88cb89df35288b80dfdbe071da74247351251/RELEASE-NOTES#L95-L108
>
> == Reference implementation ==
>
> There is a partial implementation which adds, but does not use, the
> types described in this BIP here:
> https://github.com/bitcoin/bitcoin/pull/12869
>
> == References ==
>
> 
>
> == Copyright ==
>
> This document is licensed under the Creative Commons CC0 1.0 Universal 
> license.
>
> On Mon, Sep 18, 2017 at 12:36 AM, Mark Friedenbach via bitcoin-dev
>  wrote:
>> Bech32 and WIF payload format are mostly orthogonal issues. You can design a
>> new wallet import format now and later switch it to Bech32.
>>
>> On Sep 17, 2017, at 7:42 AM, AJ West via bitcoin-dev
>>  wrote:
>>
>> Hi I have a small interjection about the point on error correction (excuse
>> me if it seems elementary). Isn't there an argument to be made where a
>> wallet software should never attempt to figure out the 'correct' address, or
>> in this case private key? I don't think it's crazy to suggest somebody could
>> import a slightly erroneous WIF, the software gracefully error-corrects 

Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected.

[Jason Davies via bitcoin-dev]

These issues all stem from the RC4-based RNG implementation (with insecure
fallback entropy) in Tom Wu's jsbn library, published here:
http://www-cs-students.stanford.edu/~tjw/jsbn/

Please refer to Tom Wu's URL, or this more up-to-date fork of Tom Wu's code
(published to NPM): https://github.com/andyperlitch/jsbn -- my repository on
GitHub was only ever intended to be a straight mirror of Tom Wu's code (created
over 7 years ago!).  I'll probably delete my mirror repository given that there
are now better JavaScript bignum alternatives, and in light of this report.

Jason

> On 9 Apr 2018, at 22:11, m...@musalbas.com wrote:
> 
> Here's the code in question: https://github.com/jasondavies/jsbn/pull/7
> 
> Best,
> 
> Mustafa

--
Jason Davies, http://www.jasondavies.com/

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected.

[Mustafa Al-Bassam via bitcoin-dev]

The original disclosure didn't contain any information about the library
in question, so I did some digging.

I think that the vulnerability disclosure is referring to a pre-2013
version of jsbn, a JavaScript crypto library. Before it used the CSRNG
in the Web Crypto API, it tried to use nsIDOMCrypto, but incorrectly did
a string comparison when checking the browser version.

In practice though, this doesn't really matter, because
navigator.appVersion < "5" returns true anyway for old browsers. The
real issue is that modern browsers don't have window.crypto.random
defined, so Bitcoin wallets using a pre-2013 version of jsbn may not be
using a CSPRNG, when run on a modern browser.

As is noted though, even if a CSPRNG is used, the library passes the
output of the CSPRNG through RC4, which generates some biased bits,
leading to possible private key recovery.


On 09/04/18 22:17, Mustafa Al-Bassam via bitcoin-dev wrote:
>
> And specifically, here's a version of it that uses Arcfour:
> https://gist.github.com/jonls/5230850
>
>
> On 09/04/18 22:11, Mustafa Al-Bassam wrote:
>>
>> Here's the code in question: https://github.com/jasondavies/jsbn/pull/7
>>
>> Best,
>>
>> Mustafa
>>
>>
>> On 06/04/18 21:51, Matias Alejo Garcia via bitcoin-dev wrote:
>>> Source? 
>>>
>>> On Fri, Apr 6, 2018 at 4:53 PM, ketamine--- via bitcoin-dev
>>> >> > wrote:
>>>
>>> A significant number of past and current cryptocurrency products
>>> contain a JavaScript class named SecureRandom(), containing both
>>> entropy collection and a PRNG. The entropy collection and the RNG
>>> itself are both deficient to the degree that key material can be
>>> recovered by a third party with medium complexity. There are a
>>> substantial number of variations of this SecureRandom() class in
>>> various pieces of software, some with bugs fixed, some with
>>> additional
>>> bugs added. Products that aren't today vulnerable due to moving to
>>> other libraries may be using old keys that have been previously
>>> compromised by usage of SecureRandom().
>>>
>>>
>>> The most common variations of the library attempts to collect
>>> entropy
>>> from window.crypto's CSPRNG, but due to a type error in a comparison
>>> this function is silently stepped over without failing. Entropy is
>>> subsequently gathered from math.Random (a 48bit linear congruential
>>> generator, seeded by the time in some browsers), and a single
>>> execution of a medium resolution timer. In some known configurations
>>> this system has substantially less than 48 bits of entropy.
>>>
>>> The core of the RNG is an implementation of RC4 ("arcfour random"),
>>> and the output is often directly used for the creation of
>>> private key
>>> material as well as cryptographic nonces for ECDSA signatures.
>>> RC4 is
>>> publicly known to have biases of several bits, which are likely
>>> sufficient for a lattice solver to recover a ECDSA private key
>>> given a
>>> number of signatures. One popular Bitcoin web wallet re-initialized
>>> the RC4 state for every signature which makes the biases
>>> bit-aligned,
>>> but in other cases the Special K would be manifest itself over
>>> multiple transactions.
>>>
>>>
>>> Necessary action:
>>>
>>>   * identify and move all funds stored using SecureRandom()
>>>
>>>   * rotate all key material generated by, or has come into contact
>>> with any piece of software using SecureRandom()
>>>
>>>   * do not write cryptographic tools in non-type safe languages
>>>
>>>   * don't take the output of a CSPRNG and pass it through RC4
>>>
>>> -
>>> 3CJ99vSipFi9z11UdbdZWfNKjywJnY8sT8
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> 
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> 
>>>
>>>
>>>
>>>
>>> -- 
>>> Matías Alejo Garcia
>>> @ematiu
>>> Roads? Where we're going, we don't need roads!
>>>
>>>
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected.

[Mustafa Al-Bassam via bitcoin-dev]

Here's the code in question: https://github.com/jasondavies/jsbn/pull/7

Best,

Mustafa


On 06/04/18 21:51, Matias Alejo Garcia via bitcoin-dev wrote:
> Source? 
>
> On Fri, Apr 6, 2018 at 4:53 PM, ketamine--- via bitcoin-dev
>  > wrote:
>
> A significant number of past and current cryptocurrency products
> contain a JavaScript class named SecureRandom(), containing both
> entropy collection and a PRNG. The entropy collection and the RNG
> itself are both deficient to the degree that key material can be
> recovered by a third party with medium complexity. There are a
> substantial number of variations of this SecureRandom() class in
> various pieces of software, some with bugs fixed, some with additional
> bugs added. Products that aren't today vulnerable due to moving to
> other libraries may be using old keys that have been previously
> compromised by usage of SecureRandom().
>
>
> The most common variations of the library attempts to collect entropy
> from window.crypto's CSPRNG, but due to a type error in a comparison
> this function is silently stepped over without failing. Entropy is
> subsequently gathered from math.Random (a 48bit linear congruential
> generator, seeded by the time in some browsers), and a single
> execution of a medium resolution timer. In some known configurations
> this system has substantially less than 48 bits of entropy.
>
> The core of the RNG is an implementation of RC4 ("arcfour random"),
> and the output is often directly used for the creation of private key
> material as well as cryptographic nonces for ECDSA signatures. RC4 is
> publicly known to have biases of several bits, which are likely
> sufficient for a lattice solver to recover a ECDSA private key given a
> number of signatures. One popular Bitcoin web wallet re-initialized
> the RC4 state for every signature which makes the biases bit-aligned,
> but in other cases the Special K would be manifest itself over
> multiple transactions.
>
>
> Necessary action:
>
>   * identify and move all funds stored using SecureRandom()
>
>   * rotate all key material generated by, or has come into contact
> with any piece of software using SecureRandom()
>
>   * do not write cryptographic tools in non-type safe languages
>
>   * don't take the output of a CSPRNG and pass it through RC4
>
> -
> 3CJ99vSipFi9z11UdbdZWfNKjywJnY8sT8
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
>
>
>
>
> -- 
> Matías Alejo Garcia
> @ematiu
> Roads? Where we're going, we don't need roads!
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] KETAMINE: Multiple vulnerabilities in SecureRandom(), numerous cryptocurrency products affected.

[Mustafa Al-Bassam via bitcoin-dev]

And specifically, here's a version of it that uses Arcfour:
https://gist.github.com/jonls/5230850


On 09/04/18 22:11, Mustafa Al-Bassam wrote:
>
> Here's the code in question: https://github.com/jasondavies/jsbn/pull/7
>
> Best,
>
> Mustafa
>
>
> On 06/04/18 21:51, Matias Alejo Garcia via bitcoin-dev wrote:
>> Source? 
>>
>> On Fri, Apr 6, 2018 at 4:53 PM, ketamine--- via bitcoin-dev
>> > > wrote:
>>
>> A significant number of past and current cryptocurrency products
>> contain a JavaScript class named SecureRandom(), containing both
>> entropy collection and a PRNG. The entropy collection and the RNG
>> itself are both deficient to the degree that key material can be
>> recovered by a third party with medium complexity. There are a
>> substantial number of variations of this SecureRandom() class in
>> various pieces of software, some with bugs fixed, some with
>> additional
>> bugs added. Products that aren't today vulnerable due to moving to
>> other libraries may be using old keys that have been previously
>> compromised by usage of SecureRandom().
>>
>>
>> The most common variations of the library attempts to collect entropy
>> from window.crypto's CSPRNG, but due to a type error in a comparison
>> this function is silently stepped over without failing. Entropy is
>> subsequently gathered from math.Random (a 48bit linear congruential
>> generator, seeded by the time in some browsers), and a single
>> execution of a medium resolution timer. In some known configurations
>> this system has substantially less than 48 bits of entropy.
>>
>> The core of the RNG is an implementation of RC4 ("arcfour random"),
>> and the output is often directly used for the creation of private key
>> material as well as cryptographic nonces for ECDSA signatures. RC4 is
>> publicly known to have biases of several bits, which are likely
>> sufficient for a lattice solver to recover a ECDSA private key
>> given a
>> number of signatures. One popular Bitcoin web wallet re-initialized
>> the RC4 state for every signature which makes the biases bit-aligned,
>> but in other cases the Special K would be manifest itself over
>> multiple transactions.
>>
>>
>> Necessary action:
>>
>>   * identify and move all funds stored using SecureRandom()
>>
>>   * rotate all key material generated by, or has come into contact
>> with any piece of software using SecureRandom()
>>
>>   * do not write cryptographic tools in non-type safe languages
>>
>>   * don't take the output of a CSPRNG and pass it through RC4
>>
>> -
>> 3CJ99vSipFi9z11UdbdZWfNKjywJnY8sT8
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
>>
>>
>>
>>
>> -- 
>> Matías Alejo Garcia
>> @ematiu
>> Roads? Where we're going, we don't need roads!
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev