3 ms·

ok, thanks ;) . I have learnt a reasonable amount about the subject.. I'm still pretty confident that if all you possess is some hashes, with no knowledge of t

by axod 18y ago

ok, thanks ;) . I have learnt a reasonable amount about the subject.. I'm still pretty confident that if all you possess is some hashes, with no knowledge of the hashing algorithm, salt etc, you won't be able to work out any of the IPs. If you think that assertion is false, please educate and explain why. But as you say, forums leave way too much room for misinterpretation in the finer details...

DenisM 18y ago
Your design may be secure software design but it is not a secure system design. When a system consists of multiple components you need to take into account the security and the failure modes of each individual component as well interactions between those failures. The operator does not need to be tortured, he simply needs to be told to cough up the salt or get tried on terrorism charges in a secret court. How many people will you find willing to trade their freedom for your corporate profits? More importantly, you don't know whether they will or will not fold, regardless of what they tell you at the job interview. Next, if the operator is the only one to know the secret, what is to stop him from blackmailing your businesses? Or dying under the bus and taking the secret with him? You will have to introduce a backup person who also knows the secret and is also fallible in the same way, increasing your risk. The questions of loyalty and conflicting interests are collectively known as "the agency problem" - where agents act not consistent with the interests of their employers. Given agency problems soon enough you will come to a point where someone with big stake in the company (like a founder or CEO) has to know the secret to avoid possible conflict of interest. Of course such person will also have a lot to lose and will be even more likely to fold under simple pressure such as arrest of their assets. The idea with storing the salt out of jurisdiction also has weak spots in it: first, you can't use public CA because NSA likely has their own certs signed by all major CAs. You would need to roll your own SSL cert and deliver it physically. Next, there wouldn't be any machine-gun-toting people streaming into the datacenter - there will be a subpoena to the CEO and if he does not comply he will go to jail and lose his mansion. Is it possible to set data such that CEO can not fetch the data? Technically yes, but realistically CEO that does not control his secrets will likely feel uneasy about losing those secrets to an accident or an agency problem and so he will most likely try to assert control over said secret. At which point he becomes a point of attack. Now, how does remote site know not to dispense secrets to a anyone who asks? It would have to ask requester for an ID and that ID will be stored on the (now confiscated) machine. Then, who will administer the remote site? What are his legal and moral obligations? Can their government compel them to cough up the secrets on request of your government? Further, RAM can and does get examined. There are consumer-level tricks with canned air that allow to reboot the machine while keeping RAM content intact for the next booted OS to chew on. This was at the heart of the recent TPM security breach (for some implementations of TPM). Also when machines are being confiscated they are not unplugged, there are products that allow to transport machine without losing power. The system is complex and there will likely be bugs at the points where some components talk to some other components.
- axod 18y ago
  Sure, these are all obvious attacks. But completely tangential to my point about the feasibility of the software. They're an 'operations/logistics' issue, not a software one.
  - DenisM 18y ago
    And this is what prompted my initial comment. End users don't care how good your software is - they care whtehr their informaiton is leaked or not. Designing this sort of secure software is akin to building the Maginot line - it may work as designed but will not fulfill the purpose.

by axod 18y ago

DenisM 18y ago

Your design may be secure software design but it is not a secure system design. When a system consists of multiple components you need to take into account the security and the failure modes of each individual component as well interactions between those failures. The operator does not need to be tortured, he simply needs to be told to cough up the salt or get tried on terrorism charges in a secret court. How many people will you find willing to trade their freedom for your corporate profits? More importantly, you don't know whether they will or will not fold, regardless of what they tell you at the job interview. Next, if the operator is the only one to know the secret, what is to stop him from blackmailing your businesses? Or dying under the bus and taking the secret with him? You will have to introduce a backup person who also knows the secret and is also fallible in the same way, increasing your risk. The questions of loyalty and conflicting interests are collectively known as "the agency problem" - where agents act not consistent with the interests of their employers. Given agency problems soon enough you will come to a point where someone with big stake in the company (like a founder or CEO) has to know the secret to avoid possible conflict of interest. Of course such person will also have a lot to lose and will be even more likely to fold under simple pressure such as arrest of their assets. The idea with storing the salt out of jurisdiction also has weak spots in it: first, you can't use public CA because NSA likely has their own certs signed by all major CAs. You would need to roll your own SSL cert and deliver it physically. Next, there wouldn't be any machine-gun-toting people streaming into the datacenter - there will be a subpoena to the CEO and if he does not comply he will go to jail and lose his mansion. Is it possible to set data such that CEO can not fetch the data? Technically yes, but realistically CEO that does not control his secrets will likely feel uneasy about losing those secrets to an accident or an agency problem and so he will most likely try to assert control over said secret. At which point he becomes a point of attack. Now, how does remote site know not to dispense secrets to a anyone who asks? It would have to ask requester for an ID and that ID will be stored on the (now confiscated) machine. Then, who will administer the remote site? What are his legal and moral obligations? Can their government compel them to cough up the secrets on request of your government? Further, RAM can and does get examined. There are consumer-level tricks with canned air that allow to reboot the machine while keeping RAM content intact for the next booted OS to chew on. This was at the heart of the recent TPM security breach (for some implementations of TPM). Also when machines are being confiscated they are not unplugged, there are products that allow to transport machine without losing power. The system is complex and there will likely be bugs at the points where some components talk to some other components.

axod 18y ago
Sure, these are all obvious attacks. But completely tangential to my point about the feasibility of the software. They're an 'operations/logistics' issue, not a software one.
- DenisM 18y ago
  And this is what prompted my initial comment. End users don't care how good your software is - they care whtehr their informaiton is leaked or not. Designing this sort of secure software is akin to building the Maginot line - it may work as designed but will not fulfill the purpose.