HN user

kgo

829 karma
Posts3
Comments245
View on HN

Anyone can create a random key with a random email. See all the president@whitehouse.gov addresses on the keyservers. So if they used the keyserver network I could just make a fake key for anyone I want to impersonate and upload it. Github has no way to authenticate which keys are good and bad if they only use the keyserver network. So they have you upload the key on their site to implicitly authorize the key as one that you (the person with the github account, or at least its password) consider valid.

http://pool.sks-keyservers.net/pks/lookup?op=vindex&search=p...

Keybase lets you do some key stuff, but the bigger feature is that it provides a bunch of ways to authenticate the source of a key above and beyond the WoT and getting into the strong set. Authentication is an inherently hard problem. With keybase you can, for example, see that the key that you want to use to send an encrypted email to x@example.com's website is owned by someone who also controls x@example.com's twitter, reddit, github accounts, web-site, etc, making it less likely that there's a MiTM going on.

It depends on whether they use PGP/MIME or inline PGP. Without installing the tool, I'm guessing they use PGP/MIME, because you pretty much can't use html email with inline PGP, and I doubt they're going to default to plain/text mails.

Heartbleed 12 years ago

Well the odds are non-zero. If you're worried about intelligence agencies harvesting your private keys, any odds above 0 is close to 1.

Dai/Nakamoto emails 12 years ago

Actually the current guidelines are pretty clear. Mining is income. When you receive your coins from mining, that's a taxable event. Current value - mining expenses = income. After that any gains or losses are unrealized until you sell, creating another taxable event. Current price - cost basis = capital gains. Since bitcoins were worthless when Nakamoto was mining, he has no tax bill there. No taxes are owed for simply holding the coins. If he sold today, he'd be taxed at the long term capital gains rate of 15% for 100% of what he sold.

EDIT: but of course I'm making the silly mistake of assuming he's an American.

