lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
From: andfarm at teknovis.com (Andrew Farmer) Subject: Time Expiry Alogorithm?? On 21 Nov 2004, at 17:18, Tiago Halm wrote: > Gautam R. Singh <gautam.singh@...il.com> wrote: >> I was just wondering is there any encrytpion alogortim which expires >> with time. >> For example an email message maybe decrypted withing 48 hours of its >> delivery otherwise it become usless or cant be decrypted with the >> orignal key > > Scenario: > Lets imagine there is a "trusted", non-hackable third-party which > handles a > timestamp database along with private/public keys. Lets cal it Trent. > Trent > manages timestamps in terms of existence and validity. Each timestamp > can > only be used once and only once. Each timestamp, as soon as it is > created > has also associated a validity window outside of which it will be > considered > as invalid. Whenever a timestamp its checked for existence, it will be > marked as used, and hence becomes invalid afterwads. Each timestamp is > also, > obviously, unique. > > Alice has a message. Alice asks Trent for a timestamp. She generates a > hash > of the message, and then she signs the hash and the timestamp with her > private key. She sends the message and the signature to Bob. > > When Bob receives the message, Bob decrypts the signature with Alice's > public key and sends Trent the timestamp for validity check. Trent > finds the > associated timestamp in its database, sends Bob a positive response and > invalidates the timestamp. > > While Bob wants to be sure the message originates from Alice, Alice > wants > the message to be valid (as originating from her) for only a certain > period > of time. > > Conclusion: > If a certain validity (48h) is given to the timestamps, this may lead > to a > valid solution for the situation described above. > How reasonable is this? Read the request again. What you've described is a system for expiring signatures, not for expiring the message itself. Now, you *could* have Trent generate a key to encrypt the message with, which would solve the original poster's problem, albeit in a rather unsatisfying way. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20041121/8116af8d/PGP.bin
Powered by blists - more mailing lists