Silk Road forums
Discussion => Silk Road discussion => Topic started by: Burning Babylon on June 27, 2013, 07:16 pm
-
So far we've only operated domestically within Sweden and there's been no trouble with the mail so far except a few random delays, but when we expand internationally we're bound to eventually have customs seizures and customers giving incorrect addresses. To solve this problem in advance so we're prepared we're going to adapt a concept called "Verification Letter", it would work like this:
A customer reads our presentation and see we offer an increased refund if they have an unique code from a Verification Letter we're selling. If the customer decides to order a Verification Letter we will print two copies which has the unique code, one will be sent to the customer while the other stays with us. The code itself will be linked to the account which made the purchase and will be time limited for one month. Let's say the customer makes another order which gets seized by Customs. The customer would then provide us with proof for this along with the unique code in the Verification Letter and get a refund for the Seizure along with a bonus refund from having used the Verification Letter.
Now this is isn't exactly a great system, but it is better in comparison to nothing at all. I foresee these potential problems eventually:
* Customer orders a Verification Letter, then an order to the same address which they then claim didn't arrive at all while still using the unique code in a dispute.
* Customer orders a Verification Letter to an address, then uses a different address for the next order.
* Customer claims during a dispute they had no idea the system existed to begin as they couldn't be bothered to read the Presentation before an order.
* Customer claims Customs Seizure in a dispute, yet won't provide proof and still want to use the unique code to get a bonus refund.
Maybe a few Vendors who operate internationally could chime in if this concept could possibly work or if a better solution exists which can deal with careless customers along with scammers? :)
-
If you don't save the address from the verification letter, then this is useless. And you shouldn't be doing that.
-
If you don't save the address from the verification letter, then this is useless. And you shouldn't be doing that.
Well it would technically work if all customers were honest and used the same address at all times, but I suppose that is a bit optimistic thinking. I suppose the best solution to this would be to attach the customer address in encrypted form using a separate PGP key just for the sake of the Verification Letters. Since it's only valid for one month it would be like a product with an expiration date and thus not technically fall under the definition of "saving the address".
My current plan is to have the following rules for Disputes:
With evidence of a seized order domestically we will repay you 75%.
With evidence of a seized order internationally we will repay you 50%, alternatively attempt to reship once.
For any order that hasn't arrived due to some other reason we will repay you 25% excluding a reshipment.
Having a Verification Letter would give a 25% bonus to any of those three categories, so the rates would be 100%, 75% and 50%.
While this next step isn't possible at the moment Silk Road could technically add a feature where it keeps track of the Verification Letter and lets the customer pick the address solely bases on that, in other words the customer would not enter any address at all but just pick "Verification Letter which is valid bla to bla with encrypted address X" and it would only work after the customer has entered the code into a subsection on Silk Road. It would in a sense take the responsibility of encrypting the address from the customer to the vendor.
-
Think of the paper trail you are making.
I can understand the desire to have verified addresses as buyers often get it wrong, but this is not the way to go about it.
For one thing instead of encyrpting the addresses they could be normalized and one-way hashed with a salt. This would allow you to confirm an address without know what the address is.
Even then it would provide an advisary with unlimited guesses. There are only so many million addresses, an advisary with medium resource could guess them all.
It is not a good plan to keep addresses in any way. Encryption is not enough, it should be encrypted anyways. You need to not be capable of getting the information in the event of a bust, ie deleted.
-
Think of the paper trail you are making.
I can understand the desire to have verified addresses as buyers often get it wrong, but this is not the way to go about it.
For one thing instead of encyrpting the addresses they could be normalized and one-way hashed with a salt. This would allow you to confirm an address without know what the address is.
Even then it would provide an advisary with unlimited guesses. There are only so many million addresses, an advisary with medium resource could guess them all.
It is not a good plan to keep addresses in any way. Encryption is not enough, it should be encrypted anyways. You need to not be capable of getting the information in the event of a bust, ie deleted.
A fair point, so what about replacing the paper copy for the vendor with a digital copy kept on an encrypted computer?
-
BB you seem hell bent on getting people to follow bad security practices these last few days.
-
BB you seem hell bent on getting people to follow bad security practices these last few days.
There are degrees of security one can follow before it starts becoming a hindrance. If one wants to stay as safe as possible as a vendor one should follow the advice of Pine and read the thread [Anonymity Masterclass] PGP Club and the War on Linkability: http://dkn255hz262ypmii.onion/index.php?topic=159758.msg1157414 However any vendor which rigidly follows these rules will have major restrictions on concepts and ideas they're able to follow, including this idea which would be unthinkable under those definitions.
I understand you adhere to the principle Security Through Obscurity, while I do not. A good analogy for our differences is how GPG4win blocks any user from pasting a password while gpg4usb does not. GPG4win claims its safer but gpg4usb is a lot more practical.
-
So these are going to be my terms:
Verification Letter gives a bonus when having a dispute with us: http://silkroadvb5piz3r.onion/silkroad/item/ff16ca31ee
The first percentage rate is for ordinary customers while the second is for those in possession of a Verification Letter.
With evidence of a seized order domestically we will repay you 75% / 100%.
With evidence of a seized order internationally we will repay you 45% / 75%, alternatively attempt to reship once.
For any order that hasn't arrived due to other reasons we will repay you 15% / 50% excluding a reshipment.
----------
The address will be encrypted using PGP, the encrypted PGP address will in turn be encrypted with HMAC (a type of salt mentioned by Tessellated ) using HashCalc. v2.02: http://www.slavasoft.com/hashcalc/
This ensures there's the ability to verify an exact address in the case of a dispute, but there's no ability to reveal the address itself for us - even if we wanted to.
Now I personally see this as a pretty good solution, while others will find it unacceptable on the basis that its philosophically against their code of Security or something. :)
-
This is a Horrible idea. If you think your gonna have so many issues maybe you should not offer international shipping. Vendors dont need to have kinda personal information kept from a buyer after sending their package.
I dont see why any buyer would agree to this at all
-
You should put this effort in to some kick ass stealth tactics.
Your going to run in to scammers. theres not much your can do. Only offer a refund with a international seizure letter.
Most countries are pretty fast to supply them when something has been confiscated.
-
This is a Horrible idea. If you think your gonna have so many issues maybe you should not offer international shipping. Vendors dont need to have kinda personal information kept from a buyer after sending their package.
I dont see why any buyer would agree to this at all
They're free not to use it, but they'll end up in the first bracket for refunds in the case of a Dispute then. Also I'm not sure you understood exactly what I wrote in my last post, can you explain how I would have access to the address with a HMAC string?
You should put this effort in to some kick ass stealth tactics.
Your going to run in to scammers. theres not much your can do. Only offer a refund with a international seizure letter.
Most countries are pretty fast to supply them when something has been confiscated.
There's plenty of other issues just than seizures, like incorrect addresses, people using PO Boxes and then not fetching the package if it requires a signature, Poste Restante and Packstations. While you're correct scammers won't be affected they at least won't have grounds to argue on when there's a very clear terms set out.
Stealth in itself is not an indicator that can be described as good or bad in relation to all countries, if a package is sent to high risk countries like Sweden or Australia the package always has a risk of getting opened no matter what kind of stealth is inside or outside. If one were to ship a drug like LSD stealth wouldn't even be a factor as Customs is probably focusing as much as LSD as they are on Salvia, in other words not very much.
-
I would NEVER do business with anyone who takes such risks with security, and think this would hurt your reputation.
Spending time on security and stealth should bring better returns, but your choice
-
If you don't save the address from the verification letter, then this is useless. And you shouldn't be doing that.
Well it would technically work if all customers were honest and used the same address at all times, but I suppose that is a bit optimistic thinking. I suppose the best solution to this would be to attach the customer address in encrypted form using a separate PGP key just for the sake of the Verification Letters. Since it's only valid for one month it would be like a product with an expiration date and thus not technically fall under the definition of "saving the address".
I dont think that this verification letter is a good idea, but you could store a hash of the shipping address and if you ship the real product, you could just check the hash of the shipping address with the hash of the verification letter address. So you dont have to store any addresses.
-
I dont think that this verification letter is a good idea, but you could store a hash of the shipping address and if you ship the real product, you could just check the hash of the shipping address with the hash of the verification letter address. So you dont have to store any addresses.
Indeed, I got to that conclusion later in the thread in this message: http://dkn255hz262ypmii.onion/index.php?topic=177984.msg1289248#msg1289248
Only difference is I put in the step of encrypting the address first, so even if they somehow crack the HMAC salt they would have to run that on the address encrypted from one of my other keys which they don't have the public key for.
For some people it doesn't matter if there's one step or five hundred, they think it's a bad idea regardless.
-
Maybe I am not understanding something here, but this idea does not make any sense to me.
-
Maybe I am not understanding something here, but this idea does not make any sense to me.
I'll explain it in detail in two hypothetical scenarios. First these are the terms I have currently:
With evidence of a seized order domestically we will repay you 75% / 100%.
With evidence of a seized order internationally we will repay you 45% / 75%, alternatively attempt to reship once.
For any order that hasn't arrived due to other reasons we will repay you 15% / 50% excluding a reshipment.
Scenario #1
A domestic customer orders 5 Grams of Hash for 1 BTC.
Viewpoint 1: The order gets seized by Customs, the customer does not have a Verification Letter and so gets a 0.75 BTC refund in resolution.
Viewpoint 2: The order doesn't arrive since the address is incorrect, the customer does not have a Verification Letter so he gets a 0.15 BTC refund in resolution ( had the customer had a Verification Letter this wouldn't have happened ).
Viewpoint 3: The order arrives without any problems, Verification Letter or not make no difference whatsoever.
Scenario #2
An international customer orders 10 Grams of Hash for 2 BTC.
Viewpoint 1: The order gets seized by Customs, the customer has a Verification Letter and so gets either a 1.5 BTC refund or a reshipment in resolution. ( The reshipment would have been included without a Verification Letter )
Viewpoint 2: The order gets lost even though the customer had a Verification Letter. I don't see this happening but if it does the customer will get 1 BTC refund in resolution.
Viewpoint 3: The order arrives without any problems, Verification Letter or not make no difference whatsoever.
I noticed PGP gives different values for encrypting the same text at different times due to how AES operates which was actually news for me, however I have to take it it was news to a few others as no one corrected me on this crucial point.
Anyway since I'll have to skip that part I'll go straight to the Address Part, let's say this is my address:
Donald Duck
1113 Quack Street
Duckburg, Calisota, USA
If I enter this exact data into a text document I should get the following values by using HashCalc:
MD5: 869c84d03001d75951c1cbf92733cdef
SHA1: 0b5359530a867c1e87b418a8c8a16acdb2d3da0f
RIPEMD160: c460db49dfc07807f0c2e5587493fca6e7923516
Anyone who uses HashCalc should get the same values as I mentioned above.
Now if I enable the option HMAC with Key Format "Text string" and the password "Scrooge McDuck" I get these new values:
MD5: 2ebd8dbb59d5381fc9e824df80392168
SHA1: 44a5c78bf4a20fc7dad4be633892797312bcd1d3
RIPEMD160: cdb77f573e4a3090176e10c6483c4a73a5f294e2
The Unique Code used for the Verification Letter could be any of those three values above, and they could only be replicated if Law Enforcement knew it was salted with HMAC with the password "Scrooge McDuck".
-
I'm not endorsing your scheme but I have some comments on implementation..
...
I noticed PGP gives different values for encrypting the same text at different times due to how AES operates which was actually news for me, however I have to take it it was news to a few others as no one corrected me on this crucial point.
That's standard for all modern algos
Anyway since I'll have to skip that part I'll go straight to the Address Part, let's say this is my address:
Donald Duck
1113 Quack Street
Duckburg, Calisota, USA
If I enter this exact data into a text document I should get the following values by using HashCalc:
...
'exact data' is a problem with your scheme, if the verification letter says USA & the order says USa it fails.
You should normalize the addy to all lower case, no punctuation, etc.
...
The Unique Code used for the Verification Letter could be any of those three values above, and they could only be replicated if Law Enforcement knew it was salted with HMAC with the password "Scrooge McDuck".
Better is to encrypt the addy using gpg symetric encryption to a truely random 64 byte pw & use that PW as the verification token. Wrap that by encrypting to your own key for your local copy.
Decrypting a file is much harder that breaking a hash & the concept is easier for people to understand. Once you destroy the plaintext addy & pw there is no way you can decrypt the addy.
If LE intercepts the verification letter they get the token but they already have the address so no harm is done.
JofSpades
-
The address will be encrypted using PGP, the encrypted PGP address will in turn be encrypted with HMAC (a type of salt mentioned by Tessellated ) using HashCalc. v2.02: http://www.slavasoft.com/hashcalc/
This ensures there's the ability to verify an exact address in the case of a dispute, but there's no ability to reveal the address itself for us - even if we wanted to.
Every PGP message is different even if the content is the same. Hashing addresses does not create privacy because it is trivial to guess every single address in the world. There are less addresses than people, ie less than 7 billion. You can guess 7 billion hashes in a matter of hours.
You cannot be storing addresses in ANY way. Not only is it a bad idea it is against the rules and vendors who do store addresses are rightly banned.
-
'exact data' is a problem with your scheme, if the verification letter says USA & the order says USa it fails.
You should normalize the addy to all lower case, no punctuation, etc.
While it should be up to the customer to get this correctly, I suppose this is basically not going to happen. I would personally go with how I would format it normally with capital letters for each section.
Better is to encrypt the addy using gpg symetric encryption to a truely random 64 byte pw & use that PW as the verification token. Wrap that by encrypting to your own key for your local copy.
Decrypting a file is much harder that breaking a hash & the concept is easier for people to understand. Once you destroy the plaintext addy & pw there is no way you can decrypt the addy.
If LE intercepts the verification letter they get the token but they already have the address so no harm is done.
JofSpades
Basically the PGP/GPG encryption works as long as it's for the end step so it won't mess up the Hash Value of the address. :)
Every PGP message is different even if the content is the same. Hashing addresses does not create privacy because it is trivial to guess every single address in the world. There are less addresses than people, ie less than 7 billion. You can guess 7 billion hashes in a matter of hours.
You cannot be storing addresses in ANY way. Not only is it a bad idea it is against the rules and vendors who do store addresses are rightly banned.
I get why you didn't find this idea of any value conceptually at first because of ideological reasons or whatever, but at this point you've crossed into absurdity. I'm not entirely sure of your thought process at this point but let me try and understand it:
Hashing addresses does not create privacy because it is trivial to guess every single address in the world.
So at face value this would mean you think my plan would be to store the address in itself without any name to it to keep it as simple as possible, because any variation at all in the recipient for the address is obviously going to create a lot more possibilities than seven billion hashes. Now you ignored my point with using a HMAC salt but I assume in this context you're assuming Law Enforcement might hypothetically have the capability of cracking every single password I have which I'll admit might be a possibility if they've been tracking how my brain operates for the last ten years and has the ability to remotely see what I see through my eyes - however if they have that ability your way of doings things will be no more secret than mine. You also ignored the point of JofSpades but I'll give you the benefit of the doubt here and assume you just didn't see it - adding the layer of encrypting the Hash Checksum will make it considerably harder to gain access to even the Hashed Salt Checksum.
Also for the final point in what universe does every single Law Enforcement Agency in the world have the name and address to every single person in the entire world, updated on a second to second basis and on top of that it's even trivial for them to brute-force encrypted PGP/GPG encryption and reveal the Hashed Salt Checksum and correctly identify it to an address/person? Considering you even tried arguing this far I don't even get what could hypothetically get you to admit you went too far in your reasoning.
You cannot be storing addresses in ANY way. Not only is it a bad idea it is against the rules and vendors who do store addresses are rightly banned.
How about storing the address on the letters being sent out to customers, which I assume even you have to do?
Now to get to the point, the Seller's Guide covers this under the section Client anonymity: http://dkn255hz262ypmii.onion/wiki/index.php?title=Seller%27s_Guide#Client_anonymity
Client anonymity
You and you alone will have your client's shipping address. This information must be destroyed as soon as it is used to label their package. When you click "confirm shipment," the address will be deleted forever and irretrievable.
-Never ask your clients for personal information.
-Under no circumstance should you save a copy of your client's address.
-Publish a Public encryption key in your user description on your settings page so your customers can send you their info encrypted if they wish.
-Under no circumstance should you save a copy of your client's address.
This is what's being covered and I have no way of retrieving the address without gaining access to the magical database you've mentioned which lists every single person in all multiverses updated continously, along with all encryption methods ever devised until the end of time and beyond. Up until the point this section is changed to include this I'm following the rules by using this method.
----------
Now I did find another layer to add to this Verification Aspect with the advent of my thread Postal Spam - Where and How? http://dkn255hz262ypmii.onion/index.php?topic=178446.msg1287151
Basically any kind of Postal Spam which can be ordered internationally can be used for this purpose. The concept is simply the customer and vendor would have access to the same type of Postal Spam and so the vendor can simply ask the customer to recite any page or characteristic which he will be able to do if he has access to it. Now this won't solve all problems as the customer could still lie about using different addresses and so on but I would qualify it as safer than nothing. I might even consider combining the ideas with sending some kind of Postal Spam in itself with the code hidden on a specific page, or sending an incomplete code with the last two digits sent in a private message through Silk Road. There are obviously a lot of ways to continuously improve this concept which is also what I'm planning on doing.
-
There are definitely some issues with this but the general idea is very good.
The main aim of the process is to verify the address that an item was sent to. I don't see why you couldn't ask someone to pay for verification upfront and send both letters at the same time? That would also make the process much quicker and the process would be a form of insurance.
I don't see why you couldn't hash the address and password (which onyl you know) together, send that as the verification code and then send the user back their address as you used it (by PGP) in the hash function. Store the username and password in a spreadsheet (encrypted) and when they contact you about verification they send you their address and verification code. You simply hash the address and the password togetherr and see if it matches. If it does it's verified.
-
The customer would then provide us with proof for this along with the unique code in the Verification Letter and get a refund for the Seizure along with a bonus refund from having used the Verification Letter.
Not sure if I would add a bonus. I'd offer a verification letter with a one time code, and if chosen to purchase that ahead of time, it can be used as a future discount code, or in the event of a seizure; a partial or whole refund.
I think offering near the same or even a greater bonus would inspire more risky purchasing from consumers but will also attract scammers. People using your own policy could ruin that policy for others, hurting your business. I wouldn't want to attract that.
-
We're opening up for European Union orders on an upcoming product within two weeks most likely so time to finalize how this concept will work:
A customer will have to order either Verifikationsbrev: http://silkroadvb5piz3r.onion/silkroad/item/b5fe4b30f for Domestic use ( Sweden ) or Verification Letter: http://silkroadvb5piz3r.onion/silkroad/item/ff16ca31ee for European Union/International use. The username and Postal Code will be put on separate lines in a text file, hash checked by the application HashCalc. v2.02 and with the option HMAC enabled with a random password the checksum for RIPEMD160 will be the Unique Code. The Unique Code along with the password needed to replicate the Unique Code if the customer wants to do his own verification will be sent in a small envelope. We will on our end store the Unique Code, the password for the Unique Code and the 28 day validity which starts the time the Verification Letter is ordered - all encrypted of course and decrypting would only be necessary in the event of a dispute.
This is kind of a middle ground solution, by basing the hash off the Silk Road username and the Postal Code itself the information would be off no use to Law Enforcement in the unlikely event they would somehow be able to crack it - the letter/text itself would not be proof of anything. The drawback is a buyer could hypothetically attempt to find an address with an identical Postal Code, send it to that new address and then claim the package didn't arrive and provide the Unique ID in the Resolution Center. In the unlikely event this happens I've decided that the Unique Code is only valid once per term, in other words it would be valid for one order during the 28 day period and if the buyer wants another Verification Letter for the same Postal Code he would have to wait until the old one expires alternatively get a new username or Postal Code.
Some random notes the Unique Code will use the font "Consolas" so one can tell the difference between 0 and o and it will be converted into UPPERCASE. Not a single Domestic Order has been seized or had any trouble so far and no one has bothered to even ask about the concept, but it's bound to happen when sending abroad eventually. To quote the current terms:
Verification Letter gives a bonus when having a dispute with us: http://silkroadvb5piz3r.onion/silkroad/item/ff16ca31ee
The first percentage rate is for ordinary customers while the second is for those in possession of a Verification Letter.
With evidence of a seized order domestically we will repay you 75 % / 100 %, alternatively attempt to reship once.
With evidence of a seized order internationally we will repay you 45 % / 75 %, alternatively attempt to reship once.
For any order that hasn't arrived due to other reasons we will repay you 15 % / 50 %, excluding reshipments.
I'll add here that with provided evidence of a seized order the reshipment doesn't have to be to the same address/postal code as it would obviously be burned for a while.
A bonus might be to put some kind of material over the paper/text itself so it's evident if its been opened/tampered with, anyone have any suggestions on that aspect? :)