Saw this post on stackexchange:

http://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters

and an article on Slashdot today:

http://it.slashdot.org/story/13/09/11/1224252/are-the-nist-standard-elliptic-curves-back-doored

I'm pretty sure bitcoin uses ECC for public/private keys.  Does it use the NIST FIPS 186-3 standard numbers?  and if so, is there any concern among the developers about a possible NSA backdoor?

I've been thinking about how an exchange could handle bitcoins securely as part of a side project I'm working on. 

Using an encrypted wallet on a firewalled non-public-facing machine seems like an obvious first step.  I'm also thinking about how to secure the application itself such that even if the app server and database were rooted, an attacker with full knowledge of the system still could not exploit it in a way that would cause coins to be lost.

So, here are my initial thoughts on how this might work.  I'm sure I'm missing something here, so I'd love it if any security experts could comment on any holes that might exist in this system:

1.  The server will have a 256-bit AES key derived from a password and a salt.  This will not be stored anywhere in the system.
   a. Password will need to be provided at application startup to "bootstrap" the app and generate the key.

2.  The server will have a 2048-bit RSA key that it will use to sign transactions in the system.
   a. The public key will be stored as plain text in a config file.
   b. The private key will be stored encrypted in a config file using the server AES key.

3.  Each user will have a 256-bit AES key derived from their password and a salt.  This will not be stored anywhere in the system.
   a. Note that this will change every time they change or reset their password.

4.  Each user will have a 2048-bit RSA key associated with their account and stored in the database.
   a. The public key will be stored in the database as plain text.
   b. The private key will be stored in the database encrypted using the user's AES key.
   c. When a user's password is changed or reset, a new RSA key will be created for the user.
      i. The old RSA key will remain valid for transactions created before the date the new key was created.  This is to ensure that in-process
         transactions (orders, withdrawals, etc.) that were signed with the old key can still be processed.
   d. The association of a key to a user will be digitally signed by the server (hash of userid + encrypted private key + public key + timestamp).
      i.  This is to prevent a user with database access from tampering with a key or associating their own key to another user
          in order to fake a signed transaction from that user.

5.  A user will be able to submit a signed bitcoin withdrawal request.
   a.  The request will be signed with the user's private key hash of (id + userid + amount + to address + timestamp)
      i.  By itself, this is vulnerable to replay attacks.  See 6(b) for solution to mitigate this risk.

6.  Requests will actually be processed by another app + bitcoind running on a separate firewalled machine with all incoming ports blocked and access only via console.
   a.  Before processing a request, the app will validate the request signature.
      i.   Calculated hash of (id + userid + amount + to address + timestamp) in request matches signed hash.
      ii.  Key used to sign the request actually belongs to the user associated with the request.
      iii. Key used to sign the request was valid as of the timestamp on the request.

   b.  The processing app will keep a separate local database with the ids of all processed transactions. 
      i.   Before processing a transaction, it will first verify that the transaction was not already processed. 
      ii.  If it was, the transaction will be rejected.  This is to protect against replay attacks.

So that covers withdrawals.  Other transactions (orders, trades, deposits, any other transactions that manipulate account balances) would be handled in a similar fashion with transactions either signed by the user submitting them or signed by the server itself.  The idea is that the server should always be able to provably audit transactions and account balances to ensure they have not been manipulated (even if a hacker had compromised the database itself)

http://it.slashdot.org/story/12/05/26/033242/hacked-bitcoin-financial-site-had-no-backups

Anyone know why the Intersango GBP market seems to be consistently overpriced relative to the USD market?  I've noticed this for at least the past month or so. 

For instance, right now the Gox USD price is $5.18 and the Intersango GBP price is 3.31 which according to Google is $5.30.  So Bitcoins on the Intersango GBP market are overpriced by about 2.5%, which is pretty consistent with what I've been seeing just about every day for at least a month.

I'm working on a concept for a Bitcoin exchange that works exactly like a regular exchange, but without real money or real bitcoins.  You would simply get an automated deposit of currency and/or bitcoins daily with which to trade.  The idea is that you could use this to test out trading strategies or bots in a realistic environment without putting any real money at risk.

Main features:

• A website (trading page, accounts, order book, graphs, etc.) - everything you would expect at a regular bitcoin exchange.
• A fully featured REST/JSON trading API along the same lines as Gox, CryptoXChange, Intersango etc.
• Automated "order monkeys" that copy orders from the major exchanges.  This would provide a full order book and liquidity even if no "real" people are trading.
• Possible competitions with prizes for winners (best return over X days, etc.  kind of like Motley Fool CAPS)
• Semi-public account information (e.g. public leaderboard(s) or rankings to show which users have the best performance, again, similar to CAPS)

Would this be something that anyone would be interested in using?  Anything else you'd like to see (or not see)?

Just tried to log in and got an invalid username/password error.  I'm certain I got the u/p right, and it was working fine just a couple hours ago.

Anyone else having problems, or is it just me?

I think I've noticed a bug on Mt. Gox, but figured I'd post it here to see if others have seen this or if I'm just imagining things.

If you have an order that gets split because of insufficient funds, and the part that you have funds for gets executed, the other part disappears.

So, for example, lets say you have an order to sell 100 BTC @ 2.50, but you only have 50 BTC in your account.  On the trades screen you'll see the order split in two - an "active" 50 BTC order and an "insufficient funds" 50 BTC order.  If someone bids 2.50 and the active 50 BTC of the order is filled, the "insufficient funds" part of the order will mysteriously disappear.

Anyone else notice this behavior?  I'm pretty sure I've seen it 5 or 6 times at least on my account over the past few weeks.

I seem to be getting timeouts with TradeHill.  Can anyone get in?

Anyone know whats up with CampBX?

I can get to the site eventually, but seems like none of the CSS/Javascript actually loads.  Anyone else having trouble with it?

Didn't see this posted anywhere else, but has anyone else noticed that ExchangeBitcoins.com is no longer accepting Dwolla?  And not just for deposits, but for withdrawls as well.  I appreciate the solidarity with TradeHill, but withdrawls too?