Shared publicly  - 
A different couple security issues, relating to e-signatures:

1. For compliance w/ esign laws, it's best if the text being signed is locked down somehow, so that instead of just setting a "Yes they put their name in the box" flag somewhere, you save a signed version of the whole document.

One obvious way to do this is PGP. If the user has PGP, it's trivial: get and store their pubkey, offer them plain text to sign, confirm the sig and signed plaintext, and sign the whole with the server's key.

Suppose however that the user doesn't have PGP. You could generate a keypair for them, keep it stored on the server, and only look at the privkey password in transit for use during creation and signing.

Since you don't keep the password — only the user does — only the user could have authorized signing the document, and the document can't have been modified afterwards. This satisfies all the major requirements of esign laws.

However, it's not clear what to do if they forget their privkey password; PGP has 'revoke the whole thing' but it doesn't have 'revoke it as of date X and replace with this new key, the old sigs are still valid before X'.

Also, it'd be better if the privkey could be stored more securely than just being locked with a user submitted password. I'm not aware of any client-side PGP signing JS (there's PGP encryption to a known pubkey), and client side storage would break if they use a different browser or clear cache; it's not persistent enough. Server side is better than nothing, but still.

2. Further, it would be good to make the document such that its timestamp is provably true (at least, within a day or so).

You can prevent forging a later sign date by e.g. including that day's closing stock market prices or NYT headline within the signed plaintext.

However, how can you prevent forging an earlier sign date — ideally in a way that doesn't require a network of other repositories to trust?
Alexia Death's profile photoRichard Gadsden's profile photoRyan Castellucci's profile photoZack Weinberg's profile photo
HTML5 local storage. see bitcoin clients that store keys locally but use a remote server for blockchain.

For non-forgeability of earlier signatures: hard :/
+Sai Store encrypted key on server, send it to client, decrypt it locally with passphrase then? That way server never sees the decrypted key.
I wonder how hard NaCl bindings would be.

(and that would be work I could easily do that would be dual-purpose, and that GOOG would probably approve of)
This might be a good use case to take to the BrowserID people.
+Sai There's a mechanism using java or silverlight plugins too, but that's ugly :(
What I mean is, the BrowserID people might be amenable to adding this kind of functionality; they're already expanding it in various directions.
+Sai To this day, MIT uses Java for signing up for an Athena account for the first time, because it's likely to be cross-platform >.<
Crossposting from stackoverflow:

First, read this article:

If you are still convinced that javascript crypto is a good idea for what you're doing, then:

PGP is fairly complicated and you don't need 95% of what it does, I would recommend that you instead consider using Ed25519 for signatures - a javascript version is available at . It's an elliptic curve based system that is substantially faster than RSA with equivalent security and much smaller keys. The keys are so small, in fact, that you can have the user choose a 'signing passphrase', feed it to scrypt[1] with their user ID as the salt, and use the output as the private key (you just need to frob three bits to make it a valid Ed25519 private key). This is cool because it doesn't require the private key to be stored - it's deterministically re-generated when needed.

+Steven Sudit Client certificates can't be used (at least by default) to sign arbitrary plaintext in a manner that's verifiable down the line, only authenticate an SSL session.
Client-side certificates require local storage and are a massive pain to move between browsers, but they do support signing arbitrary text (OpenCA does it, I can't be bothered to look into how).
+Steven Sudit Client side generation of secure RSA keys would be unbearably slow and signing operations annoyingly slow which is why I suggested using elliptic curve signatures.
In estonia we have public e-signature infrastructure tied to our national ID card that is also a chip card holding our keys. One for ID and one for signing. If you forget your signing pin, you still can recover it using the cards PUK code. IF you mess that up 3 times too, you need to go get new ID card issued with new keys and new certificates.

The document signed is hashed and the hash along with some metainfo about the file is is signed. Then the whole thing is packed in a container.
On the datestamping challenge, one option would be a timestamping server -, or, or are used for timestamping Authenticode signatures, for example.

I don't know of a web-of-trust solution for this problem, though; with timestamps you have to trust the timestamp server.

The only thing I can think for restricting the timestamp to be no earlier would be to store a piece of data that would be difficult to fake later, but would still be verifiable, e.g. a high-quality photograph of the night sky. Planetary positions would date it pretty exactly, but it would be tremendously difficult to photoshop such a pic.
+Richard Gadsden Time-stamping servers are designed to be good enough that the signature stand up in court, which is fine for this use case.
I don't think I understand your requirements well enough to represent them to a third party. Just to clarify, you wouldn't be depending on a third-party service, though, you would be depending on new browser features.

(And I'm going to have to mute this thread now, because I have tons of stuff to do and need to minimize distractions, and mainly I have nothing to add.)
Add a comment...