scripting gpg
I need to do the following: - when a new machine is created, automatically import a public key and give it full trust - be able to encrypt files with that public key without any interactive prompting (from a shell script/cron job) in other words, a machine has to go from virgin state (OS + software only) to being able to encrypt and transmit encrypted files without any prompting or other user interaction. I know about the 'trust' command but I don't see any non-interactive way to achieve that. Alternatively, if the gpg binary would stop giving me the "It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes." prompt that would be fine too. Are there some hidden command line options/environment variables I am missing? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: scripting gpg
On May 4, 2011, at 7:01 PM, Jon Drukman wrote: > I need to do the following: > > - when a new machine is created, automatically import a public key and give it > full trust > > - be able to encrypt files with that public key without any interactive > prompting (from a shell script/cron job) > > in other words, a machine has to go from virgin state (OS + software only) to > being able to encrypt and transmit encrypted files without any prompting or > other user interaction. > > I know about the 'trust' command but I don't see any non-interactive way to > achieve that. Alternatively, if the gpg binary would stop giving me the "It > is > NOT certain that the key belongs to the person named > in the user ID. If you *really* know what you are doing, > you may answer the next question with yes." prompt that would be fine too. You're looking for the "--trust-model always" option. Add that to your options, and the trust model becomes "if it's on my keyring, it's fully trusted". It's up to you to make sure that only keys that are fully trusted are on your keyring, of course. :) David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: scripting gpg
David Shaw jabberwocky.com> writes:
> You're looking for the "--trust-model always" option. Add that to your
options, and the trust model
> becomes "if it's on my keyring, it's fully trusted". It's up to you to make
sure that only keys that are fully
> trusted are on your keyring, of course. :)
Awesome, thanks. This works (php):
putenv('HOME=/tmp/gpg');
@mkdir('/tmp/gpg');
system("/usr/bin/gpg --batch --yes --import /sites/config/public_key.asc");
system("/usr/bin/gpg --batch --yes --no-ask-cert-level --trust-model always
--output $filename.gpg --encrypt --recipient $recipient $filename > /tmp/gpg.log
2>&1");
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: scripting gpg
On Thu, May 5, 2011 at 02:19, Jon Drukman wrote:
> putenv('HOME=/tmp/gpg');
> @mkdir('/tmp/gpg');
>
At this point, you should be watching carefully. What if another user has
created this directory to spoof the key?
Use the appropriate command for creating a unique temporary directory.
Should be mktemp or similar.
> system("/usr/bin/gpg --batch --yes --import /sites/config/public_key.asc");
> system("/usr/bin/gpg --batch --yes --no-ask-cert-level --trust-model always
> --output $filename.gpg --encrypt --recipient $recipient $filename >
> /tmp/gpg.log
> 2>&1");
Again, what if the keyring is already in place? Could even be yourself --
you create the keyring once, import the public key at the time, then later
update the public key and import again -- now, which key to use?
--
Jerome Baum
tel +49-1578-8434336
email jer...@jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Storing secrets on other people's computers
On 03/05/11 15:50, Daniel Kahn Gillmor wrote: Dropbox exposes your secret keys to dropbox employees (and anyone who can convince them to snoop): http://paranoia.dubfire.net/2011/04/how-dropbox-sacrifices-user-privacy-for.html That article makes no sense at all. a) Storing files containing your secret data on somebody else's computer makes sense only if *you* encrypt the data beforehand, completely independently from the person or organization that you will give the files to store. b) Your data can not be considered safely encrypted, unless encrypted with a competently written program that had its source inspected by you or someone you trust, on the computer that you control at the time of encryption. Once these two extremely straightforward principles are observed, it is perfectly OK to give the files containing your secrets to someone/anyone else for safekeeping, provided you have no problem that it will be known to him, to all those that he cooperates with and to all those that monitor the traffic between the two of you that you have given *some* secrets away for safekeeping. To imply that one such service is better or worse than another based on what *they* do (or they say they do) in order to protect your secrets is utter nonsense. Marko R. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Storing secrets on other people's computers
> Once these two extremely straightforward principles are observed... For the better part of a decade now I've volunteered to publish my private certificate in the _New York Times_ if someone will pay for the advertising space. With a strong passphrase that's not known to anyone else, the private certificate is about as safe as can be. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Storing secrets on other people's computers
On Thu, May 5, 2011 at 04:24, M.R. wrote: > On 03/05/11 15:50, Daniel Kahn Gillmor wrote: > Once these two extremely straightforward principles are observed, > it is perfectly OK to give the files containing your secrets to > someone/anyone else for safekeeping, "perfectly OK" is quite an extreme thing to say, isn't it? Say you encrypted the file with a cipher that is broken tomorrow (i.e. it becomes computationally feasible to determine the plain-text given only the cipher-text), then would you rather have someone else in possession of the cipher-text, when you could opt not to? Of course, that would prevent you from using any SaaS provider. There are always trade-offs, and that's all I'm saying. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Storing secrets on other people's computers
On Thu, May 5, 2011 at 05:34, Robert J. Hansen wrote: > > Once these two extremely straightforward principles are observed... > > For the better part of a decade now I've volunteered to publish my private > certificate in the _New York Times_ if someone will pay for the advertising > space. With a strong passphrase that's not known to anyone else, the > private certificate is about as safe as can be. > Go ahead. Send it to the list. Then offer a bounty for the guy who hands you your secret key. That'll be worth so much more. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Storing secrets on other people's computers
On Wed, May 4, 2011 at 10:24 PM, M.R. wrote: > On 03/05/11 15:50, Daniel Kahn Gillmor wrote: > >> Dropbox exposes your secret >> keys to dropbox employees (and anyone who can convince them to snoop): >> >> >> http://paranoia.dubfire.net/2011/04/how-dropbox-sacrifices-user-privacy-for.html > > That article makes no sense at all. > I was somewhat surprised at the article. I think a typical user expects that a file is encrypted locally and then securely transmitted to DropBox for storage. (I don't use DropBox, but its what I expected). I don't believe anyone would expect that DropBox transmits a plain text file and then encrypts the file at its leisure and pleasure. OT: I was just getting ready to audit DropBox via their public API for another project. The article saved me a lot of time. Jeff ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: nothing so dramatic
On Thu, Apr 28, 2011 at 12:03 PM, M.R. wrote:
> On 28/04/11 13:40, Johan Wevers wrote:
>>
>> I'm not so sure. Especially for human rights activists in, say, Syrie or
>> Tibet, might not want the government to know when they are mailing with
>> foreign journalists.
>
> Quite probably, but I do not consider myself qualified to comment
> on trials and tribulations of human rights activists in faraway lands,
> or, for that matter, on this continent. My concern is the result of
> a much more mundane set of circumstances.
>
> When legal "pressure to decrypt" is discussed, almost universally
> the issue becomes that of the right not to self-incriminate.
> Implicitly, it is assumed that the proceedings are part of some
> segment of the criminal law. However, it is not in the criminal
> but in the civil litigation that the courts can (and nowadays
> increasingly do) issue Subpoena Duces Tecum ("production of evidence")
> for plain-text of one of the litigant's communications. No right not
> to self-incriminate applies in such case. Where the record exists
> (just for an-instance) in a monetary hefty divorce litigation that
> there was encrypted communication with a third party, reasonably
> suspected of interfering in the marriage, the request from the
> opposing side for such duces tecum would not be hard to obtain.
> But there has to be a "reasonable expectation of relevance"; i.e., encrypted
> communication with a specific and relevant individual.
> Without it, request would likely be treated as nothing but a fishing
> expedition and rejected. I can easily imagine similar cases where
> the other communicating party is not Alice (36-29-38) but Bob, your
> accountant or stockbroker.
>
"A federal judge has ordered a criminal defendant to decrypt his hard
drive by typing in his PGP passphrase so prosecutors can view the
unencrypted files, a ruling that raises serious concerns about
self-incrimination in an electronic age."
'Judge orders defendant to decrypt PGP-protected laptop',
http://news.cnet.com/8301-13578_3-10172866-38.html.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Storing secrets on other people's computers
The typical user most likely *does* believe files are locally encrypted then sent to Dropbox. But isn't that still pretty meaningless? If Dropbox is encrypting your file then you have to trust that Dropbox either can't decrypt the file or that, if they can, they would never under any circumstance compromise your security. One name: HushMail. If you don't encrypt it yourself using a tool that is *known* to be secure then it really can't be trusted. Someone hacking a server is really the least of your security worries. Anthony On 5/4/11, Jeffrey Walton wrote: > On Wed, May 4, 2011 at 10:24 PM, M.R. wrote: >> On 03/05/11 15:50, Daniel Kahn Gillmor wrote: >> >>> Dropbox exposes your secret >>> keys to dropbox employees (and anyone who can convince them to snoop): >>> >>> >>> http://paranoia.dubfire.net/2011/04/how-dropbox-sacrifices-user-privacy-for.html >> >> That article makes no sense at all. >> > I was somewhat surprised at the article. > > I think a typical user expects that a file is encrypted locally and > then securely transmitted to DropBox for storage. (I don't use > DropBox, but its what I expected). I don't believe anyone would expect > that DropBox transmits a plain text file and then encrypts the file at > its leisure and pleasure. > > OT: I was just getting ready to audit DropBox via their public API for > another project. The article saved me a lot of time. > > Jeff > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Anthony Papillion Lead Developer / Owner Get real about your software/web development and IT Services (918) 919-4624 Facebook: http://www.facebook.com/cajuntechie My Blog: http://www.cajuntechie.com ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: nothing so dramatic
> "A federal judge has ordered a criminal defendant to decrypt his hard > drive by typing in his PGP passphrase so prosecutors can view the > unencrypted files, a ruling that raises serious concerns about > self-incrimination in an electronic age." That court's opinion was predicated on the fact Boucher had already waived his right against self-incrimination, and for that reason there was no constitutional violation. It's sort of like testifying in court: the government can't force you to testify in your own criminal proceeding, but if you waive that right the government can cross-examine you. Likewise, if you *voluntarily give the government your child porn*, you can't really claim that "I'm not going to provide the government with copies of that child porn, because that would incriminate me." _Boucher_ is nowhere near the death knell for privacy that some people seem to think it is. (ObDisclosure: a couple of years ago I helped prepare a law review article on _Boucher_.) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
