Re: gpg-preset-passphrase
I have a patch for fixing the 'forget' option. I hope this is of some help. http://old.nabble.com/file/p27817136/clear_passphrase.patch clear_passphrase.patch It would be nice to have a more complete tool for administering passphrases, or a simpler interface to pinentry :) /K Daniel Eggleston-2 wrote: I'm looking for some help explaining the behavior of gpg-preset-passphrase. First, the manpage states: Passphrases set with this utility don't expire unless the --forget option is used to explicitly clear them from the cache --- or gpg-agent is either restarted or reloaded (by sending a SIGHUP to it). It is But it looks like gpg-preset-passphrase cached passphrases are still subject to the --max-cache-ttl option in gpg-agent ... this behavior is hardly Don't expire. Is there a way to change this behavior? Second, the manpage also states: --forget Flush the passphrase for the given cache ID from the cache. The implication (to me) is that if I cache a passphrase with gpg-preset-passphrase, then run gpg-preset-passphrase with the same key fingerprint and the --forget option, that gpg-agent will no longer cache that entry. When this didn't pan out, I thought maybe the forget command simply makes the cached passphrase obey the --default-cache-ttl option, but no dice. So, basically the --preset command is subject to --max-cache-ttl (although the documentation implies otherwise), and the --forget command doesn't appear to change anything at all. Am I doing it wrong? Any help is appreciated, -- Daniel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -- View this message in context: http://old.nabble.com/gpg-preset-passphrase-tp27812444p27817136.html Sent from the GnuPG - User mailing list archive at Nabble.com. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how to suppress warning about gpg-agent?
Hi! On Mon, Mar 08, 2010 at 01:06:06PM +0100, Werner Koch wrote: FWIW, You should use public key encryption instead of symmetric only encryption. This makes everything much easier. I don't think so. Every project encrypt it backups with different passwords (needed for security), and right now I can keep just several dozens of passwords, but with public keys I'll need to keep several dozens of .gnupg directories instead, which is harder to manage. A littel warning: gpg-agent is is a cornerstone of GnuPG-2. You can't do much without it. Today gpg2 might be usable without a running gpg-agent but with the current branch this will change: All secret key operations are then diverted to the agent. I know. Right now it run gpg-agent in server mode and talk to it STDIN - that's ok for my needs. I don't try to avoid running gpg-agent, I just wanna suppress warning. In your case the agent is required to return the S2K count. This values is computed only once because it takes some time can can't be done for each invcation. To avoid this you may try option --s2k-count N. You can get a suitable value for N on your machine by running the command gpg-connect-agent 'getinfo s2k_count' /bye Wow, it works! With this parameter gpg doesn't output that warning anymore (and doesn't try to start gpg-agent). I wonder what is physical sense of this number? Is it safe to hardcode one number for all user accounts on same server (many servers)? P.S. But I still think much more clear solution is just add option to suppress warning message and let gpg start own copy of gpg-agent when it need it. -- WBR, Alex. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how to suppress warning about gpg-agent?
On Mon, 8 Mar 2010 01:43, power...@powerman.name said: I've a lot of projects (each has separate user account) which use gpg for encrypting daily backups (from cron) in this way: gpg --batch --cipher-algo AES256 -c --passphrase-file PASSFILE BACKUP.tar FWIW, You should use public key encryption instead of symmetric only encryption. This makes everything much easier. I don't like to run gpg-agent as a daemon on all these user accounts just to suppress this warning message (and there may be additional issues to make it accessible from cron scripts, too). A littel warning: gpg-agent is is a cornerstone of GnuPG-2. You can't do much without it. Today gpg2 might be usable without a running gpg-agent but with the current branch this will change: All secret key operations are then diverted to the agent. In your case the agent is required to return the S2K count. This values is computed only once because it takes some time can can't be done for each invcation. To avoid this you may try option --s2k-count N. You can get a suitable value for N on your machine by running the command gpg-connect-agent 'getinfo s2k_count' /bye Shalom-Salam, 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[2]: key question
Hi Paul On Monday 8 March 2010 at 7:44:42 AM, you wrote: I am assuming that a person inhabited with the desire to protect his personal information would analyze the safety of using a UID with the information that he wants to protect. I think you may be assuming an awful lot, especially in the case where the person has a desire for privacy rather than a life-or-death *need* for privacy. Such a person may well be less rigorous than yourself in their analysis and investigations. We *are* talking about a technology created for privacy (http://www.philzimmermann.com/EN/essays/WhyIWrotePGP.html ). A person worried about the disclosure of his personal information is unlikely to say, Huh. I guess I don't have an option concerning my privacy. Unless their research reveals they *can* usefully create and circulate a key that omits their name/email address, they are weighing the privacy benefit of encrypting their mail against the privacy danger of using a key that contains those details. That isn't quite the same as I don't have an option. I am also assuming that the user has intelligence and judgment. A useful combination, sadly not common enough (-; I mean that he must be able to realize that he needs to be competent in the tool that he is using. How could a person of judgment believe that he could have the minimum knowledge of how to use cryptography and his OpenPGP tool, and believe that he will successfully protect his privacy? Even intelligence and judgment together do not necessarily lead to perfect decisions. The point when the user *thinks* he has sufficient knowledge or competence does not automatically coincide with the point at which this is true. The person concerned with the releasing of his personal information might make the mistakes that you have said. But the kind of person that you are talking about has minimal knowledge in OpenPGP and the tools to implement it and has less than adequate reasoning. I would expect an inexperienced user of *anything* to have limited knowledge compared to an expert, or at least to have not yet fully reflected on and internalised the information he has acquired. The kind of person I have described would clearly have made a poor call in deciding they had done sufficient reading around the subject, but I'm not convinced I have outlined a person of less than adequate reasoning ability. I have been naive before. But I didn't begin using GnuPGP while I was still naive about it. I studied how cryptography and OpenPGP worked, how to use gpg, and how to use it with e-mail and files. Many people are less patient than you must be; I have heard numerous people advocate the ready, fire,aim approach to life. I won't claim that I am better or more knowledgeable than some of the other smart people on this mailing list, but I will say that I am smart enough to teach others how it works. Actually, it was my goal to understand the concepts and the tools well enough to teach others. You don't have to have the most understanding in order to teach others, but you do have to have /enough/ understanding in what you want to teach in order to teach others. Yes, in my first two years at university most staff were assigned to teach topics outside their primary field of expertise, and switched around every year. The stated idea was to enable undergraduates to be taught by people who had recently learnt (or re-learnt) the same material, who would be more in tune with what a new learner would find difficult than the expert who, having been fully conversant with the material for several decades, would see it all as trivial. That is what I was saying in the previous posting. Someone who desires privacy will do what it takes to get it. That includes dispelling his naivety with knowledge. Which is an ongoing process. An individual desirous of privacy is likely to continue finding new threats and/or new protections for as long as they care to keep looking. As for the person not realizing how easy it would be to accidentally upload a public key to a keyserver, I was never that naive. I was aware of it from the beginning. My key wasn't on the keyservers, initially (I chose to upload it later). But I knew that if I was careless it could wind up there. Were you aware because of something you read, or because of experimentation? When first trying PGP in 2003, I read that uploading your key to a server was a Good Thing but found no evidence to support that assertion. I had no desire to publish my key to a server so I had no reason to experiment with how to do it. I was genuinely shocked when, much later, I found out how easy it was to upload keys and considered the likelihood of mistakes. Fortunately, I had created my key without including my name or email address (because I could not see how including them could aid privacy). Maybe it is that I am an above average user. Maybe. Maybe it is just that I
Re: Re[2]: Memory forensics
On Monday 08 March 2010, MFPA wrote: Hi John On Friday 5 March 2010 at 9:42:53 PM, you wrote: Most 'Hibernators' I know are laptop/notebook/netbook Users who are too important to wait for boot-up when the unit is Opened. :-D Did you mean important rather than impatient? I guess John was referring to those important manager-type laptop/notebook/netbook users. ;-) 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[2]: key question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Paul On Monday 8 March 2010 at 5:35:08 AM, you wrote: MFPA wrote: On Saturday 6 March 2010 at 8:55:48 AM, you wrote: On Sat, 27 Feb 2010 03:52:02 + MFPA wrote: (b) the person owns the information has the right to control how it is disseminated, and This was someone's re-interpretation of my point. Spot the extra ? Hello MFPA, I never asserted that you said the key's originator owned the information stored in the key. I was quoting the context of what your reply about the originator having some rights was about. I would never try to insert words into your mouth. I just wanted anybody reading this after the event to be clear the quoted line about owning was not anything *I* have said. The data subject does have various rights concerning the personal information that is about him. I used this quote, because I believe that it states, in your own words, what you have been saying, either directly or by implication, during this whole discussion thread. Yes, it is the main thing I have ended up discussing. The concept of *owning* your personal information makes little sense. [snipped the rest of the paragraph] You have began by answering a question that I never asked. I have only asserted that you believe that the originator has some rights. I never used the word own. I used the word rights. Since you quoted Robert J. Hansen's line beginning the person owns the information, I felt I could not reasonably address the question you went on to ask without first putting that point to bed. Really, I am not interested in talking about what the law says. The law may be right, or the law may be wrong. I don't want to know what the law thinks, I want to know what you think. The legal aspect is an integral part of the answer to your question; it demonstrates that rights to privacy and to an element of control over one's personal information are not something I dreamt out of thin air. Whatever different views people may have on moral or ethical rights, there are situations where processing/storage/dissemination of personal information is the subject of an established body of legislation and legal precedent. All that is open to question is the extent and nature of privacy rights that may exist beyond the narrow set enshrined in law and the slightly wider set in documents such as ECHR. For the record, I don't believe that the key holder should upload the key if the key's originator doesn't want Seeing as we are framing this in terms of rights, do you believe the holder has a right to upload in these circumstances but should not exercise that right? the key in some public venue (forget the keyservers, it's about public availability). It's not entirely about public availability. There is also the inability to remove a key from most servers. An individual may be perfectly happy to post the key on their website, or biglumber, or the PGP directory, but not want it on the main server networks. It's about the individual's right to choose what happens to their personal information. But I don't believe the originator has a /right/ to prevent the key holder from sharing it. Morally and ethically, I disagree. To use an example with phone numbers: say I had a personal friend who was an insurance broker with a teenaged daughter and elderly parents. I would suggest it's perfectly in order for me to pass to a third party my mate's business number. I definitely have no moral or ethical right to pass on his daughter's or parent's numbers or his personal number. Some would argue he has a right to give me a good beating if I did. In practical terms, the originator currently has no means to prevent this sharing, whether or not he has a right. In a certain narrow set of circumstances, there could be an argument for legal redress if the originator's personal information was shared. I don't believe the keyserver (or the church) is responsible for another's actions. But I wanted to see whether you thought the keyserver should be responsible. I also don't think a webhost should be deemed responsible if somebody posts unlawful material on a site or forum that happens to be hosted on their servers. The only problem that I can see with the keyserver preventing any modification of the originator's key, is that it could prevent someone else from ever revoking their signature on the originator's key. That would be, of course, if absolutely no modification is allowed. Unless I have missed something, the RFCs have not addressed that point. If the originator does have rights to control copying and sharing, are there any fair use rights for the person who has a copy of the public key? Should these rights of the originator be enforced by some governing body, or should they be merely courtesy or suggestion? I am not advocating anything remotely equivalent to copyright provisions, just protection of personal
