Was randomly recommended a video on YouTube a few weeks ago which was a recording of a tour of the WLW broadcast transmitter facility. You get to see the high power equipment in detail accompanied by lots of history about the facility. Was a fun watch.
From what I remember poking around at Hansa that's not true. Each vendor / user had a public key associated with their account. All text communication through the website was supposed to be with GPG encrypted text secured by private keys unavailable to website.
So law enforcement has lots of encrypted text along with some clear text from users not informed enough to follow any kind of opsec.
Law enforcement could have easily MITM'd the PGP.
They replace the public key of a vendor with their own public key (on the vendors's page, without the vendor's/buyer's knowledge), then the buyer address gets encrypted with that public key. Then they decrypt and resend the message using the sellers original public key.
They almost certainly did. I do market research and a number of vendor keys changed on Hansa and Dream on June 23rd. Some had various comments in them claiming to be older, e.g. "EST June 2016".
I'm a developer on the OpenBazaar project which is a p2p Bitcoin market. Because DNMs are the most popular Bitcoin marketplaces I keep up with them and their features and trends. They're great sources for discovering security concerns.
Can you give an example of some of the security concerns you have discovered? Do you keep a formal list of threat vectors? I would have thought they are pretty much the same as regular web apps.
PS. OpenBazaar seems to have received $3M funding. Interesting about change for a project started by Amir Taaki given his very anarchist professions.
PPS. Desktop client seems a bad thing to develop first (in the true tradition of Bitcoin!). Perhaps you guys could have stuck with network client daemon + API for starters. Anyway, good luck.
Furthermore, in order to lower the risk of anyone detecting this here's something the LEO could do:
1. They seize control of the servers.
2. They make note of who is an existing user and keep serving them the real PGP keys of other pre-existing users.
3. For anyone who registers after the point in time where LEO controls the servers, replace the PGP keys of sellers and also the keys of these new users with MITM key pairs.
Then when they run the site for a month as they did and they have the influx of users they got from AlphaBay, they will have plenty of evidence on all of the sellers that are active during that period of time due to there being so many new users all of whom you are MITMing, regardless of whether the sellers are new or old because the old sellers are also being MITMed in all exchanges they have with new users.
The sellers were the primary target of interest, so the LEO got what they wanted.
All of what I said is just something they could have done though. Not saying that it's what they actually did.
The impression that I get is that after they busted Alphabay, they nabbed a number of sellers and possibly some large buyers, who were held incommunicado. When there was a big migration from Alphabay to Hansa of both customers and sellers, there was an opportunity to set up many of those sellers' entire presence from scratch there. So it wasn't just the site that was compromised, but many of the largest individual sellers themselves, physically.
Of course, I know nothing and have just heard of either of those sites this morning.
While I doubt that many people check the vendor's public keys, it would just take one person to notice that a vendor has a different public key from another site (for example, AlphaBay, since there must have been lots of users moving to Hansa from there). If they questioned the vendor about it, they'd discover something was wrong. This would then blow the cover of the police, or at the very least be a big red flag showing that the site had been hacked.
In short, I doubt the police did this kind of thing because they risked blowing their cover for the sake of getting some buyers' addresses.
Also, these sites tend to have a big button labelled 'encrypt my message' - which ostensibly does all the PGP for you. I'd guess that most people are lazy and just press this instead of running PGP/GPG manually. It would be trivial for the police to capture the unencrypted messages just by subverting the auto-PGP.
Then users looking at their accounts from other logins would see the wrong public key and know something was wrong. Also wonder if that happened at all
The only reason I mention that this is at all probable is because of the length of a PGP key. How often is the average user of a site like this logging in to verify even the last few bytes of a PGP pub key compared to what is saved in their software? Plus how many users would chalk it up to "oh SellerX just changed their key pair" and continue on encrypting their message with the new key
I highly doubt anyone looked at it or cared. People were most likely on there to buy drugs. Do you think they turned to their friend and asked "hey do you mind looking into this website and comparing the PGP keys with me? I just want to be sure!"
This has me curious (as a complete crypto noob): how would one defend against such a MITM attack in general?
Only send messages to vendors with known "trusted" keys and don't trust new keys? So in general, use a trusted channel for key exchange separate from the communication channel so that a MITM needs to control both channels?
Correct. This is what the PGP "web of trust" is supposed to assist with: a trusted key is either one which you have verified, in person, as belonging to your correspondent, or one which has been signed by a number of other correspondents whom you trust to verify keys (and whose keys you have verified in person).
Using a standard channel for public key exchange is half the battle. The other half is using a trusted channel to verify the public key does indeed match the public key you were originally sent. "Trusted channel" can be broadly interpreted (and is also often subject to tampering as well)
They can't MITM secure email from buyers to vendors (the direction with actual physical addresses) unless they subvert either the buyers or vendors email server. The actual email does not go through the site.
This is true, but if they had taken over the site, they could decrypt anything that the site had 'encrypted' (some sites let you either encrypt stuff yourself, or let the site do it for you... which isn't a very sensible option)
They did exactly this on Hansa. They also used this same method to break the multisig transactions that hansa used to direction bitcoins directly to LE wallets (The dutch say 2million euros worth)
The 5th covers several rights of a person accused of a crime. In this context they are referring to the amendment's protection against self incrimination: "nor shall be compelled in any criminal case to be a witness against himself."
A person has the right to decline to answer questions if they believe that their answers could be used against them as evidence of a criminal act. This particular proceeding is civil rather than criminal so its outcome can't result in any criminal convictions. However, if he were later to be charged with a crime and tried in a criminal court any testimony he gave in this civil action could be used against him as evidence in the criminal trial.
I come to the HN web site on slow work days or when I need a breather and generally look at front page stories or glance over the Ask HN list.
I noticed what seemed like a pattern: stories with a high ratio of points to comments were often more valuable and the discussions more interesting. Entries with more comments than upvotes are frequently pop culture-y or bike shedding discussions.
So to try and see a "best of" without lower value discussions I threw together a Twitter feed that lists stories with high points and a high point to comment ratio: https://twitter.com/HighSNHN
Once closure happens the bill heads into markup behind closed doors where the sausage making starts.
These bills are still very much on track. People need to be on the phones to their senators urging a no vote on closure so that the debate can happen in public with input from both sides.
Yesterday had some impact, but these bills are still very much on track to become law. All the post mortems today aren't communicating that very well.
The closure vote in the Senate on the 24th needs at least 41 no votes to prevent the bill from moving into markup. While more senators have announced opposition or doubt, current headcounts put "no" votes on closure only in the single digits.
Unlike subcommittee hearings, the markup hearings are closed door and allow the Senate to draft a final version of the bill without public scrutiny or testimony from tech leaders. If this legislation follows suite with other controversial legislation, the bill that emerges will have enough back room deals attached to let both the latecomer opposition and the White House to declare the bill a healthy compromise irregardless of the facts.
People need to be on the phone to their senators. Urge them to vote no on closure so that the inevitable compromise bill can be debated in public with input of experts.
Additionally, the lobbying groups aren't about to stop lobbying suddenly. It just means that they need to try harder. I wouldn't be shocked in the least to find some well funded senator trying to slide some of the language from this bill into a "must pass" 10,000 page budget bill.
What's scary enough is that some of this will get through in some way or another eventually.
So perhaps the best way to appease the lobbying companies would be to pass SOPA, but remove the most destructive pieces first. Perhaps narrowing the definition of an infringing or "rogue" site would be a good start.
I think its a good idea and will give it a try next time I need to spin up a theme.
Ignore the negativity in these comments. This is a great example of scratching your own itch and being generous enough to place it on Github. Who cares if the bulk of WordPress users won't grok it? That's no reason not to build it. Thanks for sharing.
Besides entertainment value doesn't all of this back and forth reduce down to the age old "use the right tool for the job in front of you"?
Node.js as it currently stands isn't the best solution for applications that will involve CPU intensive tasks. Perhaps at the outset of a project you don't know when and where those types of tasks will pop up so basing an entire architecture on it might be risky.
However, it seems to me that regardless of the above, there are tasks Node excels at and it would be silly to dismiss it as a technical solution all together. I'm building browser based games with it and love working with Node. The bulk of the logic is in the client and Node serves as the glue that allows people to play games together from different clients. Nothing I have read gives me pause about this implementation.
https://www.youtube.com/watch?v=CbHjcwIoTiY