[Cryptography] Came up with a weird use case, got questions Crypto
My mom passed in 2013. I had a nice day, where my wife, daughter, and myself, went to an interesting and fun wedding today. I had a random thought, that I would have loved to talk to my mom, and tell her about it. Obviously, not possible, short of a OUIJA board. :) So I thought about writing a letter. So where do I post it? So I thought of a website, where you can send letters to people, a la Postsecret. But it's harder to anonymize electronic messages. Soooo, how about a system that automatically encrypts incoming emails? And then, some time later, it decrypts, long after anyone who wrote those letters is alive? Say 100 years. I'd write a letter to my mom which would be auto-decrypted 100 years later and given to the public. A la Post secret, and historical interest. Any systems out there which will auto-decrypt, not based on a clock (which can be spoofed), but instead based on an event, a piece of information, a trusted info source? Something like the Long Now foundation's clock? Weird use case, I apologize. Just a thought. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
> On Jan 5, 2019, at 8:40 PM, Joshua Marpet <joshua.marpet@guardedrisk.com> wrote: > Any systems out there which will auto-decrypt, not based on a clock (which can be spoofed), but instead based on an event, a piece of information, a trusted info source? Something like the Long Now foundation's clock? This is not weird at all, US Census has exactly that requirement. They have a law that requires all the census responses be secret for 70 years and then public after that. There is no clock based system that I know of that does not require a trusted third party or a trusted group of third parties. The group idea would be similar to the NIST Beacon <https://csrc.nist.gov/CSRC/media/Presentations/The-NIST-Randomness-Beacon/images-media/day2_demonstration_1100-1150pt1.pdf>; (which is offline at the moment due to government shutdown) that has similar services in Chile <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=2ahUKEwiAo6ym5dnfAhWC_p8KHaMtD34QFjADegQIBxAB&url=https://beacon.clcert.cl/&usg=AOvVaw3RvRIynvzWS-KJpSZBJ-VV>; and maybe Brazil <http://science.sciencemag.org/content/360/6396/1383>;. The idea would be to use SSS to break up the key in m of n and send n pieces to different time escrow services with a statement to release in 100 years. As long as m do not collude to release the secret, the secret is safe. As long as n-m continue to operate in 100 years, your secret will be released. Less likely ideas would be to: Encrypt with 1024 bit RSA and in 100 years it “should” be easily breakable. Ditto for AES 128. Put the key on a rocket that will take 100 years to make a specific flight. Use a radio to bounce a signal off a star 50 light years away. Jim _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Den sön 6 jan. 2019 06:23 skrev Joshua Marpet <Joshua.Marpet@guardedrisk.com >: > > Any systems out there which will auto-decrypt, not based on a clock (which > can be spoofed), but instead based on an event, a piece of information, a > trusted info source? Something like the Long Now foundation's clock? > There's a few possible variants, each with different properties that you may or may not want. Time-lock cryptography, which is essentially hashcash / proof-of-work, wherein the work task (for symmetric algorithms) is created in parallel and then chained such that they only can be solved serially, which means that assuming a certain maximum CPU speed (!) you can enforce that a minimum time passes (by enforcing that a minimum number of CPU cycles passes). However, without incentive nobody will try to solve it. Dead man's hand schemes. They're typically not based on cryptography, instead they rely on a mechanism that will outlive you to trigger an event. You can combine it with cryptography - it would for example work just fine to combine this with Shamir's Secret Sharing Scheme by setting up multiple computers that will run non-stop (perhaps a few solar powered Raspberry Pi:s), placed in different locations, and when the time is up they each release their share of the secrets. This is quite fragile, partially because you can't know for sure what electronics will last 100 years, and because it's just as hard to know what companies you could outsource the task to which would last 100 years and uphold the promise. Lastly, assuming there's some entity that can simply be trusted just to continously perform some repetitive task for the entire time (such as just publishing the current time, digitally signed), not tampering with the clock, then functional encryption / indistinguishable obfuscation could work. You'd create a cryptographic program that only releases its secret if given a signed message with that future date. The issue with this one is that we don't even have any proper prototypes of cryptographic algorithms that can do this yet, we're still in the theoretical academic phase and don't know for sure if these algorithms can be sufficiently secure. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On Sun, Jan 6, 2019 at 12:23 AM Joshua Marpet <Joshua.Marpet@guardedrisk.com> wrote: > My mom passed in 2013. I had a nice day, where my wife, daughter, and > myself, went to an interesting and fun wedding today. I had a random > thought, that I would have loved to talk to my mom, and tell her about it. > > Obviously, not possible, short of a OUIJA board. :) So I thought about > writing a letter. So where do I post it? > > So I thought of a website, where you can send letters to people, a la > Postsecret. But it's harder to anonymize electronic messages. > > Soooo, how about a system that automatically encrypts incoming emails? And > then, some time later, it decrypts, long after anyone who wrote those > letters is alive? Say 100 years. I'd write a letter to my mom which would > be auto-decrypted 100 years later and given to the public. A la Post > secret, and historical interest. > > Any systems out there which will auto-decrypt, not based on a clock (which > can be spoofed), but instead based on an event, a piece of information, a > trusted info source? Something like the Long Now foundation's clock? > > Weird use case, I apologize. Just a thought. > It is actually an example of a very common requirement for timed release of information or release on specific criteria. This is in part what the blockchain's smart contracts are a nod towards. Use cases include: * Release of a person's will on their death * Release of a person's bank accounts etc. * Release of family secrets, national security, etc. I have a lot of information I would like to keep secret from my family until after my death and some stuff longer than that. I want them to know where I buried Aunt Agatha's jewelry but not where I buried Aunt Agatha. The timed version is going to require some form of notary. But it is easy enough to provide a robust disclosure protocol and I have anticipated this requirement in the Mesh tools which allows use of Shamir secret sharing to provide additional robustness. [I have not yet implemented this particular service but I might well do so earlier than I planned as it gives me a podcast.] So let us imagine that disclosure authority (DA) creates a sequence of keypairs that are dated as follows: Hourly - for the next 240 hours. Daily - for the next 365 days. Monthly - for the next 120 months. Annually - for the next 100 years. The DA releases the corresponding private key at the specified time. So for the simplest escrow protocol, we simply encrypt under the corresponding public key. This is not very robust though and especially so if we want to achieve long escrow times. For this we need to provide for separation of duties and use multiple DAs with a quorum. So let us say we want to escrow the data for ten years. Three DAs and a quorum of Two should be sufficient. We encrypt the data under a master key, split the master with Shamir Secret Sharing and encrypt each share under our selected DAs. If we want to keep the data for twenty, thirty or more years, we would need to have more shares. This protocol is not perfect, it is still possible for a coercion attack to work. So if I was going to escrow really important information I would want there to be additional controls provided through use of verifiable ceremony. But as soon as you go to ceremony you are limited to quarterly operations. We can also make use of threshold crypto at the DA level. So the DA might actually have three hosts that each disclose a share. The most useful form of DA would be one that will disclose information UNLESS the party takes some action. So the data is disclosed unless I say it should be kept private. But that is really difficult to achieve robustly. The nearest I have is that the DA reads a list of signed notices saying 'don't release X' and only decrypts the escrowed data that isn't on the list. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On Sat, 5 Jan 2019 23:40 Joshua Marpet asked: … > Soooo, how about a system that automatically encrypts incoming emails? And > then, some time later, it decrypts, long after anyone who wrote those > letters is alive? Say 100 years. I'd write a letter to my mom which would > be auto-decrypted 100 years later and given to the public. A la Post > secret, and historical interest. > > Any systems out there which will auto-decrypt, not based on a clock (which > can be spoofed), but instead based on an event, a piece of information, a > trusted info source? Something like the Long Now foundation's clock? I remember a similar request being discussed many years ago, after some politician or the like was required to turn over his private diary to some legal proceeding. The idea was to come up with a public key that could be used to encrypt a diary, where the corresponding private key would only be released some time well in the future. One suggested approach was to generate keys for, say, ten-year intervals and secure the private keys with an m out of n secret sharing system. The key shards would then be entrusted to a dozen or so reputable agencies, such as university libraries, in different legal jurisdictions, who would agree to hold the keys in secret until the appointed times. There were also discussions of ceremonies to create the keys in a way that would be trusted. I remember the suggestion being made that any such ceremony protocol be reviewed be a good professional magician before being declared foolproof. Another approach suggested, if I remember right, was to store the private keys in satellites placed in orbits that only return to earth infrequently. With several large satellite constellations in development or being proposed, all with much more computer capability than was common decades ago, adding a delayed key service might be quite feasible. Arnold Reinhold _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
So... about the incentive to break a key... Let us imagine that we got millions of people to take cat pictures and escrow them. Then there would be an incentive to break the key. Problem is that it is impossible to predict how fact hash mining will be in five years let alone 100 so those schemes fail. People really like cat pictures. The rocket solutions are in effect merely a different type of clock. And the physics of those are really hard because electronics degrade in space and things burn up in the atmosphere. The most robust schemes in practice are going to involve ceremony and some form of trusted hardware. We could build a HSM such that it will only release the data if it receives a signed statement of the current time from a trusted source. Throw it in a vault and bring it out after 100 years. It will probably work. If built right. Establishing a quorate notary that can be trusted to sign time is rather easier. Each notary would have to delegate its function to a successor periodically but that should not be too difficult to ensure. Of course there is then a real risk that the data is lost because the notaries don't continue their function. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On 1/7/19 at 10:38 PM, phill@hallambaker.com (Phillip Hallam-Baker) wrote: >The most robust schemes in practice are going to involve ceremony and some >form of trusted hardware. We could build a HSM such that it will only >release the data if it receives a signed statement of the current time from >a trusted source. Throw it in a vault and bring it out after 100 years. It >will probably work. If built right. > >Establishing a quorate notary that can be trusted to sign time is rather >easier. Each notary would have to delegate its function to a successor >periodically but that should not be too difficult to ensure. > >Of course there is then a real risk that the data is lost because the >notaries don't continue their function. There are a lot of causes of risk of data loss. Bit rot in storage media is a real worry. The best solution is to copy the data regularly. For the encrypted data, the only downside is the storage cost. For the keys it introduces a new complication in maintaining secrecy. There is also risk of transistor failure in the HSM due to dopant migration over time. We don't have experience with transistor equipment over long periods of time. Our experience with tube equipment, which is about 100 years, is that electrolytic capacitors die unless treated with a low voltage for a while to rebuilt their insulation layer. Sometimes they die anyway. I can't think of a way of keeping a HSM alive over long periods of time, certainly not one that is anywhere near as easy as copying data. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz | "I wish there was a knob on the TV to turn up the 408-356-8506 | intelligence. There's a knob called "brightness", but www.pwpconsult.com | it doesn't work. -- Gallagher _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
> > I can't think of a way of keeping a HSM alive over long periods of time > i am told that hsm lifetimes are constrained by the battery life of the tamper detect and wipe. HSMs have a means of changing the batteries. FWIW. Not saying this is the way to go... Mike _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
>> i am told that hsm lifetimes are constrained by the battery life of >> the tamper detect and wipe. > > HSMs have a means of changing the batteries. FWIW. Not saying this is > the way to go... honto???? with a three battery protocol? the mind boggles. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Randy Bush <randy@psg.com> writes: >> HSMs have a means of changing the batteries. FWIW. Not saying this is >> the way to go... > >honto???? > >with a three battery protocol? the mind boggles. Either there are two batteries and you swap the dead one out while the other powers the anti-tamper, or there's a supercap and you get X days to replace the battery. Peter. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On Mon, Jan 7, 2019 at 1:38 PM Bill Frantz <frantz@pwpconsult.com> wrote: > On 1/7/19 at 10:38 PM, phill@hallambaker.com (Phillip > Hallam-Baker) wrote: > > >The most robust schemes in practice are going to involve ceremony and some > >form of trusted hardware. We could build a HSM such that it will only > >release the data if it receives a signed statement of the current time > from > >a trusted source. Throw it in a vault and bring it out after 100 years. It > >will probably work. If built right. > > > >Establishing a quorate notary that can be trusted to sign time is rather > >easier. Each notary would have to delegate its function to a successor > >periodically but that should not be too difficult to ensure. > > > >Of course there is then a real risk that the data is lost because the > >notaries don't continue their function. > > There are a lot of causes of risk of data loss. Bit rot in > storage media is a real worry. The best solution is to copy the > data regularly. For the encrypted data, the only downside is the > storage cost. For the keys it introduces a new complication in > maintaining secrecy. > > There is also risk of transistor failure in the HSM due to > dopant migration over time. We don't have experience with > transistor equipment over long periods of time. Our experience > with tube equipment, which is about 100 years, is that > electrolytic capacitors die unless treated with a low voltage > for a while to rebuilt their insulation layer. Sometimes they > die anyway. I can't think of a way of keeping a HSM alive over > long periods of time, certainly not one that is anywhere near as > easy as copying data. > > Cheers - Bill > My current solution is to laser etch anodized aluminium plates with Shamir secret shares... _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
> > Let us imagine that we got millions of people to take cat pictures and > escrow them. Then there would be an incentive to break the key. > --I have to admit, I laughed. You REALLY like cat pics!!! :) > > Establishing a quorate notary that can be trusted to sign time is rather > easier. > --Agreed to a certain extent. In theory, this does make sense. > Each notary would have to delegate its function to a successor > periodically but that should not be too difficult to ensure. > --Sorry, I disagree. This is the "practice" part that I don't think would work. Same problem as most secret societies. First generation secret societies are all fired up, the next generation goes, "Why are we doing this?" and stops. Unless there is a monetization or religious reason, it's going to fail. > > Of course there is then a real risk that the data is lost because the > notaries don't continue their function. > --yup. Agreed. I love what you've talked about here. I just worry about the ramifications of depending on, effectively, secret multi-generational societies. <scratches head> weird one. Maybe we should just set up a religion. :) _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
On Tue, Jan 8, 2019 at 11:28 PM Joshua Marpet <Joshua.Marpet@guardedrisk.com> wrote: > > >> Let us imagine that we got millions of people to take cat pictures and >> escrow them. Then there would be an incentive to break the key. >> > --I have to admit, I laughed. You REALLY like cat pics!!! : > It was that or porn. Each notary would have to delegate its function to a successor periodically >> but that should not be too difficult to ensure. >> > --Sorry, I disagree. This is the "practice" part that I don't think would > work. Same problem as most secret societies. First generation secret > societies are all fired up, the next generation goes, "Why are we doing > this?" and stops. Unless there is a monetization or religious reason, it's > going to fail. > I was assuming that there would be a financial incentive. But it needn't be too much. For example, how about we begin by encrypting the notary master key under AES512 and splitting the master key 5 ways with a quorum of 3 and laser engraving the shares onto anodized aluminum plates which are immediately put into a tamper-proof evidence bag. OK so now lets put the shares somewhere public like a box in the center of DisneyWorld. The fact that there is a concentration of secret knowledge there becomes a tourist attraction in itself. This is part of what I mean by 'ceremony'. I love what you've talked about here. I just worry about the ramifications > of depending on, effectively, secret multi-generational societies. > <scratches head> weird one. Maybe we should just set up a religion. :) > The societies don't need to be secret, they just need to keep a secret. One could imagine founding a Freemason's lodge for the sole purpose of managing the secrets. And yes, there is a religious aspect to this. Many early religious practices are intricately bound to preservation, propagation and use of manufacturing secrets. The process for making Samurai swords for example. Every step is part of a ritual ceremony whose purpose is to ensure the correct outcome. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
jamesd@echeque.com wrote: > An SSH ed25519 public key in text format looks like this: > AAAAC3NzaC1lZDI1NTE5AAAAIPgXkBezz5jt2hlJwdqjJ5sbN5SlmxCYcNeNXGqMCPUf > > > And the corresponding private key in text format looks like this: > AAAAIAGYxPxNy0vT+BYZrhtvi8D9ZxNDQlyPccHhnz0Wi3jn > > Where are these formats, and their conversion to and from binary, defined? > Where is the source code - yes, I figure that since putty and openssh is > open source, it is somewhere in there, but perhaps I am being stupid, since > "where" is not altogether obvious to me. Kind of hoping to find not just > the code, but the reasons for the code. IIRC the formats used by OpenSSH are not defined anywhere but in their code. (I once went through that when trying to figure out how to convert between RFC4716 and OpenSSH formats: https://www.netmeister.org/blog/ssh2pkcs8.html) > And what with the AAAA fields? The format is base64 encoded tuples of four bytes of length of field followed by field, I think. So the leading 'AAAAC3NzaC1lZDI1NTE5' becomes 00 00 00 0b = length 11 73 73 68 2d 65 64 32 35 35 31 39 = ssh-ed25519 etc. etc. -Jan _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Jan Schaumann <jschauma@netmeister.org> writes: >IIRC the formats used by OpenSSH are not defined anywhere but in their code. >(I once went through that when trying to figure out how to convert between >RFC4716 and OpenSSH formats: https://www.netmeister.org/blog/ssh2pkcs8.html) I think everyone who implements SSH has done this at one time or another. In brief, it's just the base64-encoded form of the SSH public key record. Peter. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
89.2 MB 3,873 messages
Last sync: 15 July 2019 22:44

Move Messages

Save

Apply Labels


Warning: Unknown: write failed: No space left on device (28) in Unknown on line 0

Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php/sessions) in Unknown on line 0