[ANN] bitaddress.org Safe JavaScript Bitcoin address/private key - page 43.

pointbiz

sr. member

Activity: 437

Merit: 415

1ninja

Quote from: nmat on September 21, 2011, 09:48:33 AM

Actually I am not using an iPhone. It's a 2G iPod Touch with iOS 4.2.1 (so yes, it is a slow device).

I'm glad Casascius can generate on his iPhone4. Unfortunately for my device and yours we are pretty much out of luck.

There is a technique to use setTimeout to split up the JavaScript work into batches so it doesn't trigger a browser timeout (for desktop browsers usually you get a popup asking if you want to stop the script or wait). This technique is useful when you can do bulk processing but it's not wise to implement this technique to facilitate 1 address generation because the execution path and variable scopes change when you call setTimeout.
It's mentioned here in the top answer:
http://stackoverflow.com/questions/4402012/avoiding-timeouts-on-iphone

Stephen Gornick

legendary

Activity: 2506

Merit: 1010

This is so close to having a low-tech Do-It-Yourself paper-based solution for merchants.

With this, the merchant pre-prints out a batch of these with the public-key only (and its QR Code) on paper (such as blank personal check paper stock) (see below)
http://www.amazon.com/VersaCheck-Refills-Personal-Wallet-Prestige/dp/B00134O78S

And then generated is the merchant's master (see below) to be kept secure which contains the public-key (& QR Code) and also the private key (& QR Code) for redeeming.

Then at the point of sale the cashier has a supply of these pre-printed "check" blanks with Bitcoin addresses (see below).

When the purchase occurs, the cashier fills in the amount and invoice # (or other identifier for matching to the point of sale transaction) and provides the check blank to the customer. The customer, using a mobile, scans the QR code and sends the bitcoins.

The merchant's back-office already has the address registered with BitcoinNotify.com so when payment is made (on 0/unconfirmed) an email (or SMS) is received.
- http://bitcoinnotify.com

The cashier places the check in the drawer as the customer has paid and proceeds with completing the sale.

After the shift, the merchant's bookkeeper matches up the checks from the drawer against the corresponding master which has the private key, scans the key and spends those funds to the merchant's master wallet / consolidation address. The "master" strip can then be stapled to the check and archived for records storage without having to further worry about securing the private key.

This could work.

Here's what I picture a batch of three checks looking like: [Edit: obviously, each of the three would have a unique bitcoin address code, but being lazy, I just did a copy and paste using the same code for all three]

And the merchant's masters corresponding to the checks:

casascius

vip

Activity: 1386

Merit: 1135

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

Quote from: Jan on September 21, 2011, 05:30:05 AM

You should always use a salt when generating a deterministic wallet. The salt should be globally unique and easy to remember. An email address has those properties, and makes a rainbow attack impractical. This wiki discusses how it is done for the BCCAPI: http://code.google.com/p/bccapi/wiki/SecurityAndDeterministicWallets
The BCCAPI is opensource and available here: http://code.google.com/p/bccapi/

