Long Term Content Protection
There is, perhaps, a wider perspective on the problem discussed in this thread. GPG is a reasonable tool for the protection and verification of content exchanged between two parties. Once a message reaches the recipient's operational environment, it should be decrypted, and its further protection is best addressed as part and parcel of the protection of that complete environment. After all, a message of any consequence will likely result on secondary content generated by and on the recipient's computer, that needs as much (or more) protection as the message content in transit. There are many tools and techniques for achieving that, but their use and best practices are beyond the scope of this list. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgAnon, draft 20150
On 5/29/20 4:51 PM, Stefan Claas - s...@300baud.de wrote: how does Alice protects her Live-CD and USB stick, when she leaves home and Mallory gains access to them, so that for example the Live-CD can be exchanged? Live-CD is a "public resource", available from multiple locations on the 'net and off, simply discarded when not practical to protect. Anybody can download, burn and give her a copy. On first use, checked with: sudo cat /dev/cdrom | shasum - While noting on the CD is a secret, it is quite unlikely an adversary can modify it without being detected. Does Alice use the USB-stick also with other mediums and if so how does she detect bad USB? USB hygiene is always a problem. Small devices and frequent hardware cycling on the trusted device with two USB ports is helpful: dd if=/dev/sdb of=/dev/sdc bs=10M (with subsequent cat ... | shasum - thrown in for good measure) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
gpgAnon, draft 20150
The setup described in this "how-to" was originally put together and used (and possibly still is) quite a while ago, using Disastry's PGP 2.6.3ia-multi06 as the crypto back end. This guide has been composed from bits and pieces of the original user documentation, scissoring out the content that it refers to vaguely as "group policies". Other than that, the only substantial change is the replacement of pgp 2.6.3ia-multi06 with gpg 1.4.10 (or later). Technical testing of the described setup with the new crypto back end is underway. Any comments and criticism, of whatever kind, is welcome, if it implies the permission to incorporate it into the final version of the document. Available to first one hundred downloads at: https://send.firefox.com/download/d49d3f511202f943/#ITQHMkZexDePZ1JMwziuqg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: "just invent something..."
On 5/23/20 4:30 PM, Robert J. Hansen wrote: I mean, this seems like 95% of what you want. You just want the reference to an email address in step 4 removed? If you can get the community to agree, I'm all in favor. - All gpg operations (key generation, encryption, decryption) are carried out on a device not connected to the Internet. The FAQ covers both online and offline use. I maintain two short internal documents on "WOT-less" and "e-mail-less" off-line gpg use: one can be thought as "tutorial" the other as "reference". When I get some free time I'll merge them, remove group-specific stuff and post in a new thread. Would that be okay? Would that be worthwhile? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: "just invent something..."
Robert, Hi and thanks for the reply. Salsa is cooking. And since you are so kind: It would help a whole lot if GPG included some authoritative documentation on how to use the program in the following scenario: - The trust in the correspondent's public key is established only by comparing the key fingerprint derived programmatically from the locally stored key-file and a copy independently obtained from the owner. The only identification of a public key is its fingerprint. Since the public key is either known to an adversary, or it is very hard to guard against such eventuality, the public key itself should not provide the adversary with any useful information. - All gpg operations (key generation, encryption, decryption) are carried out on a device not connected to the Internet. - There is no e-mail. (It's not just "resting", it is DEAD). It would really, really help. p.s. Out-of-channel fingerprint dissemination and exchange of ciphertext without the benefit of the e-mail system has been dealt with, so there is no need at all to address that. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: "just invent something..."
On 5/21/20 10:52 AM, Ingo Klöcker - kloec...@kde.org wrote: On Donnerstag, 21. Mai 2020 00:14:40 CEST LisToFacTor via Gnupg-users wrote: I suppose you also entered an empty string for "Email address": `` > Real name: Email address: f...@example.com You selected this USER-ID: "f...@example.com" Change (N)ame, (E)mail, or (O)kay/(Q)uit? o [...] ``` A key with above User-ID is generated. You are correct, the e-mail address was likewise an empty string. First, let me mention that Web of Trust is to me not a useful public key verification mechanism, as it is compromises my privacy. I use other methods to make it possible for my correspondents to verify the key. I do not have a/one e-mail address either. At any point in time, I might be using any number of addresses, depending on who I'm communicating with, and none of those addresses is likely to remain in use as long as the key I am generating. None of such e-mail correspondents would have any idea whatsoever what to do with a gpg-encrypted message received from me anyways. On the other hand, for the exchange of personal and confidential messages, I do not use the "conventional" e-mail at all - the encrypted text is exchanged by other means, of which there are myriad. I do know I could have given my name as "Peter P. Pumpkineater" and the e-mail address as "peter.p.pumpkinea...@example.com" and the program would generate the key-pair for me. But the question begs: is inventing false information the proper way of preventing the leakage of personally identifiable information, completely unnecessarily, via programs constructed by system architects whose thinking about the privacy is stuck in the time long behind us? The proper thing for gpg program to do would be to allow the personally identifiable information in the key to be optional, and to warn the user generating such key that he will not be able to participate in the Web of Trust. Wouldn't that be a better system design than demanding the user to provide the false information and treating such information as valid? Especially as one would not be able to participate in the Web of Trust as "Peter P. Pumpkineater", but there is no way for a program to issue any warning for that? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: "just invent something..."
On 5/20/20 6:52 PM, Andrew Gallagher wrote: On 20 May 2020, at 18:51, LisToFacTor via Gnupg-users wrote: Demanding a piece of information from someone who would prefer not to give it is equally user-hostile, especially so if he who demands it does so only because it is required by some internal mechanics of the system he constructed “Demand” is a strong word that I don’t believe is justified here, and only serves to inflame the debate. Most implementations of email require that you enter a “real name” of some kind. OpenPGP/GPG strongly encourage you to use the same real name on your key as you use on your email profile - this is for the benefit of your correspondents, since using different IDs will likely cause confusion. You are free to ignore this recommendation but I don’t think the documentation should encourage novices to do so. English is not my native tongue, and the word I've chosen is based on my interpretation of the dialog presented by the program when generating the key: GnuPG needs to construct a user ID to identify your key. that the Old Guard (somebody used the term in one of the previous posts) just can't even Real name: upon entering an empty string, the response is: ... gpg: [internal]: no User-ID specified (and the program quits with no further explanation) To me, this appears to qualify as a demand for user's "Real name". It is not up to a program designer to decide that it is mandatory for a user to provide a piece of personally identifiable information because "this is for the benefit of your correspondents, since using different IDs will likely cause confusion." User is the one to decide what personally identifiable information to provide, when and to whom. And if the is demand for such information is refused, and the service is summarily denied, (as outlined above) then it is not okay for the program designer to wash his hands with "...so why didn't you just invent something...". Of course, it would be a one-minute job to change the prompt to "enter a “real name” of some kind..." (or something to that effect, better formulated). But with that, the whole "Web of Trust" structure would collapse, and that is something to horrible to even contemplate. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
"just invent something..."
On 5/20/20 7:27 AM, Andrew Gallagher wrote: Such a limitation would be user-hostile, as there are people in some cultures who have only one name, the Indonesian dictator Suharto being one famous example. Demanding a piece of information from someone who would prefer not to give it is equally user-hostile, especially so if he who demands it does so only because it is required by some internal mechanics of the system he constructed. Answering user's objection to such request by telling him: "well, if you don't want to give me this information, just invent something..." is wrong on so many levels that I feel no need to get into. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fwd: The GnuPR FAQ
On 5/11/20 10:11 PM, Robert J. Hansen - r...@sixdemonbag.org wrote: This arrived in my inbox: I'm presenting it here without comment. You've advised people to use a HORRIBLE practice of using dictionary words solely for their password. I tested this theory myself back in the day, so I can 100% guaranty you of this fact: A brute force dictionary based attack can crack a password like that in LESS THAN 5 minutes!! I once stretched that out to 20 minutes by cleverly picking words that I already knew were at the opposite ends of the dictionary. In order to discuss the feasibility of brute forcing a set of a few random dictionary words, we would have to agree on a few numbers: 1) how many words in the passphrase 2) how many words in a dictionary 3) how many dictionaries 4) how many slightly different forms can average word of the dictionary take due to the declension, conjugation and noun/adjective gender matching. This happens to be an English-only language mailing list, but very few users of this program speak (only) English. It always surprises me how contributors native-language-centric some Internet discussions on a technical subject that transgresses language borders are. Overall, the original suggestion in the FAQ is perfectly valid, and all I would add is point out the benefit of (3) and (4) above. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Maximum keypair length...
If everyone involved will have both the public and secret daily keys, I don't see the need for using public cryptography. Just generate all those daily keys¹ as a random 128 bit passphrase each and use a symmetric cipher such as AES.² It is actually an interesting contemporary phenomenon: there are quite a few instances I've encountered, where the threat model is never properly defined, and therefore the cryptography system architecture is not what fits any particular threat model, and where public key crypto is used where the "common", symmetrical crypto would do the trick quite nicely. It is my theory that this is happening with such surprising regularity because too many system architects view GPG as a "magic box", without even understanding that in reality it is only a public key crypto "wrapper" around the conventional, symmetric crypto hiding inside. In other words, symmetric crypto is *always used* by their system, if the wrapper around it is used in addition, there better be a justifiable reason for it. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
