Silk Road forums
Discussion => Security => Topic started by: dillondillon on August 13, 2012, 08:00 pm
-
After Wiki Leaks publishing more Stratfor emails leaked by Anonymous, Trapwire has been getting a lot of attention in the past couple days. One of the things unearthed is Anonymizer may have been a honey pot all along...
Breaking: Trapwire surveillance linked to Anonymizer and transport smart cards
https://darkernet.wordpress.com/2012/08/13/breaking-trapwire-surveillance-linked-to-anonymizer-and-transport-smart-cards/
-
My biggest fear is that services that mix bitcoins turn out to be honey pots. Really hope there comes a way to mix them with security by design without needing to hope that the service is not a honey pot.
-
My biggest fear is that services that mix bitcoins turn out to be honey pots. Really hope there comes a way to mix them with security by design without needing to hope that the service is not a honey pot.
Blind mixing allows coins to be mixed without the mix operator being able to gain any information even if they are malicious. I think I am going to implement a blind mix right now actually, maybe I will charge a bit to use it or maybe I will give it to SR to run and hope he compensates me a little.
-
One can never be truly sure if the Operator of such services are "legit".
CYA - Always use multiple sources to "wash" coins that may come from questionable sources.
As per usual it comes down to what type of threats you might be facing...
-
My biggest fear is that services that mix bitcoins turn out to be honey pots. Really hope there comes a way to mix them with security by design without needing to hope that the service is not a honey pot.
Blind mixing allows coins to be mixed without the mix operator being able to gain any information even if they are malicious. I think I am going to implement a blind mix right now actually, maybe I will charge a bit to use it or maybe I will give it to SR to run and hope he compensates me a little.
Thing is. How to prove to somebody who has just arrived at your service that this is indeed a blind signature mix, and not just a regular bitcoin laundry service? Somebody with no programming knowledge to audit open source code? Otherwise there's no comparative advantage for a blind sig over a normal mix, because you're back to trusting 'authority' i.e. other SR people or the mix owner that it all works according to plan. Maybe I haven't read the work on blind signature mixers properly, but if I'm right, then this is serious problem for anybody implementing a mix.
Also, it would need to be tested per mix cycle in case a LE agent was doing a bait 'n switch with a blind signature mixer and a normal mix. Block chain looks the same, but you're potentially linkable to a transaction if your anonymity is compromised.
Surely somebody like Chaum already came up with a solution to this?
-
My biggest fear is that services that mix bitcoins turn out to be honey pots. Really hope there comes a way to mix them with security by design without needing to hope that the service is not a honey pot.
Blind mixing allows coins to be mixed without the mix operator being able to gain any information even if they are malicious. I think I am going to implement a blind mix right now actually, maybe I will charge a bit to use it or maybe I will give it to SR to run and hope he compensates me a little.
Thing is. How to prove to somebody who has just arrived at your service that this is indeed a blind signature mix, and not just a regular bitcoin laundry service? Somebody with no programming knowledge to audit open source code? Otherwise there's no comparative advantage for a blind sig over a normal mix, because you're back to trusting 'authority' i.e. other SR people or the mix owner that it all works according to plan. Maybe I haven't read the work on blind signature mixers properly, but if I'm right, then this is serious problem for anybody implementing a mix.
Also, it would need to be tested per mix cycle in case a LE agent was doing a bait 'n switch with a blind signature mixer and a normal mix. Block chain looks the same, but you're potentially linkable to a transaction if your anonymity is compromised.
Surely somebody like Chaum already came up with a solution to this?
Chaum invented the first blind mix. The client software can verify that the signature is blind, so you really are not trusting anything other than the implementation of the client. Oh yeah, blind mix would need specialized client side software.
-
My biggest fear is that services that mix bitcoins turn out to be honey pots. Really hope there comes a way to mix them with security by design without needing to hope that the service is not a honey pot.
Blind mixing allows coins to be mixed without the mix operator being able to gain any information even if they are malicious. I think I am going to implement a blind mix right now actually, maybe I will charge a bit to use it or maybe I will give it to SR to run and hope he compensates me a little.
Thing is. How to prove to somebody who has just arrived at your service that this is indeed a blind signature mix, and not just a regular bitcoin laundry service? Somebody with no programming knowledge to audit open source code? Otherwise there's no comparative advantage for a blind sig over a normal mix, because you're back to trusting 'authority' i.e. other SR people or the mix owner that it all works according to plan. Maybe I haven't read the work on blind signature mixers properly, but if I'm right, then this is serious problem for anybody implementing a mix.
Also, it would need to be tested per mix cycle in case a LE agent was doing a bait 'n switch with a blind signature mixer and a normal mix. Block chain looks the same, but you're potentially linkable to a transaction if your anonymity is compromised.
Surely somebody like Chaum already came up with a solution to this?
Chaum invented the first blind mix. The client software can verify that the signature is blind, so you really are not trusting anything other than the implementation of the client. Oh yeah, blind mix would need specialized client side software.
Now that is very interesting and would love to see the use of it wide spread and adopted by SR users. In the mean time what other mixing services are well respected other than bitcoinfog? Sorry to hijack the thread!
-
My biggest fear is that services that mix bitcoins turn out to be honey pots. Really hope there comes a way to mix them with security by design without needing to hope that the service is not a honey pot.
Blind mixing allows coins to be mixed without the mix operator being able to gain any information even if they are malicious. I think I am going to implement a blind mix right now actually, maybe I will charge a bit to use it or maybe I will give it to SR to run and hope he compensates me a little.
Thing is. How to prove to somebody who has just arrived at your service that this is indeed a blind signature mix, and not just a regular bitcoin laundry service? Somebody with no programming knowledge to audit open source code? Otherwise there's no comparative advantage for a blind sig over a normal mix, because you're back to trusting 'authority' i.e. other SR people or the mix owner that it all works according to plan. Maybe I haven't read the work on blind signature mixers properly, but if I'm right, then this is serious problem for anybody implementing a mix.
Also, it would need to be tested per mix cycle in case a LE agent was doing a bait 'n switch with a blind signature mixer and a normal mix. Block chain looks the same, but you're potentially linkable to a transaction if your anonymity is compromised.
Surely somebody like Chaum already came up with a solution to this?
Chaum invented the first blind mix. The client software can verify that the signature is blind, so you really are not trusting anything other than the implementation of the client. Oh yeah, blind mix would need specialized client side software.
Now that is very interesting and would love to see the use of it wide spread and adopted by SR users. In the mean time what other mixing services are well respected other than bitcoinfog? Sorry to hijack the thread!
Bitcoin Laundry (clearweb I think)
-
Chaum invented the first blind mix. The client software can verify that the signature is blind, so you really are not trusting anything other than the implementation of the client. Oh yeah, blind mix would need specialized client side software.
Must think further thoughts on this, I think it's going to get important ASAP to hold up the B$ system when LE openly starts to run operations to shut down or spy using the exchanges. It'll happen anyway, but it might as well be done right, obviously people would be super leery of installing software onto their computers that explicitly implicates them as blackmarket users of B$.
-
Chaum invented the first blind mix. The client software can verify that the signature is blind, so you really are not trusting anything other than the implementation of the client. Oh yeah, blind mix would need specialized client side software.
Must think further thoughts on this, I think it's going to get important ASAP to hold up the B$ system when LE openly starts to run operations to shut down or spy using the exchanges. It'll happen anyway, but it might as well be done right, obviously people would be super leery of installing software onto their computers that explicitly implicates them as blackmarket users of B$.
They could encrypt it when they are not using it ?? Then hide it in a video file with stego ?
-
That wouldn't implicate them anymore than using tor or PGP. It is just another tool to stay anonymous and we have every right to practice this.
Like the other poster above me said you could put it on your encrypted USB if you are worried.
-
They could encrypt it when they are not using it ?? Then hide it in a video file with stego ?
Of course, but it is not physical discovery of the file that concerns me. It's a factor, but not a terribly important one unless anonymity is compromised, my real concern is below:
That wouldn't implicate them anymore than using tor or PGP. It is just another tool to stay anonymous and we have every right to practice this.
Like the other poster above me said you could put it on your encrypted USB if you are worried.
I'd be more cautious about advocating my rights and more especially in expecting them to protect me, I don't expect LE to play by Marquis of Queensbury rules and neither should you. Unfortunately they are no gentlemen in that regard (this is something that has changed over the course of the Drug War), even though many smuggling organizations do adhere to a strict honor code, usually inspired by ethnicity bonds and issues of practicality in evasive tactics. The Snakeheads for example, despite a fearsome reputation in the general media, are almost always honorable men that have done a great many invisible good deeds in this world and Capitalism owes them a debt. They are nothing less than modern day heros in South East Asia. If we didn't there would be a far more fearsome body count. When I said the DEA were outnumbered, I wasn't using a metaphor, they cannot afford open war against the black market no matter what they claim in public. They are Chihuahua to our Doberman, and would emit a brief high pitched squeak if they ever encountered their real opposition directly ;-) If you want evidence for my world view, there's plenty to spare in Mexico.
--
More to the point, I am not concerned about physical discovery of such software because of anonymity.
No, I am more worried about one of us working for a LEA and installing an exploit into such a software on the client OR betraying data on transactions via the server by using a bait and switch. That is not an accusation, simply that this would clearly be an extremely affective way at undermining the black market using B$. Temptation beckons! A poisoned chalice it would surely be too for any such subscriber.
Of course I don't trust the current bitcoin laundry facilities either, but it seems to me that working out a solution that doesn't rely on trust is the key thing here. For example, I would assume GPG and Tor *could* contain exploits, but that they would only be used in times of extraordinary conflict, not on something like SR. As I've said before, we have a unique kind of political protection. A bitcoin laundry is another matter. That is why I have always advocated using two factor bitcoin anonymity, both physically in the real world by obtaining bitcoin with cash, and virtually by using mixes.
Perhaps I am spoiled with cryptographically assured trust systems like signed PGP, but it seems to me a real solution has not been yet purposed that doesn't depend on a lack of corruption among the developers. Not arguing for perfection here, just think it should be conceptualized differently to the way things are normally done. Blind mixes are fantastic idea, but only if they work as advertised without 'features'. How can one guarantee such a thing? Some genuine out of the box thinking is required. I mean look at cryptographically signed certificates on the normal web, what a bunch of crap that is. It depends on the persuasive power of the agency wanting to compromise them, i.e. we are cryptographically back to square one, with cryptography operating in favor of the strong but not the weak, not exactly at peace with crypto-anarchy there are we.
Argumentum ad verecundiam may be often completely correct, witness the peer review process of science, but because it is an argument on the bias of expecting future perfection indefinitely it is at heart a horribly flawed piece of logic.
tldr; We can do better than this.
-
No, I am more worried about one of us working for a LEA and installing an exploit into such a software on the client OR betraying data on transactions via the server by using a bait and switch. That is not an accusation, simply that this would clearly be an extremely affective way at undermining the black market using B$. Temptation beckons! A poisoned chalice it would surely be too for any such subscriber.
If the software is open source then it is only vulnerable to people installing exploits in it if nobody audits it. People will always be able to steal bitcoins in their possession so I don't see how having a secure mix is any different from having a less secure mix in that respect.
Perhaps I am spoiled with cryptographically assured trust systems like signed PGP, but it seems to me a real solution has not been yet purposed that doesn't depend on a lack of corruption among the developers. Not arguing for perfection here, just think it should be conceptualized differently to the way things are normally done. Blind mixes are fantastic idea, but only if they work as advertised without 'features'. How can one guarantee such a thing?
They guarantee it based on the way the math works, the client gets an IOU saying that they are owed 1 bitcoin for every bitcoin they send to the server, and then they can do a mathematic proof that shows the server can not identify the signature on the IOU it just sent them. However, the server can still verify the signature on the IOU when presented with it, and then it knows that it actually owes the person with the IOU 1 bitcoin. However, it can not link the person taking the bitcoin out to the person who put the bitcoin in. If the client software is open source and people audit it, there is not much risk of a backdoor being put in...in fact blind mixing software is pretty simple to make and wouldn't entail very much code at all.
Please let me know when you do better than mathematically ensured unlinkability of signatures to clients.
-
Also open transactions is nice but it includes a LOT more than blind mixing and I think that it may be rather overkill for people who simply want the ability to mix their bitcoins with a proof of unlinkability.
-
I wasn't arguing that blind mixes needed improving as a concept kmfkewn. I was saying that the way it is delivered is important. Unlike GPG or the Tor software, LEA has a very great motive to surveillance/exploit such software as that which compromises a blind mix. A judge would never give the go ahead for exploits in something like everybody's copy of GPG, but in "money laundering software"? Yes I think so.
Source code auditing is always important, but I'm trying to put across the point that it is extremely so in this case and even that it would be better if we had some method of guaranteeing per software use that the software only did what it was supposed to, since not everybody can be expected to read lines of code and then compile from source each them they use it. Maybe it is not possible, or more probably not very easy, but it is not a ridiculous idea considering that such software would ultimately become the defacto foundation for the entire black market bitcoin economy. It's pretty much got to be a bulletproof way of preventing exploits becoming possible.
Vague thought: If we had one 'perfect' never changing version of a blind mix. Then we could audit it in such a way to guarantee there was no exploit trickery e.g. lots of experienced eyeballs staring at it, and then have it written to read only disks/special write-once flash drives etc. Then those could be distributed throughout the community and copied, but not altered. Could use SHA hash to validate that each disk/flash drive contained the legitimate copy.
Anyway, I am not feeling well today and don't have any wonderfully original ideas to offer, I just think it's a super important issue and now I must go discover some caffeine dispensing apparatus in the lobby.
-
I think a judge would have absolutely no problem with feds exploiting Tor or GPG to get to their targets. As far as backdoors go, that is why things should be open source. You can simply have a hash value of the code and then everyone who audits it can confirm they audited the files that hashed to so and so value, and people who use it can hash it to verify its integrity prior to using it. The closest thing to bulletproof way to prevent exploits would be formal verification I imagine, but not even the bitcoin clients themselves have such a high degree of security.
I think you over estimate the amount of
code complexity required for a blind mix, particularly if you consider so much of it is already done in crypto libraries.
here is one blind mint protocol (I tried to fix up the formatting)
Creating the Mint
The mint chooses a prime, p, with (p − 1)/2 also prime, a generator, g, s.t.
g 2 = 1 (mod p)
and
g (p−1)/2 = 1 (mod p)
and a random number, k,
k ∈ [0, (p − 1)/2)
Let G be the group generated by g.
The mint publishes
(g, p, g k (mod p))
Withdrawing a Coin
To withdraw a coin Alice picks a random x, the coin ID, from a sufficiently large
set that two equal values are unlikely to ever be generated2 , and calculates,
y = oneway(x)
y should be in G; check that
1<y <p−1
We should avoid the trivial values 1 and -1, because their signatures are in-
dependent of k. Note that many one-way coin functions (including the one
presented here) provably never produce 1 or -1, but we include this condition
for completeness.
y (p−1)/2 = 1 (mod p)
If it is not, a new coin should be chosen. Note that great care must be take
if you want to choose a one-way function that guarantees membership of G -
certainly one attempt led to disaster.
Alice chooses a random blinding factor b ∈ [0, (p − 1)/2) and sends yg b (the coin
request) to the mint. The mint debits Alice’s account and returns the blinded
signature,
m = (yg b )k (mod p)
Alice unblinds m, calculating the signature,
z = m(g k )−b = (yg b )k g −kb = y k g bk g −kb = y k (mod p)
The coin is then
c = (x, z)
Spending a Coin
To spend a coin, Alice simply gives the coin, c, to Bob. Bob then sends it to the
mint to be checked. The mint first ensures that x has not already been spent,
and that oneway(x) is in G and is not 1 or -1, then checks that z is a signature
for x (i.e. z = oneway(x)k (mod p)). The mint then records x as spent and
credits Bob’s account.
Unfortunately an attack on the anonymity of this protocol is possible. The mint
can mark a coin in a way that only it can detect, by signing it with k instead
of k. Then the unblinded “signature” is
z = (yg b )k g −bk = y k g b(k −k) (mod p)
When Bob submits c to the mint, then the mint calculates
y(zy −k )1/(k −k) = y(g b(k −k) )1/(k −k) = yg b (mod p)
The mint can then simply look up who sent yg b to it and thus learn Alice’s
identity.
One defence against this attack is to make the mint prove that it has signed
with k and not some other number. Since the mint must not reveal k, this proof
must be a zero-knowledge proof. Two possible zero-knowledge proofs are known
to me.
Given a coin request, yg b , the mint chooses a random number r s.t.
r ∈ [1, p − 1)
s.t. r is invertible modulo p − 1 (i.e. gcd(r, p − 1) = 1) and calculates
t = k/r (mod p − 1)
(p − 1 rather than p because r and t will be used as exponents modulo p). The
mint then sends Alice
Q = (yg b )r (mod p)
A = g r (mod p)
Alice then randomly demands one of r or t.
If Alice chose r, she verifies that
Q = (yg b )r (mod p)
A = g r (mod p)
If Alice chose t, she verifies that
At = g rt = g k (mod p)
Qt = (yg b )rt = (yg b )k = z (mod p)
Note that a mint that wants to cheat has a .5 chance of getting away with it each
time (by guessing whether the challenger will choose r or t and lying about Q
and A appropriately). Naturally, it is increasingly unlikely to get away with this
with each repetition. A suspicious challenger could always repeat the protocol
until the probability of cheating is low enough to make them happy.
A lot of these pieces are done, just need hooked together.
All the code would consist of, would be these math formulas for the client and server (many parts of which are in crypto libraries), a tiny bit of networking code so the client and server can communicate with each other, and maybe a wrapper for a bitcoin client (although that isn't even required).