I am not sure this applies in this case. Rainbow attacks help attackers take a large number of hashes and try to recover plaintext from as many as possible with the same effort. In wallet generation, the hashes are used as private keys which the attacker has no access to (or else if he gets the private keys, his attack has already succeeded, there's no value in recovering the plaintext itself). This advice is useful for someone operating a website and storing hashed passwords in a database, but I believe it has no application for wallet generation.

Although I agree that the linked wiki article discusses it and recommends the user enter a "salt"... what practical difference would there be between the user entering a "salt" into a separate field, versus simply appending some extra characters to their passphrase? They will be concatenated anyway, so none from what I can tell. Salt in most other contexts is not something chosen by a user, rather it is something added by an application outside the user's control.

nmat

hero member

Activity: 602

Merit: 501

Quote from: pointbiz on September 21, 2011, 01:55:54 AM

nmat, Debug Console huh... never noticed that option before. I confirm I see the timeout error, that would explain why I thought the try/catch wasn't working. I put a try/catch around generating the bitcoin address. It appears things are timing out in the "am3" function. I did notice in Safari 3.2.3 for Windows generating was painfully slow so I'd assume the iPhone Safari is processing the JavaScript at a snail's pace and timing out.

The mouse thing would cause trouble on an iPhone but I implemented a timeout which forces the bitcoin address generation after a few seconds and I confirmed that code it being called, the private key gets generated but things timeout when trying to create the public key. I checked on the older versions and they all timeout on Safari Mobile 4.

Actually I am not using an iPhone. It's a 2G iPod Touch with iOS 4.2.1 (so yes, it is a slow device).

Jan

legendary

Activity: 1043

Merit: 1002

Quote from: pointbiz on September 15, 2011, 07:29:29 PM

At the moment I'm not convinced Deterministic Wallets are the way to go. People think alike and therefore the algorithms and patterns used to make Deterministic Wallets can be gamed en mass.

Consider these two possible wallet decisions:
1) using a 5-character password to create a Deterministic Wallet using some tool.
2) create a truly random private key and copy/paste it into a text file in an encrypted true crypt drive, that is protected with a 5-character password, that you back up in several locations online and offline.

In scenario #1 someone can turn their GPU farm to silently create a bunch of Deterministic Wallets and check them against the blockchain. Only 1 person has to have an easy password for this attack to work and it's more likely to be a profitable attack.

In scenario #2 someone has to personally hack you then make childs play of your password. Much less likely to happen and more expensive for an attacker. Your 5-character password is much safer on your computer or on dropbox then in the blockchain for anyone to brute force. Maybe I could enforce a minimum password size and minimum complexity.

All that being said thank you for the suggestion, I see there will probably be demand for this type of feature. It's definitely a complimentary feature that would make sense on bitaddress so I'll consider it in the future.

You should always use a salt when generating a deterministic wallet. The salt should be globally unique and easy to remember. An email address has those properties, and makes a rainbow attack impractical. This wiki discusses how it is done for the BCCAPI: http://code.google.com/p/bccapi/wiki/SecurityAndDeterministicWallets
The BCCAPI is opensource and available here: http://code.google.com/p/bccapi/

casascius

vip

Activity: 1386

Merit: 1135

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

I am able to generate addresses on my iPhone 4... it is a bit slow but not unreasonable. Couple of seconds.

pointbiz

sr. member

Activity: 437

Merit: 415

1ninja

Casascius, yes, I was thinking of the iPhone screenshot capability.

nmat, Debug Console huh... never noticed that option before. I confirm I see the timeout error, that would explain why I thought the try/catch wasn't working. I put a try/catch around generating the bitcoin address. It appears things are timing out in the "am3" function. I did notice in Safari 3.2.3 for Windows generating was painfully slow so I'd assume the iPhone Safari is processing the JavaScript at a snail's pace and timing out.

The mouse thing would cause trouble on an iPhone but I implemented a timeout which forces the bitcoin address generation after a few seconds and I confirmed that code it being called, the private key gets generated but things timeout when trying to create the public key. I checked on the older versions and they all timeout on Safari Mobile 4.

nmat

hero member

Activity: 602

Merit: 501

Quote from: pointbiz on September 21, 2011, 12:38:00 AM

A cellphone might be a good place to use this for a disposable address if someone wants to pay you and you don't have a bitcoin wallet handy.

I tested on a physical iPhone 3G Safari 4 and it doesn't work. I tested on Safari 3.2.3 for Windows and it works.
It appears that the Mobile Safari doesn't even support try/catch properly so there is little chance I can get this thing working on an iPhone.

Do you have Safari Mobile 4 or 5 ?

I didn't thought of that. Interesting idea.

It's version 5. I enabled debug console and it shows an error after a while:

Quote

JavaScript Error on Line 1334
JavaScript execution exceeded timeout

