Hacker News Reader

Comment by mbenjaminsmith | Hacker News Reader

I think this is neat. I can't imagine a use for it but I like the UI.

The fundamental problem with this:

There's no way to prove that the secret has been deleted and / or not copied. You have access to the plaintext and the password / url (presumably an encryption key). You (the malicious server operator or the compromised server) can do anything you want with the information.

This would be interesting if you could:

1) Offer end-to-end encryption. This would require encryption in the client which has its own issues.

2) Be able to provide proof that the information has been made inaccessible. This is not the same thing as having the link return a 404 the second time.

View on HN

Offer end-to-end encryption could be solved using a javascript library which encrypts/decrypts the secret in the browser, and passing the key behind a #, kind of the way mega.co.nz does it. Than you can always verify that what you typed actually never get's submitted to the host unencrypted.

Before I get to far into a topic I'm not an expert in, I'll refer you to these:

http://matasano.com/articles/javascript-cryptography/

http://tonyarcieri.com/whats-wrong-with-webcrypto

I'd say the main issue with that is sending an encryption package over an insecure channel. While you could verify the package independently (check a hash against a publicly known one) you're already into advanced user territory and the "encryption for everyone" point of this is gone.

you are pointing out valid concerns.

in terms of end-to-end encryption, what kind of client-encryption do you have in mind? usually, this involves steps that regular internet-users are not able or willing to handle. that's why i think such a service might be a great thing.

to your second point, how would you ever be able to proof that?

Those are really good questions.

> in terms of end-to-end encryption, what kind of client-encryption do you have in mind?

I didn't have something in mind, but Stanford has a good, relatively hard to screw up (by configuration) JS crypto library. But that's only part of the battle since we can't trust the delivery channel or the browser.

> usually, this involves steps that regular internet-users are not able or willing to handle.

That's right and underlines the single biggest reason crypto isn't really used by most people apart from HTTPS.

> to your second point, how would you ever be able to proof that?

That's a really interesting question. It might not be provable. I wasn't trying to be cryptic (excuse the pun) but that was really the point I was making.

I will be open sourcing the code once I've cleaned it up a little.

Doesn't solve the problem he's describing since it won't prove that the published code is what's running.

you can host it yourself?

It was my understanding it is supposed to be used to pass secrets between people. If I host my own I may trust it but you may not.

then i guess there's no service for both of you

Nor it will prove that code is not running inside a malicious VM that shares its memory with other applications.

Yes, but other people will be able to further develop the ideea in a more satisfactory manner.

Hey Adam,

Would you mind discussing your product over on Product Hunt? What's your twitter id?

Reply on news.ycombinator.com