On Sat, Mar 3, 2012 at 4:14 PM, Werner Koch wrote:
> My usually advise is to put an URL to the public key into the URL field
> and then use the fetch sub command of the --card-edit menu to retrieve
> the key.
>
Should it be necessary to use the card-edit menu? I tried something
similar, realized
On Sat, Mar 3, 2012 at 4:23 PM, Hauke Laging
wrote:
> But it the public key technically necessary to decrypt data? I checked what
>
I *think* this is either because the key lookup is happening on the public
key first, before checking for the matching secret key, or because the
stubs aren't being
On Sun, Feb 26, 2012 at 11:50 AM, Todd A. Jacobs wrote:
>
> # Prompts twice for password to clearsign.
> echo foo | gpg --clearsign; echo foo | gpg --clearsign
>
> So, the keychain problem seems to be resolved, in that gpg-agent is now
> reading the SSH authentication key off t
On Sat, Feb 25, 2012 at 8:43 AM, Todd A. Jacobs wrote:
> eval `keychain --eval --agents gpg,ssh id_rsa BCB6C8D4`
>
With keychain 2.6.8 (and possibly others) the agents won't start properly
if actually specified, so taking out the agents option actually allows
gpg-agent to start,
On Sat, Feb 25, 2012 at 3:06 AM, Astrid Staufer wrote:
>
> I encrypt with the folowing command on a server a backup and send it on an
> other server over FTP:
>
I'd suggest re-writing your script so that you can validate that the
archive is valid and decryptable *locally* before doing anything ov
I'm using GnuPG 1.4.11 on Ubuntu 11.10, and have a Crypto-Stick v1.2 with
an authentication key. My desktop is LXDE, but I'm starting gpg-agent using
keychain from my ~/.bashrc. My configuration files look like this:
# ~/.bashrc
eval `keychain --eval --agents gpg,ssh id_rsa BCB6C8D4`
# ~/.gnupg/g
On Mon, Apr 18, 2011 at 3:56 PM, Robert J. Hansen wrote:
> To give you an example, RC5-64 was a giant distributed network of computers
> run by hobbyists using spare CPU cycles, trying to brute-force a 64-bit key.
There's still a big difference between trying to brute-force a
cryptographically-s
On Sat, Apr 16, 2011 at 8:02 PM, Robert J. Hansen wrote:
> The best numbers I've seen regarding passphrase entropy suggest that plain
> English text has in the neighborhood of 1.5 to 2.5 bits of entropy per glyph.
> Just FYI. You can find these numbers in Shannon's original works on
> entropy
I'm not sure how I'm supposed to get GPG to automatically retrieve
keys for signatures when validating a key. I'm currently running:
gpg --keyserver-options auto-key-retrieve -kvv FBB75451
which doesn't do what I expect. I get a whole bunch of [User ID not
found] messages, when what I expecte
On Sat, Apr 16, 2011 at 11:00 AM, Peter Pentchev wrote:
> Mine, for instance, is over 30 characters long and, while it is derived
> from a couple of phrases, none of its components would be found by any
> reasonable brute-force or even dictionary attack, even by people who
> know me (please note t
Currently, it looks like pinentry-gtk-2 (I'm using 0.8.0) doesn't allow
pasting from the clipboard. This is annoying, because a truly long,
randomized password is not practical to type into a hidden dialog box. It
really seems like pinentry forces one to use short, insecure passwords. One
supposes
A month or so ago, I bumped into the fact that the howto on gnupg.org was a
bit outdated, and didn't really cover proper use of udev or libccid on
Debian and Ubuntu. So, I threw together a little howto of my own, and
bundled it with a new udev rules file and a helper script for generating new
udev
On Sat, Feb 26, 2011 at 5:53 PM, Hauke Laging
> dev_device="${DEVICE//proc/dev}"
> chgrp "${GROUP}" "${dev_device}"
> chmod g+rw "${dev_device}"
Thanks for the suggestion. However, $DEVICE isn't populated at all,
although the udev rule appears to be triggering. My script now
contains:
#!/bin/bash
Here are the steps I needed to take under Ubuntu 10.10 to get this
particular reader working properly as a mortal user.
1. sudo aptitude install --with-recommends libccid
2. sudo addgroup --system pcscd
3. sudo addgroup pcscd
4. cat << EOF | sudo tee /etc/udev/rules.d/gnupg-ccid.rules
SUBSYST
The following line in gnupg-ccid.rules will now create the /dev node
with the correct permissions, but the card reader itself still remains
inaccessible to non-root users:
ACTION=="add", SUBSYSTEM=="usb", ENV{PRODUCT}=="4e6/511f/*", GROUP="scard"
This seems like a simpler way to assign the GID, r
I have an SCR3310 card reader on an Ubuntu 10.10 system, and installed
the drivers through the libccid package. This works out of the box for
root, but mortal users can't access the card at all. I tried a lightly
modified version of the scripts from
http://www.gnupg.org/howtos/card-howto/en/smartca
I have an SCR3310 card reader on an Ubuntu 10.10 system, and installed
the drivers through the libccid package. This works out of the box for
root, but mortal users can't access the card at all. I tried a lightly
modified version of the scripts from
http://www.gnupg.org/howtos/card-howto/en/smartca
I've attempted (several times, in fact) to create a key pair with three
UIDs: one primary and two others. Whether using Seahorse or the command
line, I will manually set one of the UIDs as primary.
This *appears* to work locally, but if I export the keypair and then
import it into another gnupg ke
I've attempted (several times, in fact) to create a key pair with three
UIDs: one primary and two others. Whether using Seahorse or the command
line, I will manually set one of the UIDs as primary.
This *appears* to work locally, but if I export the keypair and then
import it into another gnupg ke
19 matches
Mail list logo
