h a l f b a k e r yMay contain nuts.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
Suppose you have an important email to send that you'd like to get independently witnssed - to prove what you sent, who you sent it to, and when you sent it. However, you don't want to pay a notary or somesuch to witness it.
Maybe you'd like proof of posting of every single email you ever send on
the small chance that maybe one day you'd need to be able to prove what you sent, when you sent it, and who to, of one of them.
Or you've got a really good digital photograph and want help - on the cheap - of asserting your (copy)right to it, or a great idea for an invention and want to be able to prove when you thought of it.
And you don't really "get" stuff like digital signatures: there hasn't really been great takeup of this sort of thing by mass-market consumers, who these days are producing billions of digital images and relying more and more on email.
This is an idea for a service - maybe web based - where you can send your email or upload your digital material. The service would associate the transaction with an accurate timestamp probaly in the neutral-timezone UTC, and a unique-random globally-unique identifier (GUID). Maybe by computing a hash of the input and storing this with the timestamp and GUID.
A key thing is that the GUID is unique-random: it's not in itself a hash computed from the input. This should mean that no amount of brute-force attacking can compute it from the original input.
If in future there's some dispute about the what and when and who, the original input and the GUID can be input into the system, the hash is recomputed to check against the stored hash, and voila there's your proof (or otherwise)!
e-TimeStamp
http://www.digistamp.com/
Electronic notary service. [jutta, Oct 28 2006]
Surety
http://www.surety.com/
Another one. [jutta, Oct 28 2006]
Stamper
http://www.itconsult.co.uk/stamper.htm
The indie version. Posts to alt.security.pgp. I don' t whether it still works. [jutta, Oct 28 2006]
RFC 3161: Time-Stamp Protocol (TSP)
http://www.ietf.org/rfc/rfc3161.txt
[jutta, Oct 28 2006]
OpenSource: OpenTSA
http://www.opentsa.org/
If you wanted to start one, you could use this! [jutta, Oct 28 2006]
Cut-and-paste interface for SHA1 digest
http://www.certum.p...rvices/ts/sha1.html
[jutta, Oct 28 2006]
SHA1 / MD5 digest applet
http://www.jensign....digestTS/index.html
Disclaimer: not baked by me - trust at own risk. My baked digest applet is currently in a number of messy pieces [RandomOracle, Oct 28 2006]
Docverify - www.docverify.com
http://www.docverify.com
I use it and it truly works like a digital notary to be able to prove what, who, and when. [jwhite128, Jan 12 2008]
[link]
|
| |
//And you don't really "get" stuff like digital signatures//
//Maybe by computing a hash of the input and storing this with the timestamp and GUID.// |
|
| |
Maybe I don't get it either, but that sounds kind of like a digital signature to me. |
|
| |
It's completely transparent to the user - the hash computation is all on the server side. Their experience would just be of filling in a boring old web form and receiving a reasonably short GUID |
|
| |
When I read the title I thought that a couple of avatars were going to come and try handing me a spamphlet. |
|
| |
Another thing, since the GUID is unique-random, hence unpredictable, there's no way of knowing if GUIDx relates to a point in time before or after GUIDy, unlike say a sequentially generated GUID scheme |
|
| |
It sounds OK to me, except that the GUID should not be stored with the hash. |
|
| |
Basically, we reinstitute manditory copyright registration, the removal of which has destroyed much of the art in the US, while also providing us with interesting opportunities (can you imagine bloggers waiting for copyright registration before posting?). |
|
| |
Maybe reinstitution of copyright registration in an automated form like this would solve the problems while securing the benefits of the current system. |
|
| |
But, how do you blog about the registration service having an outage? |
|
| |
[ironfroggy] //how do you blog about the registration service having an outage?// |
|
| |
It's true that such a system would need to be built to exacting standards so as to be abe to really deliver the promises it makes to consumers. I see the issue of verification longevity as problematic: if the service ceases to exist how can the association between issued GUIDs and content be verified? I guess you could bolster the system with the use of some form of widely-witnessed publication (usenet, p2p, the press?) in association with independently verifiable regular crypto like OpenPGP. |
|
| |
All while keeping it as simple as something like sending an email, from the perspective of the end user. |
|
| |
[Ling] //except that the GUID should not be stored with the hash// |
|
| |
I think it's probably because I misunderstood your idea. I read it through a few more times - my brain is a bit slower than normal, today, and in a sense your idea is like using a one time public key for encryption, and including the public key in the input before encryption, and no private key is available? |
|
| |
[21 Quest] Yes that's true. But it's easy to fake items in your "sent messages" folder. Hence such items likely of little value as "evidence". |
|
| |
[Ling] Yep! The original idea was an extemely usable way of mass-market consumers being able to achieve the same standards of digtal proof that you would normally need to be fairly tech-savvy to achieve. |
|
| |
One of the interesting things to emerge from playing with the idea is that you can get a GUID, and then embed it in the source material, and then complete the "registration". It's kind of like embedding the hash in the material used to compute the hash! |
|
| |
Now, why not have the website output a signature, too, for offline checking? ;-) |
|
| |
[ihope127] Yes. The system could (likely would have to) use something like [Open]PGP to sign a "message" where the message contains bits and pieces like the content URL, GUID, timestamp, participants, the hash etc. Users still have the convenience of just being able to use the GUID + content to verify. And if the servce is unavailable - offline or out of business - there's still the means to verify the association using established tools. |
|
| |
The signed message is emitted as a user-friendly "certificate" - in the sense that if printed off it looks like something of importance. |
|
| |
There's probably the need do something about signing key revocation policy, and widely-witnessed publication of some sort of cryptographic checksum. |
|
| |
[jutta] Yes, there's surety, digistamp/e-timestamp, codelmark, protectmywork, genuinedoc, etc. They're all based on regular crypto, and not focussed on mass-market. Systems based on RFC3161 - Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) abound. |
|
| |
Few key differentiators of this idea are that it's intended for mass-market, the output (GUID) is not in any way computed from the input, and there's no way of knowing if GUIDx was generated before or after GUIDy. |
|
| |
Whether this useful or not, and whether or not there's a mass-market niche for this sort of concept, is indeed moot... |
|
| |
The general concept is called a "TSA", or "time stamping authority". The consumer offering is usually called a "digital notary" or "electronic notary". See links for companies, an Internet protocol, and open source software to run one yourself. |
|
| |
I found a web interface for timestamping SHA1 digests, but none that computes the SHA1 digest itself and has you post or paste the document. |
|
| |
Maybe the market of people who see the usefulness of a timestamp, but don't know how to compute a SHA1, and don't think there's a bandwidth and privacy problem with posting their documents to a central server, is somewhat small. |
|
| |
[jutta] I've played around with a few cool applets to compute digests on the (web) client - hence resolving bandwidth and privacy (if you trust the code-signer) issues. Including *huge* video files in quite a reasonable time. |
|
| |
And I'd envisage a variety of clients - maybe an Office plugin where, again, the hashing would take place on the client, doing the "registration" stuff via, e.g., SOAP calls, leveraging the common server code base. |
|
| |
It could indeed be a consumer-friendly TSA implementation, wtih the added-value unique features as described in my other comments. |
|
| |
Youre totally right - it's a tricky call regarding size of market. This sort of thing could be much pricier to build and trial than a MySpace or YouTube, and in the end maybe only a couple of paranoid cheapskates (this would be for the most part a *free* service ) would use it. |
|
| |
There are however something like 60 (small) billion email transactions per day. And who knows how many blog posts, digital photos or videos? |
|
| |