Re: Symmetrical encryption or ...
I installed keepassx. Not much use to me. 1. Illegible with my eyesight (reported to them) 2. Insufficient fields (seems to be non expandable). regards On 22 November 2014 02:37, Doug Barton wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 11/20/14 10:40 AM, Dave Pawson wrote: > | Requirement. Two machines (one Linux, one Windows). > | > | I want a secure file 'shared' between them, as a pwd-safe. > | > | Only I use the two machines, but need the file encrypted. > | > | Any alternatives to symmetrical encryption of a file? > > Either symmetric or PK encryption would suit your needs, but as > someone pointed out already, a better solution is to use a password safe. > > KeePass is an excellent solution, and I use the same password db > between Windows, Linux, and OS X (not in that order). :) You want to > use the lowest common denominator format between those systems, which > at this point is the 1.28 version for Windows, and the keepassx > version that comes with most Linux distributions (I use Ubuntu > primarily). For OS X it gets a little trickier, since the version that > includes auto-type is community sourced, but the person who produces > it is well trusted, and a lot of people use it. > > Schneier had an interesting blog post recently about password safes, > with a link to papers that did extensive research on them. KeePass > came out looking pretty good, as one of the key problems with most > password safes is that if the auto-type is truly automatic, it can be > triggered by malicious software and grab your passwords off the > clipboard in windows. While KeePass does have an auto-type feature, > you have to trigger the key sequence to use it, and that sequence is > user-configurable. And obviously you don't want to use solutions like > LastPass, where your stuff is stored in their cloud. The question of > "What if they get hacked?" is no longer academic, since it happened > recently. > > For synchronization between systems I use SpiderOak, which also has > clients for all 3 platforms. KeePass already encrypts the db file, and > SpiderOak, unlike most "cloud storage" platforms, encrypts the files > it backs up locally (on your system) with a special key that the > company does not know. The upload channel is encrypted to their > servers as well, so your data is never available in the clear. Because > they don't know the encryption key your data is never de-duplicated > with other people's stuff, although if you set up folder > synchronization between systems the same files will be de-duplicated > within your own account. > > ... and speaking of folder synchronization, one of the things I like > about SpiderOak is that you can set up arbitrary folders to > synchronize between systems, you don't have to put all of your stuff > in one folder. You can also configure it to exclude certain files from > syncing, which is handy to avoid synching the .lock file for KeePass. :) > > http://keepass.info/index.html > > https://www.schneier.com/blog/archives/2014/09/security_of_pas.html > > If you use this link to sign up for SpiderOak, I get free space. :) > https://spideroak.com/signup/referral/25c4971714a13f13c24fa98a43317dc2/ > > Or, here is the regular link, if you prefer: > https://spideroak.com/ > > hope this helps, > > Doug > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJUb/bPAAoJEFzGhvEaGryEq9EH/0pwRxi7PpJMlJs9yGOvdcBO > +oqL6uJ99U72kdmUeznLzSewN5pHJoKB26gHAqs2WvNnoNGDOfRKz89ijKxCOWbE > 8uJfz+AEqDJLe6CdLXSVTTa8SdLDydYUqrQZuV3aPxVPCCA91I4vi0HVB3MAlqLV > ndOEaX6wP6/GCqVDkHUDQ9V37jmFHa7jl2RKFXj5BRL31ztQuqVQ4VlCiVbZFvje > aipBL8p1l9EBdEUdQIM7tnykeP9EY+0F5zQmSqAuxxk+CFKQZBJ2FqZN1bnvi5OC > QQFaUy4sGQKdI/uoOQOVM5YHXzQxJ6tZY1zFUudQwcs/Sdi2EQkRZQVOpMHeeqQ= > =dI3t > -END PGP SIGNATURE- > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Symmetrical encryption or ...
Thanks Doug On 22 November 2014 02:37, Doug Barton wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Either symmetric or PK encryption would suit your needs, but as > someone pointed out already, a better solution is to use a password safe. > > KeePass is an excellent solution, and I use the same password db > between Windows, Linux, and OS X (not in that order). :) You want to > use the lowest common denominator format between those systems, which > at this point is the 1.28 version for Windows, and the keepassx > version that comes with most Linux distributions (I use Ubuntu > primarily). Noted. typically Secure access requires n items, login/pwd/mothers maiden name/ inside leg measurement etc... Can keepassx store a list of key:value pairs? I know some systems are restrictive in this area. I'm currently running Python code which dumps the dictionary content for use, direct from the decryption. So where do you store the data? Online for access from 3 machines? Dropbox? Seems an unnecessary exposure. I'll have a look. > > And obviously you don't want to use solutions like > LastPass, where your stuff is stored in their cloud. The question of > "What if they get hacked?" is no longer academic, since it happened > recently. Yes... > > For synchronization between systems I use SpiderOak, which also has > clients for all 3 platforms. KeePass already encrypts the db file, and > SpiderOak, unlike most "cloud storage" platforms, encrypts the files > it backs up locally (on your system) with a special key that the > company does not know. Another exposure? At least with a symmetrical encryption the files are only local... (Am I being too cautious?) > http://keepass.info/index.html > > https://www.schneier.com/blog/archives/2014/09/security_of_pas.html > > If you use this link to sign up for SpiderOak, I get free space. :) > https://spideroak.com/signup/referral/25c4971714a13f13c24fa98a43317dc2/ Thanks Doug. More options. > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJUb/bPAAoJEFzGhvEaGryEq9EH/0pwRxi7PpJMlJs9yGOvdcBO > +oqL6uJ99U72kdmUeznLzSewN5pHJoKB26gHAqs2WvNnoNGDOfRKz89ijKxCOWbE > 8uJfz+AEqDJLe6CdLXSVTTa8SdLDydYUqrQZuV3aPxVPCCA91I4vi0HVB3MAlqLV > ndOEaX6wP6/GCqVDkHUDQ9V37jmFHa7jl2RKFXj5BRL31ztQuqVQ4VlCiVbZFvje > aipBL8p1l9EBdEUdQIM7tnykeP9EY+0F5zQmSqAuxxk+CFKQZBJ2FqZN1bnvi5OC > QQFaUy4sGQKdI/uoOQOVM5YHXzQxJ6tZY1zFUudQwcs/Sdi2EQkRZQVOpMHeeqQ= > =dI3t > -END PGP SIGNATURE- > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Encryption on Mailing lists sensless?
On Nov 21, 2014 8:55 PM, "Ingo Klöcker" wrote: > > On Thursday 20 November 2014 14:36:35 Schlacta, Christ wrote: > > On Nov 20, 2014 1:58 PM, "Ingo Klöcker" wrote: > > > On Tuesday 18 November 2014 22:43:18 MFPA wrote: > > > KMail encrypts an individual copy for each BCC recipient. I thought > > > Thunderbird+Enigmail would also do this. > > > > > > Any mail client not doing this completely subverts BCC (unless > > > > --throw-keyids > > > > > or --hidden-recipient is used, but even throwing the key IDs still leaks > > > > the > > > > > number of hidden recipients). > > > > There's nothing preventing a list server or mail client from intentionally > > adding a pseudo random quantity of invalid or junk keys to the recipient > > list, thus obfuscating the number of additional recipients, only providing > > an upper bound to the estimate. > > Adding additional junk keys doesn't help if the recipient (or the recipients) > expect a certain number of recipients. If the message is encrypted to more > than (expected number of recipients)+1 (for encrypt to sender) then the > recipients most likely will wonder who the other recipients are. You'll have a > hard time convincing them that the "other recipients" are just fakes to > confuse a third party intercepting the messages. Perhaps a future version of the pgp specification should say something akin to gpg should always add a number of junk keys, perhaps to pad the key list out to one from a list of constant sizes, just to ensure that nobody can know for sure how many recipients there are (except the sender), and can at best place an upper bound. Perhaps the valid keys should be placed pseudorandomly throughout the constant sized key table ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Encryption on Mailing lists sensless?
On Thursday 20 November 2014 14:36:35 Schlacta, Christ wrote: > On Nov 20, 2014 1:58 PM, "Ingo Klöcker" wrote: > > On Tuesday 18 November 2014 22:43:18 MFPA wrote: > > KMail encrypts an individual copy for each BCC recipient. I thought > > Thunderbird+Enigmail would also do this. > > > > Any mail client not doing this completely subverts BCC (unless > > --throw-keyids > > > or --hidden-recipient is used, but even throwing the key IDs still leaks > > the > > > number of hidden recipients). > > There's nothing preventing a list server or mail client from intentionally > adding a pseudo random quantity of invalid or junk keys to the recipient > list, thus obfuscating the number of additional recipients, only providing > an upper bound to the estimate. Adding additional junk keys doesn't help if the recipient (or the recipients) expect a certain number of recipients. If the message is encrypted to more than (expected number of recipients)+1 (for encrypt to sender) then the recipients most likely will wonder who the other recipients are. You'll have a hard time convincing them that the "other recipients" are just fakes to confuse a third party intercepting the messages. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Symmetrical encryption or ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/20/14 10:40 AM, Dave Pawson wrote: | Requirement. Two machines (one Linux, one Windows). | | I want a secure file 'shared' between them, as a pwd-safe. | | Only I use the two machines, but need the file encrypted. | | Any alternatives to symmetrical encryption of a file? Either symmetric or PK encryption would suit your needs, but as someone pointed out already, a better solution is to use a password safe. KeePass is an excellent solution, and I use the same password db between Windows, Linux, and OS X (not in that order). :) You want to use the lowest common denominator format between those systems, which at this point is the 1.28 version for Windows, and the keepassx version that comes with most Linux distributions (I use Ubuntu primarily). For OS X it gets a little trickier, since the version that includes auto-type is community sourced, but the person who produces it is well trusted, and a lot of people use it. Schneier had an interesting blog post recently about password safes, with a link to papers that did extensive research on them. KeePass came out looking pretty good, as one of the key problems with most password safes is that if the auto-type is truly automatic, it can be triggered by malicious software and grab your passwords off the clipboard in windows. While KeePass does have an auto-type feature, you have to trigger the key sequence to use it, and that sequence is user-configurable. And obviously you don't want to use solutions like LastPass, where your stuff is stored in their cloud. The question of "What if they get hacked?" is no longer academic, since it happened recently. For synchronization between systems I use SpiderOak, which also has clients for all 3 platforms. KeePass already encrypts the db file, and SpiderOak, unlike most "cloud storage" platforms, encrypts the files it backs up locally (on your system) with a special key that the company does not know. The upload channel is encrypted to their servers as well, so your data is never available in the clear. Because they don't know the encryption key your data is never de-duplicated with other people's stuff, although if you set up folder synchronization between systems the same files will be de-duplicated within your own account. ... and speaking of folder synchronization, one of the things I like about SpiderOak is that you can set up arbitrary folders to synchronize between systems, you don't have to put all of your stuff in one folder. You can also configure it to exclude certain files from syncing, which is handy to avoid synching the .lock file for KeePass. :) http://keepass.info/index.html https://www.schneier.com/blog/archives/2014/09/security_of_pas.html If you use this link to sign up for SpiderOak, I get free space. :) https://spideroak.com/signup/referral/25c4971714a13f13c24fa98a43317dc2/ Or, here is the regular link, if you prefer: https://spideroak.com/ hope this helps, Doug -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJUb/bPAAoJEFzGhvEaGryEq9EH/0pwRxi7PpJMlJs9yGOvdcBO +oqL6uJ99U72kdmUeznLzSewN5pHJoKB26gHAqs2WvNnoNGDOfRKz89ijKxCOWbE 8uJfz+AEqDJLe6CdLXSVTTa8SdLDydYUqrQZuV3aPxVPCCA91I4vi0HVB3MAlqLV ndOEaX6wP6/GCqVDkHUDQ9V37jmFHa7jl2RKFXj5BRL31ztQuqVQ4VlCiVbZFvje aipBL8p1l9EBdEUdQIM7tnykeP9EY+0F5zQmSqAuxxk+CFKQZBJ2FqZN1bnvi5OC QQFaUy4sGQKdI/uoOQOVM5YHXzQxJ6tZY1zFUudQwcs/Sdi2EQkRZQVOpMHeeqQ= =dI3t -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: correct usage of gpg param 'throw-keyid(s)' ?
Am Fr 21.11.2014, 13:58:19 schrieb grantksupp...@operamail.com: > The obvious difference in usage ... > > One says the usage is > > throw-keyids > > the other says usage is > > throw-keyid That's just a typo. The correct name for the option is "throw-keyids". You do not have to write the complete name. It is enough to have so many chars that the option or command is unambiguous. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: correct usage of gpg param 'throw-keyid(s)' ?
On Fri, Nov 21, 2014, at 02:33 PM, Daniel Kahn Gillmor wrote: > As long as the prefix substring is unique, gpg will accept a truncated > long-option. > > That is, the full option is --throw-keyids, but gpg will accept > --throw-keyid as an alias for it. > > It should also accept --throw-keyi and --throw-key and --throw-ke to > mean the same thing, but it doesn't due to a quirk of the source code > (i've just mailed a patch to gnupg-devel to fix that). > > Good documentation should always use the full option, to avoid ambiguity > with any potential future updates. I'd say the GNU privacy handbook > should be updated to use --throw-keyids instead of --throw-keyid. Thanks for the clarification, and the prompt fixes. Appreciated! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: correct usage of gpg param 'throw-keyid(s)' ?
On 11/21/2014 04:58 PM, grantksupp...@operamail.com wrote: > The obvious difference in usage ... > > One says the usage is > > throw-keyids > > the other says usage is > > throw-keyid > > neither one mentions the others' usage As long as the prefix substring is unique, gpg will accept a truncated long-option. That is, the full option is --throw-keyids, but gpg will accept --throw-keyid as an alias for it. It should also accept --throw-keyi and --throw-key and --throw-ke to mean the same thing, but it doesn't due to a quirk of the source code (i've just mailed a patch to gnupg-devel to fix that). Good documentation should always use the full option, to avoid ambiguity with any potential future updates. I'd say the GNU privacy handbook should be updated to use --throw-keyids instead of --throw-keyid. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: correct usage of gpg param 'throw-keyid(s)' ?
> And what do you consider the conflict? >> What is this param's correct usage: >> >> "throw-keyids" or "throw-keyid" >> >> ? The obvious difference in usage ... One says the usage is throw-keyids the other says usage is throw-keyid neither one mentions the others' usage ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: correct usage of gpg param 'throw-keyid(s)' ?
Am Fr 21.11.2014, 12:16:39 schrieb grantksupp...@operamail.com: > I see conflicting docs online: > Do not put the recipient key IDs into encrypted messages. This > helps to hide the receivers of the message and is a limited > countermeasure against traffic analysis.1 On the receiving side, it > may slow down the decryption process because all available secret > keys must be tried. --no-throw-keyids disables this option. This > option is essentially the same as using --hidden-recipient for all > recipients. > throw-keyid — do not put key IDs into encrypted packets And what do you consider the conflict? Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
correct usage of gpg param 'throw-keyid(s)' ?
What is this param's correct usage: "throw-keyids" or "throw-keyid" ? I see conflicting docs online: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html & --throw-keyids --no-throw-keyids Do not put the recipient key IDs into encrypted messages. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis.1 On the receiving side, it may slow down the decryption process because all available secret keys must be tried. --no-throw-keyids disables this option. This option is essentially the same as using --hidden-recipient for all recipients. & https://www.gnupg.org/gph/en/manual/r2110.html Name throw-keyid — do not put key IDs into encrypted packets Generally, which gpg docs are authoritative? https://www.gnupg.org/documentation/manuals, OR, https://www.gnupg.org/gph/en/manual ? I.e., if/when they conflict, which is considered correct? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Symmetrical encryption or ...
1. A matter of trust (low) 2. One mc is Linux, the other windows - they tend not to mix? Tks, Dave On 21 November 2014 18:36, Schlacta, Christ wrote: > For a password safe you might look into existing solutions, such as > keepass(x) or other similar password storage solutions > > On Nov 21, 2014 10:29 AM, "Dave Pawson" wrote: >> >> Thanks Robert. I'll give it a try. >> >> regards Dave P >> >> On 21 November 2014 18:24, Robert J. Hansen wrote: >> >> Only I use the two machines, but need the file encrypted. >> >> >> >> Any alternatives to symmetrical encryption of a file? >> > >> > >> > Not really. Sym would appear to be ideal for your use case. >> > >> > >> > ___ >> > Gnupg-users mailing list >> > Gnupg-users@gnupg.org >> > http://lists.gnupg.org/mailman/listinfo/gnupg-users >> >> >> >> -- >> Dave Pawson >> XSLT XSL-FO FAQ. >> Docbook FAQ. >> http://www.dpawson.co.uk >> >> ___ >> Gnupg-users mailing list >> Gnupg-users@gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Symmetrical encryption or ...
For a password safe you might look into existing solutions, such as keepass(x) or other similar password storage solutions On Nov 21, 2014 10:29 AM, "Dave Pawson" wrote: > Thanks Robert. I'll give it a try. > > regards Dave P > > On 21 November 2014 18:24, Robert J. Hansen wrote: > >> Only I use the two machines, but need the file encrypted. > >> > >> Any alternatives to symmetrical encryption of a file? > > > > > > Not really. Sym would appear to be ideal for your use case. > > > > > > ___ > > Gnupg-users mailing list > > Gnupg-users@gnupg.org > > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > > -- > Dave Pawson > XSLT XSL-FO FAQ. > Docbook FAQ. > http://www.dpawson.co.uk > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Symmetrical encryption or ...
Thanks Robert. I'll give it a try. regards Dave P On 21 November 2014 18:24, Robert J. Hansen wrote: >> Only I use the two machines, but need the file encrypted. >> >> Any alternatives to symmetrical encryption of a file? > > > Not really. Sym would appear to be ideal for your use case. > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Symmetrical encryption or ...
Only I use the two machines, but need the file encrypted. Any alternatives to symmetrical encryption of a file? Not really. Sym would appear to be ideal for your use case. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How much information can be gleaned about a gpg key by possessing both plaintext and ciphertext?
On 11/21/2014 at 1:01 PM, "Christ Schlacta" wrote: > >So to summarize, the best way to try this attack would be to >encrypt lots >of small messages to a dummy key and a target key because the only >knowable >plaintext is the session key. However, there's no known or >reasonably >suspected method of plaintext attack anyway, so all this data is >believed >to be a waste. = Correct. You could (more efficiently) isolate the Public GnuPG key as an RSA Public key, and use an implementation of RSA that does not use padding, and try all the plaintexts and known resulting ciphertexts, and still not construct the RSA Private key. vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How much information can be gleaned about a gpg key by possessing both plaintext and ciphertext?
So to summarize, the best way to try this attack would be to encrypt lots of small messages to a dummy key and a target key because the only knowable plaintext is the session key. However, there's no known or reasonably suspected method of plaintext attack anyway, so all this data is believed to be a waste. Correct me if I'm wrong, and thank you all for the prompt and consistent replies On Nov 21, 2014 7:59 AM, wrote: > On 11/21/2014 at 4:57 AM, "Christ Schlacta" wrote: > > >how much information does GPG reveal in such situations? > > = > > GnuPG works by using hybrid encryption: > > [1] The plaintext is converted to ciphertext using a block cipher, with > GnuPG generating a random session key for the encryption > > [2] The random session key is then encrypted to the recipient's public key. > > [3] The recipient uses the private key to recover the session key in [2], > which is then used to decrypt the plaintext in [1]. > > > No amount of plaintext and ciphertext reveal anything about the > recipient's *Private* key. > (The recipient's public key is usually *public* and known already). > > That said, > Any attacker can simultaneously encrypt to a 'Target' public key, and to > the Attacker's own public key. > > The Attacker can then recover the session key by decrypting with the > Attacker's private key. > This 'session key' is the only thing that can be used as the "plaintext" > that is encrypted to the Target's public key. > > > An attacker now knows: > > (a) The *ciphertext*, which is the session key encrypted to the Target's > public key. > > (b) *PART* of the *plaintext*, which is the session key, since it was > encrypted to the attacker's public key. > (It is only *part* because the session key is padded with a *different* > padding for each key to which it is encrypted, > even when the same session key is simultaneous encrypted to different > public keys.) > > (c) The Target's Public key. > > The Attacker can generate an unlimited amount of messages in this way. > > Using this information the attacker now wants to find/reconstruct the > Target's Private key. > > > I don't know that much about attacking RSA Key Pairs in trying to find > the Private Key, (other than factoring the modulus), > but suffice it to say, that in the over 20 years that RSA has been around > and many different attacks have been tried, > *this* type of attack has not seemed feasible enough for anyone to try. > > So, > Short summary, > > No useful information can be gleaned. > > > vedaal > > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Backup of encrypted private key on uncontrolled disks
It's really easy to point fingers at them and say, "man, what chumps." But the reality is none of us on this list are different than they are. We're human, with the same foibles and weaknesses, and I'm pretty sure Robin Sage would rip through this mailing list like a chainsaw. For that matter, Eliezer Yudkowski's "AI in a Box" experiment shows just how prone people are to being gamed. (And yes, I was reminded of Yudkowski's work by seeing today's XKCD.) http://yudkowsky.net/singularity/aibox ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How much information can be gleaned about a gpg key by possessing both plaintext and ciphertext?
On 11/21/2014 at 4:57 AM, "Christ Schlacta" wrote: >how much information does GPG reveal in such situations? = GnuPG works by using hybrid encryption: [1] The plaintext is converted to ciphertext using a block cipher, with GnuPG generating a random session key for the encryption [2] The random session key is then encrypted to the recipient's public key. [3] The recipient uses the private key to recover the session key in [2], which is then used to decrypt the plaintext in [1]. No amount of plaintext and ciphertext reveal anything about the recipient's *Private* key. (The recipient's public key is usually *public* and known already). That said, Any attacker can simultaneously encrypt to a 'Target' public key, and to the Attacker's own public key. The Attacker can then recover the session key by decrypting with the Attacker's private key. This 'session key' is the only thing that can be used as the "plaintext" that is encrypted to the Target's public key. An attacker now knows: (a) The *ciphertext*, which is the session key encrypted to the Target's public key. (b) *PART* of the *plaintext*, which is the session key, since it was encrypted to the attacker's public key. (It is only *part* because the session key is padded with a *different* padding for each key to which it is encrypted, even when the same session key is simultaneous encrypted to different public keys.) (c) The Target's Public key. The Attacker can generate an unlimited amount of messages in this way. Using this information the attacker now wants to find/reconstruct the Target's Private key. I don't know that much about attacking RSA Key Pairs in trying to find the Private Key, (other than factoring the modulus), but suffice it to say, that in the over 20 years that RSA has been around and many different attacks have been tried, *this* type of attack has not seemed feasible enough for anyone to try. So, Short summary, No useful information can be gleaned. vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
2 pka dns RRs - same email address
i know its not strictly for this list but does anybody have a suggestion for the zone file ? i have 2 TLSA RRs in my zone file, 2 certs, and postfix automatically selects the correct cert based on the RR what would gnupg do if it encountered 2 pka RRs ? would it select the correct finger print automatically ? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How much information can be gleaned about a gpg key by possessing both plaintext and ciphertext?
I know some encryption schemes reveal more information about the keys used when an attacker has both the plaintext and the ciphertext. In general, how much information does GPG reveal in such situations? Virtually none. How much plaintext/ciphertext matched data would an attacker need (An order of magnitude is fine) before being able to reverse enough of the key to be meaningful on fairly modern computers? Enough to make it far, *far* more cost-effective to resort to other methods to recover your key. Just buying the hard drives alone would exhaust the budgets of large corporations. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How much information can be gleaned about a gpg key by possessing both plaintext and ciphertext?
Am 21.11.2014 um 10:57 schrieb Schlacta, Christ: > I know some encryption schemes reveal more information about the keys used > when an attacker has both the plaintext and the ciphertext. In general, > how much information does GPG reveal in such situations? Short answer: Thats no problem. google e.g.: "plain text attacks on gnupg site:gnupg.org" Greetings Martin ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
How much information can be gleaned about a gpg key by possessing both plaintext and ciphertext?
I know some encryption schemes reveal more information about the keys used when an attacker has both the plaintext and the ciphertext. In general, how much information does GPG reveal in such situations? How much plaintext/ciphertext matched data would an attacker need (An order of magnitude is fine) before being able to reverse enough of the key to be meaningful on fairly modern computers? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Re: problems with pinentry-0.9.0 (Werner Koch)
On Thu, Nov 20, 2014 at 12:31:53PM -0800, Rex Kneisley wrote: > Gracious reply: > >Install the pkg-config package: > >apt-get install pkg-config > >Shalom-Salam, > >Werner > > Thank you! > After installing pkg-config as suggested, > Looks like I'm down to the wire: > > checking whether mlock is broken... no > checking for byte typedef... no > checking for ulong typedef... yes > checking for setcap... /sbin/setcap > checking for cap_set_proc in -lcap... no > checking for initscr in -lncursesw... no > checking for initscr in -lncurses... no > checking for tgetent in -lcurses... no > checking for tgetent in -ltermcap... no > checking for tgetent in -ltermlib... no > checking for initscr in -lcurses... no > checking for pkg-config... /usr/bin/pkg-config > checking for gtk+-2... no > configure: WARNING: pkg-config could not find the module gtk+-2.0 > checking pkg-config is at least version 0.9.0... yes > checking for QT4_CORE... no > configure: error: No pinentry enabled. > > I have tried: > > sudo apt-get install gtk+-2 If you need to build programs with GTK+ 2.0 support, the package that you need to install is usually named something like libgtk2.0-dev on Debian-like systems. This information is actually available if you have "deb-src" lines in your /etc/apt/sources.list, so that Apt can download information about source packages; then you can try the following: apt-cache search -n pinentry (see that it shows a pinentry-gtk2 binary package) apt-cache show pinentry-gtk2 | less (it will tell you "Source: pinentry") apt-cache showsrc pinentry It will give you a list of packages in the Build-Depends field; those are packages that the Debian package of pinentry needs so that it can build properly with full support for all the backends. You might consider installing at least some of them. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