I'm pretty sure it worked before you introduced the mouse thing.

casascius

vip

Activity: 1386

Merit: 1135

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

On a cell phone, how would you use such a thing?

On an iPhone you can take a screenshot by pressing both hardware buttons... do you mean that? If so, that's an unusual way to do it, though it would work. Otherwise, the private key will disappear as soon as you touch the window and the funds will be gone.

What part of the code necessitates a try/catch?

pointbiz

sr. member

Activity: 437

Merit: 415

1ninja

Quote from: nmat on September 18, 2011, 09:46:01 AM

Hum... It doesn't work on my iPhone. Maybe because I can't move my mouse around? Tongue

It hangs on "Generating Bitcoin Address...".

Anyway, a cellphone probably isn't the best place to use this.

A cellphone might be a good place to use this for a disposable address if someone wants to pay you and you don't have a bitcoin wallet handy.

I tested on a physical iPhone 3G Safari 4 and it doesn't work. I tested on Safari 3.2.3 for Windows and it works.
It appears that the Mobile Safari doesn't even support try/catch properly so there is little chance I can get this thing working on an iPhone.

Do you have Safari Mobile 4 or 5 ?

nhodges

sr. member

Activity: 322

Merit: 251

Quote from: casascius on September 20, 2011, 12:17:53 AM

Random suggestion: Your donation address shouldn't be a QR code. You might get random donations if someone's scanner accidentally picks it up, but the problem is that those donations would be unintended and undesirable.

Android wallets autosend? There's no, "Hey, you're about to send 5 BTC to x" feature? I thought instapay was what NFC was for, not QR codes. Tongue

pointbiz

sr. member

Activity: 437

Merit: 415

1ninja

Quote from: casascius on September 20, 2011, 12:17:53 AM

Random suggestion: Your donation address shouldn't be a QR code. You might get random donations if someone's scanner accidentally picks it up, but the problem is that those donations would be unintended and undesirable.

v0.6
http://www.bitaddress.org/bitaddress.org-v0.6-SHA1-1cea2d8c437d49c550b9ec1cfc5d02ac85e8199e.html
-Removed QRCode donation address

casascius

vip

Activity: 1386

Merit: 1135

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

Random suggestion: Your donation address shouldn't be a QR code. You might get random donations if someone's scanner accidentally picks it up, but the problem is that those donations would be unintended and undesirable.

pointbiz

sr. member

Activity: 437

Merit: 415

1ninja

v0.5

http://www.bitaddress.org/bitaddress.org-v0.5-SHA1-7ea8d0e32c3583d369dc4079443e0d6e215ac216.html

2011-09-19: status ACTIVE
bitaddress.org-v0.5-SHA1-7ea8d0e32c3583d369dc4079443e0d6e215ac216.html
-DO NOT USE VERSION 0.1 TO 0.4! They infrequently could generate bad keys.
-Bug Fixed: v0.1 to v0.4 included a bug in the Elliptic Curve function:
ec.PointFp.prototype.getEncoded
The X and Y integers that were less than 32 bytes were not being zero padded.
They are now zero padded which fixes the bug in generating public keys.
-Bug Fixed: v0.3 and v0.4 had a bug in the Wallet Import Format function:
ECKey.prototype.getBitcoinWalletImportFormat
Private keys there were less than 32 bytes were not being zero padded.
They are now zero padded which fixes the bug in generating private keys.
-Requires IE8+, Firefox, Chrome or sufficient JavaScript support.
-Added function to build a CSV list of addresses and keys.
Not supported in the GUI yet.
-Added a timeout to override the mouse move detection. Therefore, if the user
has not moved his mouse before a certain random expiry the address and key
will then be generated. This helps for mobile devices.

casascius

vip

Activity: 1386

Merit: 1135

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

I tested the CSV file of 10,000 addresses you sent me (pointbiz) and all of them passed. Woo hoo!

pointbiz

sr. member