Inflation adjusted, that would put him in the range of Rockefeller, Carnegie, Vanderbilt, Mellon, etc. If (and it's a big if) bitcoin was worth as much as the world gold market, it isn't disruptive like an internet startup, it's disruptive like Marxism. We could argue about the insanity suggesting that bitcoin will reach that sort of value, but if it somehow did, then $500 billion isn't totally out of line.

True, but they were able to process a single quarter-million dollar transaction and easily turn that into 'real' cash. That's still a pretty decent accomplishment for magic internet money.

Switzerland has its own currency and its own central bank. It doesn't use the Euro. So the money doesn't need to 'paid for'. The government can just create the money and hand it out.

Of course this might devalue the currency as a whole, but the central bank had to institute an exchange rate floor because Francs were becoming too expensive relative to the Euro. So they probably wouldn't even consider a minor devaluation a bad thing.

These guys are complaining about disk space and bandwidth, not message security.

Even so, the current network can probably handle 100,000 messages a day, and the bottleneck there is some side channel timing attack mitigation code that causes the client to sleep while syncing with a peer. If you separate out the message syncing from the decryption process and eliminate the timing attack potential, the network can easily scale to a million messages a day or more.

At that point, the messages will need to be broken into 'streams' so that you can partition the traffic. The protocol supports this, but punts on the implementation details, so there's no easy way to implement multiple streams at this point in time.

But I would hardly describe that as full-on 'fail'. Everyone-shares-everything is a design feature to preserve anonymity. It's more difficult to tell who sent a message, who received it (if anyone), who was able to read it (if anyone), etc.

Reading more on this software, it seems like they try to solve the capacity/bandwidth problem by using a distributed hash table, but now the protocol requires a lot of handshaking with specific machines that has potential to remove some anonymity, and also potentially makes it easier to prevent a user from getting messages. Block enough traffic at the Great Firewall and you might not be able to get messages. [Take the above listed weaknesses with a grain of salt, I haven't done an in-depth look at the protocol.]

But in general it's probably premature to worry too much about scaling, since the bitmessage network can already handle several more orders of magnitude than the current traffic levels:

http://vps1.adammelton.com/

This seems very similar to bitmessage, which has a functioning client and 1000's of active nodes. Why would I wait for this instead of using bitmessage?

The problem is that you don't sent to the destination SMTP server. You send to your SMTP server. That goes at least one hop via SMTP and eventually ends up on the destination's domain server.

So even if I setup and host my own SMTP server, and even if I verify the TLS certs on my side, I have no way to verify that I'll get (1) A TLS connection (2) with an authenticated cert all the way to the ultimate destination.

It's beyond my control to ensure that I'm secured when emailing to an arbitrary domain with arbitrary configuration.

Meanwhile, per the Washington Post article, he asked the guardian to setup PGP in Feb, and his contact finally did so in March, both before this key's listed creation date.

Okay, so lets assume that the NSA has quantum computers that can decrypt RSA and ECC with ease. They would have to assume another state funded effort by someone like China could do so as well. Then the NSA wouldn't issue recommendations that the US Government itself use these encryption methods for TOP SECRET and CONFIDENTIAL documents.

An actual pyramid scheme involves you giving a cut of your profits to the person who signed you up, and getting a cut of profits from people you sign up. Nothing remotely like this happens with bitcoin.

Similarly it's not a Ponzi scheme because it doesn't involve the fraudulent transfer of new capital into fictional profits. Nothing remotely like this happens with bitcoin.

If we alter the definition of pyramid scheme so that Bitcoin qualifies, that definition would match every successful startup company.

Current Market Cap is at $1 billion.

Let's say all bitcoin becomes is a paypal killer.

Paypal had a total payment volume of $145 billion in 2012. Now you can't just say a fair value for bitcoin's market cap is $145 billion because that doesn't take money velocity into account. Some of that volume could be the same dollars floating around. You don't need $145 billion in cash all at once to cover that activity. But paypal's revenue was $5.6 billion. So the amount bitcoin needs to be worth to handle the same amount of business as paypal is somewhere between those two numbers, and even a low $10 billion prices bitcoins at $1000 each.

Visa Inc had a total payment volume of $6.4 Trillion in 2012. Of course in addition to figuring out the actual money velocity you need to remove the credit component since bitcoin doesn't do that. But some sketchy back-of-the-envelope math can demonstrate that a $100 billion dollar market wouldn't be unheard of, with $10,000 bitcoins.

Of course I'm talking like 10-20 years out for anything like that, not today.

The Start-Up Trap 13 years ago

"Of course one of the disciplines I'm talking about is TDD. Anybody who thinks they can go faster by not writing tests is smoking some pretty serious shit."

Why do so many TDD people think that people who don't use TDD don't write tests?

Basically because a proper X.509 implementation requires a CA to be in place first, so you have a place to submit a CSR, but there is no CA, so you're forced to self sign. I've written a rant on the topic here:

http://www.rubygems-openpgp-ca.org/blog/gem-signing-x509-and...

I've been trying to get people to sign with OpenPGP because that can be done first and then you can put an authentication system into place after the fact. You can't do this with X.509, if/when a CA comes into play all gems would need to be resigned and republished.

Yep, you can do WoT with X.509 if you write the semantics from scratch, and you can also do a CA approach with OpenPGP.

The thing is, for years no-one has stepped in and actually gone through the pesky little details of implementing all those semantics for rubygems via X.509 even though it's come up repeatedly. But maybe someday some expert will come along and fix things.

If you actually read the rubygems documentation on signing gems, it's pretty much "Okay generate your own self-signed key, then sign it with your self-signed key." That leaves a lot to be desired vs best practices. There isn't even an attempt to describe how you get your self-signed keys to users.

I just think leveraging the existing OpenPGP semantics, ecosystem, and battle-hardened gnupg codebase, is a lot easier than implementing an entire system from scratch on X.509 just because openssl is already installed everywhere and ruby has better bindings and gnupg is not and does not.

I'm just trying to take the approach you usually preach: Don't roll your own crypto code and leave the real work to the pros, and it seems like gpg offers a lower path of resistance.