"No, I'd say it's time for you to learn what "one-way" means. Mars ain't around the damn corner."

"martian rover maintenance infrastructure" sounds like the repair infrastructure is on Mars, so you would just bring it back to that location on Mars.

"Calm down there"

His post was pretty calm. Yours... not so much.

No I read it correctly, and if you come to me and say I "should" do this or that as a content host, and when I CHOOSE to do otherwise, you start yelling about how "This is total bullshit" then you sound like an ignorant child who is trying to tell people that they should do something where you have no right.

I think both sides of the argument are pretty mute anyhow. I don't think much is gained or lost either way you go.

I know what BGP is but I never memorized what the letters stand for. Even if we spelled it out, that barely scratches the surface of what it is and doesn't make the article anymore informative for someone not versed in what BGP is.

Yes, it is usually standard practice in any formal writing. Slashdot is hardly formal though, when Bennet gets to spout his half formed ramblings every week.

"If only specific files, then simply decrypt those and host them separately"

You are the one who proposed hosting them unencrypted. I read and quoted exactly what you said. I don't have a reading problem at all.

" Decrypt, host separately... done."

Then again you say the same thing.

"A little file the thin clients grab as part of the login script."

You're the one who proposed access controls as part of your architecture. Go back and read your initial statement.

PGP is an example of asymmetric encryption. You have to encrypt a copy of the payload for each receiver. This is why it's great for messaging, and exactly what I was talking about why its applicable only when sharing something between two people. Whenever you send a message to multiple parties, you have to encrypt a copy of the message separately for each receiver. When you try to apply this same technique to file sharing, it means potentially large files have to be duplicated to allow them to be encrypted with each receiver's key.

"First rule of computer security is physical security."

Indeed. That's exactly why smart cards are superior. The private key is on the card, and the card is always physically with the owner.

Otherwise you have to lock your office and the cleaners can't do their job. Are they just gonna clean the hallways?

" that is all you need."

No hardware is not all you need, you have to build an architecture and software platform. you said yourself:

"You have per client access rules and passively encrypt everything. What is more, the encryption keys can be held on office thin clients that transparently download the decryption engine and keys from an onsite server"

Someone has to do onsite key management. Either you are manually copying keys to each thin client, or your onsite server has ACLs that decide who gets what keys. It also needs to be able to integrate with the cloud storage to pull the upstream encrypted files, which means implementing whatever API is used to access the upstream server. Most small businesses I know, even if they have a couple programmers, aren't skilled enough to grasp these web APIs.

"Decrypt, host separately... done."

Then anyone at the hosting company can access the decrypted files. You're just describing the same process in use today that is vulnerable to all the problems we were addressing above. You missed the whole point of the discussion.

"Your private key is useless for securing information originating from you, since your public key is, well, public."
"Your private key is useless" ... " since your public key is, well, public."
You are arguing the private key is useless because the public key is public. That is utter nonsense. Your private key is not useless. The whole point of public/private key pairs is that one is public and the other is private.

With assymetric encryption, the sender uses their private key, and the receiving party's public key. The process creates an encrypted payload that only the receiver can decrypt. This is a good place to educate yourself on how public-key cryptography works, aka assyemtric encryption: http://en.wikipedia.org/wiki/P...
"Public-key encryption, in which a message is encrypted with a recipient's public key."

"'combining your private key and their public key' statement is nonsense"
No you idiot, that's exactly what asymmetric encryption is. You need to educate yourself before you start telling people what is nonsense.

I have implemented several forms of asymmetric encryption leveleraging Bouncy-Castle Crypto libraries, and have done extensive reading of the RFCs related to these processes.

You also don't understand symmetric encryption but enough time wasted on you.

It doesn't. As far as I can tell from his vague description of XOR'ing "random bits" with "nonrandom bits", he's talking about a very specific mode of using AES, which is OFB or CTR. In both cases it is clearly documented that reusing the key stream would destroy security. As long as you follow the specification for these modes it is secure.

Someone could probably make a business of exactly the architecture you describe, providing a small onsite appliance that does this orchestration. So you use their cloud storage solution, and they provide an architecture that guarantees only your onsite appliance has the keys capable of decrypting the data.

"What is more, the encryption keys can be held on office thin clients that transparently download the decryption engine and keys from an onsite server which likewise can serve both to remote users as part of their login script."

This would be a great architecture for a business when talking only about accessing data that is shared among employees.

However, if they want to share certain files with another business to remotely access the encrypted data, then you have to also share the encryption key to support client side decryption, and you encounter the same problem as before. There are certainly businesses that have moved the majority of their data storage to the cloud, but there are a greater number who haven't made that kind of commitment, and only use cloud storage for sharing certain files/data with business partners. You could host a local server that retrieves the data from the cloud, decrypts it using the onsite stored keys, and serves it to authenticated business partners. This would mean deploying onsite the your own implementation of a web API or website that provides the interface for third parties to login and access authorized data. Half the reason to move to the cloud is to avoid implementing, deploying, and managing this kind of infrastructure.

And of course for individuals sharing with other individuals, this approach doesn't work either.

Essentially, as even your example demonstrates, somewhere a central system must orchestrate access and decrypt the data or provide keys to clients. Moving that system onsite mitigates risk by putting it in your control and affording the business the opportunity to legally challenge information/search requests, but it also decreases the benefits of using the cloud since you've now moved a major piece of infrastructure back onsite.

Not disagreeing with you, but want to clear up what it means to make cloud storage, or any type of server storage, secure and inaccesible from court orders:

In the case of dropbox, data is stored encrypted, but the server software holds the encryption keys so it can serve the data to clients unencrypted. This means subpeanas and other legal/law enforcement actions can access the data by going to the server operators, who likely will not challenge the order.

If you instead encrypt the data client side before you send it to the server, then everyone who accesses the data must also have the key.
What if you want to revoke access for one person? You have to download the data client side, decrypt/re-encrypt with a new key, reupload, provide key to remaining sharers. So this technique only really works for data that you do not share, i.e. just your personal stuff, and is essentially what people do now when they encrypt data before uploading it to dropbox.

Asymmetric techniques don't really apply here unless you're only sharing with one party. You combined your private key and their public key to encrypt the data, then only they can decrypt it. This does not work when dealing with 3 or more parties, unless some are going to share the same key for one side of the asymmetric encryption, in which case you're back to the same problem we had with sharing a symmetric key.

"shouldn't cost us knowledge"

Oh I comprehend, that he thinks the content belonged to "us". If it does, then he his welcome to setup hist own host and host that content. Nothing is lost if you exercised your right to make a copy under the CC license, assuming it was licensed that way. If not, then it didn't belong to us.

Who the fuck are you to say this or that entity is obligated to be your personal content host? It's not your fucking server. If I run a website, and I decide that an article is out of date and I take it down, that's might right as the owner of that server. Fuck you.

Content and knowledge are related, but are not the same. If someone stops delivering content, that doesn't mean the knowledge is lost.

What you don't comprehend is the distinction between having knowledge, and actually where it is hosted.

This is not like we've taken every written record of physics and banned it. 1) You are still free to host the content at your own free will. 2) That "knowledge" exists in many other forms, so even if was not licensed the knowledge is not lost.

So your point is, if twisted juuust right, any slashdot article can somehow be an opportunity for someone to bitch about Obama.