Activity: 437

Merit: 415

1ninja

Quote from: nmat on September 19, 2011, 08:49:36 PM

Quote from: dooglus on September 19, 2011, 08:45:23 PM

Quote from: pointbiz on September 18, 2011, 07:06:48 PM

Thanks for the bug find... I'm working on it.
Please don't use v0.1 to V0.4

Perhaps you should edit your first post in this thread to say that. I had to get to page 3 before seeing any kind of a warning.

Or put it offline for the time being.

Sorry guys, I goxed on that. The site is down until the fixed version is live. V0.1 to V0.4 are permanently down. Please don't send BTC to addresses you generated with those versions unless you've double checked the private key and bitcoin address with pywallet or something else. Only a tiny percentage of addresses were bad. However, only zero percent is acceptable. My apologies.

nmat

hero member

Activity: 602

Merit: 501

Quote from: dooglus on September 19, 2011, 08:45:23 PM

Quote from: pointbiz on September 18, 2011, 07:06:48 PM

Thanks for the bug find... I'm working on it.
Please don't use v0.1 to V0.4

Perhaps you should edit your first post in this thread to say that. I had to get to page 3 before seeing any kind of a warning.

Or put it offline for the time being.

dooglus

legendary

Activity: 2940

Merit: 1330

Quote from: pointbiz on September 18, 2011, 07:06:48 PM

Thanks for the bug find... I'm working on it.
Please don't use v0.1 to V0.4

Perhaps you should edit your first post in this thread to say that. I had to get to page 3 before seeing any kind of a warning.

pointbiz

sr. member

Activity: 437

Merit: 415

1ninja

Preview of patched function:

Code:

// patched by bitaddress.org and Casascius for use with Bitcoin.ECKey
ec.PointFp.prototype.getEncoded = function () {
	var x = this.getX().toBigInteger();
        var y = this.getY().toBigInteger();
        var len = 32; // integerToBytes will zero pad if integer is less than 32 bytes. 32 bytes length is required by the Bitcoin protocol.
        var enc = ec.integerToBytes(x, len);
        enc.unshift(0x04);
        enc = enc.concat(ec.integerToBytes(y, len));
        return enc;
};

The integerToBytes function has a while loop to pad the zeros, so we should be okay if there needs to be more than 1 leading zero byte.

Code:

ec.integerToBytes = function (i, len) {
        var bytes = i.toByteArrayUnsigned();
        if (len < bytes.length) {
        	bytes = bytes.slice(bytes.length - len);
        } else [b]while (len > bytes.length)[/b] {
        	bytes.unshift(0);
        }
        return bytes;
};

Thank you for the fix for the private key as well!! I will work on getting this patched up and send you a PM with a big CSV.

casascius

vip

Activity: 1386

Merit: 1135

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

This might be the answer to your other issue:

See current code:

Code:

            // Sipa Private Key Wallet Import Format
            ECKey.prototype.getBitcoinWalletImportFormat = function () {
                // Get a copy of private key as a byte array
                var bytes = this.priv.toByteArrayUnsigned();
      ////////////// right here ////////////////
                bytes.unshift(0x80); // prepend 0x80 byte
                var checksum = Crypto.SHA256(Crypto.SHA256(bytes, { asBytes: true }), { asBytes: true });
                bytes = bytes.concat(checksum.slice(0, 4));
                return Bitcoin.Base58.encode(bytes);
            };

Where I have marked "right here", I think the problem would be solved if you added this line:

while (bytes.Length < 32) bytes.unshift(0x00);

(assuming bytes.Length is how you get the number of bytes in the array? I don't do much javascript)

When done, if you (or TTBit, thanks) can send me a large CSV file full of private keys with bitcoin addresses generated by this updated code, I already have some test code ready to verify them. Send me 10,000 or more if possible.

Topic: [ANN] bitaddress.org Safe JavaScript Bitcoin address/private key - page 43. (Read 153002 times)