Re: Sharing/Storing a private key
On 16/12/13 23:41, Doug Barton wrote: but one argument against what you're suggesting is that it's only as secure as the encryption used in step 1 of the hybrid approach. If only everything in cryptoland was only as secure as 3DES... The ability to apply SSS to the entire secret would be quite valuable I don't see why. If this is because you avoid insecurities in symmetric crypto, I just don't buy it. Otherwise, please explain. although your concern about entropy use is something that should be addressed explicitly. And how do you propose to do that? You can't conjure up good quality entropy. And if you don't trust symmetric crypto, you can't use that to create an almost-random stream either. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Sharing/Storing a private key
On 12/18/2013 08:53 AM, Peter Lebbing wrote: On 16/12/13 23:41, Doug Barton wrote: but one argument against what you're suggesting is that it's only as secure as the encryption used in step 1 of the hybrid approach. If only everything in cryptoland was only as secure as 3DES... I understand that you're not interested in an argument that the encryption of the entire secret may not be secure, but everything is secure right up until it isn't. (Robert, please ignore my tortuous use of secure in that sentence.) :) The ability to apply SSS to the entire secret would be quite valuable I don't see why. If this is because you avoid insecurities in symmetric crypto, I just don't buy it. Otherwise, please explain. Completely aside from the possibility (however remote) of the crypto failing, I'm also thinking of layer 9 issues that can come into play. For example I was the one who proposed using SSS to distribute portions of the root DNSSEC KSK to members of the community to provide a disaster recovery procedure should something catastrophic happen to ICANN. They didn't finish the root key protocol until after I left IANA, and what they ended up doing instead was using a HSM to store the key. But they did end up using SSS with members of the community to share the password for the HSM, for the same reason I proposed. If the HSM hadn't come into play the politically expedient thing to do would have been to distribute pieces of the secret, rather than pieces of the key used to encrypt the secret. Now I realize that most of the people on the list aren't interested in layer 9, but some of us live in a world where it is necessary to do so. :) although your concern about entropy use is something that should be addressed explicitly. And how do you propose to do that? I don't, I was suggesting that your concerns are valid and that the author of the new software is responsible for addressing them. Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Sharing/Storing a private key
On 12/18/2013 1:25 PM, Doug Barton wrote: (Robert, please ignore my tortuous use of secure in that sentence.) :) Hey, I was being *nice*. I wasn't even pointing out that 3DES only has 112 bits of keyspace... ;) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Sharing/Storing a private key
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Well, I'm really sorry to have set up such a conversation :o) As I said earlier I'm not quite good at crypto-things, all I wanted to do was to protect my private key easily in case of HDD error. And all I wanted to do with this little tool was to share it with you. If you can explain to such a nooby-noob like me what matters, I'll try to do my best not to make you loose your time ;o) Mindiell, Le 18/12/2013 17:53, Peter Lebbing a écrit : On 16/12/13 23:41, Doug Barton wrote: but one argument against what you're suggesting is that it's only as secure as the encryption used in step 1 of the hybrid approach. If only everything in cryptoland was only as secure as 3DES... The ability to apply SSS to the entire secret would be quite valuable I don't see why. If this is because you avoid insecurities in symmetric crypto, I just don't buy it. Otherwise, please explain. although your concern about entropy use is something that should be addressed explicitly. And how do you propose to do that? You can't conjure up good quality entropy. And if you don't trust symmetric crypto, you can't use that to create an almost-random stream either. Peter. - -- Mindiell -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlKyCscACgkQUrT9WwBwY7zakQD/YTei8nEPmIL+aiPrF+lVqJPP POvkULr4DoDGA+bV63cA/2rUxaY8epxpdtbQtT44zEJ6fL6cwO3Go4jtRPy2LSNu =i3nj -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Sharing/Storing a private key
On 12/15/2013 04:58 AM, Peter Lebbing wrote: On 14/12/13 21:14, Leo Gaspard wrote: Maybe if you explained what the limitations of are...? My guess is the fact that only supports secrets up to 1024 bits; if you want to share a larger secret you need to do a hybrid approach where you symmetrically encrypt the data and then use secret sharing for the randomly chosen encryption key. If I understand Mindiell's message right, his implementation works for larger secrets. But I don't see why you wouldn't just use and the hybrid approach. I haven't looked at Mindiell's software, but one argument against what you're suggesting is that it's only as secure as the encryption used in step 1 of the hybrid approach. The ability to apply SSS to the entire secret would be quite valuable, although your concern about entropy use is something that should be addressed explicitly. Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Sharing/Storing a private key
On Sat, 14 Dec 2013 21:14, ekl...@gmail.com said: AFAIK, *is* an implementation of SSS. So, why would you write a new version? FWIW, a few years ago, Phil Sutter wrote a daemon for GnuPG which implements secret key splitting. I don't have the URL handy, but it should be easy to find. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Sharing/Storing a private key
On 14/12/13 21:14, Leo Gaspard wrote: Maybe if you explained what the limitations of are...? My guess is the fact that only supports secrets up to 1024 bits; if you want to share a larger secret you need to do a hybrid approach where you symmetrically encrypt the data and then use secret sharing for the randomly chosen encryption key. If I understand Mindiell's message right, his implementation works for larger secrets. But I don't see why you wouldn't just use and the hybrid approach. For one, it uses much less entropy, since Shamir's secret sharing algorithm requires a lot of it, I believe proportional to the size of the data to be shared. I haven't checked the code by Mindiell, but this sounds like a potentially big issue. It seems to me the hybrid approach is better. Since supports the hybrid approach, I don't see the need for a new tool. I do see use for a much simpler tool that makes the hybrid approach more accessible: pick a random key, and use that for invocations of both (openssl or gnupg) and . HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Sharing/Storing a private key
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 AFAIK, *is* an implementation of SSS. So, why would you write a new version? I must say I didn't look at the source, as I do not see the point at first. So, this is a warning about security issues : something you made yourself is likely to be unsafe. A tested implementation exists. Maybe is there really a point in writing it, but I can't see which. Maybe if you explained what the limitations of are...? HTH, Leo Hello, The demo of shows : - - a secret limited to 128 characters - - a generation of n fragments in once pass. You couldn't generate a new fragment later - - you have to copy paste each fragments after splitting, and right again on combination Plus, in the source code, you can see it is not using the modulo part, needing a specific lib (if I understood well). Finally, when I tried it on the demo page, if I enter less fragments than needed, it seems to raise an error which can help into discovering how much fragments are needed. In the end, it was a good exercise for me and I wanted to share it. And as a Python version it is runnable everywhere without compiling which seems to be a problem with the last version of . regards, - -- Mindiell -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlKtofQACgkQUrT9WwBwY7xd4wD9HCDe/Rb6uNZTvT+Jlm1SZLVU k2+hl/971LMU8EcBSzwA/RSJE+CV0+vdrwKWOZyK2XQp5du3lsH69SAic5RU9IRm =L9PN -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Sharing/Storing a private key
On Fri, Dec 13, 2013 at 12:12:12PM +0100, Mindiell wrote: Hello, I'm using GPG regularly and did want to save my private key. [...] I found (http://point-at-infinity.org//) too, but it wasn't really usable beacause it has too many limitations IMHO. So I did it myself : ShareIt (https://gitorious.org/shareit) [...] It is using the Shamir's Sharing Secret Algorithm (http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing). [...] Any Comments and/or critics are more than welcome, especially on security issues. AFAIK, *is* an implementation of SSS. So, why would you write a new version? I must say I didn't look at the source, as I do not see the point at first. So, this is a warning about security issues : something you made yourself is likely to be unsafe. A tested implementation exists. Maybe is there really a point in writing it, but I can't see which. Maybe if you explained what the limitations of are...? HTH, Leo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Sharing/Storing a private key
Hello, I'm using GPG regularly and did want to save my private key. On the IRC channel someone linked me to paperkey : http://www.jabberwocky.com/software/paperkey/ While this project is really interseting, it does not fit my needs. I found (http://point-at-infinity.org//) too, but it wasn't really usable beacause it has too many limitations IMHO. So I did it myself : ShareIt (https://gitorious.org/shareit) It's a very simple program which take a file (whatever in it a GPG key or a pdf, etc...) and generates some fragments which can be given to some contacts in order to store the document while not making it readable directly. It is using the Shamir's Sharing Secret Algorithm (http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing). I ever worked on a faster fragmentation this morning and will push it on the repo this evening (I can't from here). I planned a C version too, I hope to release quickly, but it is not really needed urgently because the Python version is fast enough to share a GnuPG key. Any Comments and/or critics are more than welcome, especially on security issues. Regards, Mindiell ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
