Re: 1024 key with large sub key

2017-10-02 Thread Daniel Kahn Gillmor 
On Mon 2017-10-02 17:38:36 -0400, Robert J. Hansen wrote:
>> But in terms of being willing to make changes to the GnuPG option space
>> that break backward compatibility for some users in order to improve the
>> overall state of GnuPG crypto, removing --enable-large-rsa isn't
>> anywhere *close* to the top of my list.
>
> It's fine if it's not at the top of the list; but is there any
> compelling reason to not put it on the list?

sure, it's a simple recompile away (or installation of old versions) for
folks who want to enable it during key creation.  why would we encourage
those folks to run unmaintained versions, even if we think that their
long-key-fetishism isn't particularly well-motivated?  keeping the
two-stage thing in place makes it clear that this hard boundary is a
deliberate design decision, and some accomodation has been made, but
that we have explicit defaults for a reason.

Anyway, nothing on any list that actually deliberately "breaks backward
compatibilty for some users" is acceptable in GnuPG's current
development model afaict.

if that's not the case, then we should probably start by specifically
making a shared list of breaking changes and trying to prioritize them.

--dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 1024 key with large sub key

2017-10-02 Thread Robert J. Hansen 
> But in terms of being willing to make changes to the GnuPG option space
> that break backward compatibility for some users in order to improve the
> overall state of GnuPG crypto, removing --enable-large-rsa isn't
> anywhere *close* to the top of my list.

It's fine if it's not at the top of the list; but is there any
compelling reason to not put it on the list?




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 1024 key with large sub key

2017-10-02 Thread Daniel Kahn Gillmor 
On Mon 2017-10-02 15:04:07 -0400, Robert J. Hansen wrote:
> Anyone want to point out what I'm missing?  I don't want to sound as if
> my mind is made up, but right now it truly seems to me the
> --enable-large-rsa option is a misfeature.

I agree that there's no good reason to enable it by default.

But in terms of being willing to make changes to the GnuPG option space
that break backward compatibility for some users in order to improve the
overall state of GnuPG crypto, removing --enable-large-rsa isn't
anywhere *close* to the top of my list.

Note that --enable-large-rsa still only allows creation 8Kibit RSA keys,
not 10Kibit or 16Kibit keys like those reported in the original bugs, so
it doesn't actually cater to the hard-core "keylength-fetishist" crowd.

 --dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 1024 key with large sub key

2017-10-02 Thread Robert J. Hansen 
> see also https://bugs.debian.org/739424 and https://dev.gnupg.org/T1732
> 
> here's the commit log:

Thank you for digging this up.

I'd like to open a discussion about removing this option.

First, I think it was a misfeature from conception.  The justification
was, "Some older implementations built and used [large] RSA keys" --
which is absolutely true -- but there was no justification given to
allowing RSA keys *generated today* to be of that size.  Allowing GnuPG
to import keys of that size might be necessary to give users an upgrade
path; allowing GnuPG to *generate* keys of that size seems unjustified.

Since we are no longer concerned with "older implementations" (which I'm
assuming means "PGP 2.6 and its derivatives"), the original
justification is gone.  And on the downside, keeping this option in
place encourages a kind of cryptofetishism where all that matters is key
length.

Anyone want to point out what I'm missing?  I don't want to sound as if
my mind is made up, but right now it truly seems to me the
--enable-large-rsa option is a misfeature.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 1024 key with large sub key

2017-10-02 Thread Daniel Kahn Gillmor 
On Mon 2017-10-02 10:46:48 -0400, Robert J. Hansen wrote:
>> In batch mode it can go higher. 
>
> I was about to disagree with you when I discovered the
> --enable-large-rsa flag.
>
> When did this get introduced?  Why?  What possible use case is there for
> this?

It was introduced in 2014 in git commit
534e2876acc05f9f8d9b54c18511fe768d77dfb5 on STABLE-BRANCH-1-4, which was
subsequently ported to master.

see also https://bugs.debian.org/739424 and https://dev.gnupg.org/T1732

here's the commit log:


commit 534e2876acc05f9f8d9b54c18511fe768d77dfb5
Author: Daniel Kahn Gillmor 
Date:   Fri Oct 3 12:01:11 2014 -0400

gpg: Add build and runtime support for larger RSA keys

* configure.ac: Added --enable-large-secmem option.
* g10/options.h: Add opt.flags.large_rsa.
* g10/gpg.c: Contingent on configure option: adjust secmem size,
add gpg --enable-large-rsa, bound to opt.flags.large_rsa.
* g10/keygen.c: Adjust max RSA size based on opt.flags.large_rsa
* doc/gpg.texi: Document --enable-large-rsa.

--

Some older implementations built and used RSA keys up to 16Kib, but
the larger secret keys now fail when used by more recent GnuPG, due to
secure memory limitations.

Building with ./configure --enable-large-secmem will make gpg
capable of working with those secret keys, as well as permitting the
use of a new gpg option --enable-large-rsa, which let gpg generate RSA
keys up to 8Kib when used with --batch --gen-key.

Debian-bug-id: 739424

Minor edits by wk.

GnuPG-bug-id: 1732


Regards,

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 1024 key with large sub key

2017-10-02 Thread Peter Lebbing 
On 02/10/17 16:46, Robert J. Hansen wrote:
> I was about to disagree with you when I discovered the
> --enable-large-rsa flag.

Note that the key in question appears to be an ElGamal subkey, not RSA.

Not that that makes a difference to your questions and sentiments :-).

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 1024 key with large sub key

2017-10-02 Thread Robert J. Hansen 
> In batch mode it can go higher. 

I was about to disagree with you when I discovered the
--enable-large-rsa flag.

When did this get introduced?  Why?  What possible use case is there for
this?


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcard not seen when reinserted

2017-10-02 Thread Matthias Apitz 
El día lunes, octubre 02, 2017 a las 01:35:16p. m. +0200, Franck Routier 
escribió:

> My problem, in addition to the pin being cached "forever" (as long as
> the card is inserted, with no time limit), is that when I remove and
> reinsert the card, it is not recognized unless I restart gpg-agent.
> 
> So here is what happens:
> 
> card inserted
> pam_poldi.so called (sudo)   --> PIN requested
> pam_poldi.so called (sudo)   --> no PIN requested 
> pam_poldi.so called (sudo)   --> no PIN requested
> card removed (I don't like to let my card inserted, with no PIN
> validation needed !)
> card inserted--> card not seen (card error,
> OpenPGP card unavailable)
> gpgconf --kill gpg-agent   --> card seen
> pam_poldi.so called (sudo)   --> PIN requested
> pam_poldi.so called (sudo)   --> no PIN requested 
> etc...
> 
> Hence my questions:
> 1) can I force PIN for authentication each time I use it (it seems that
> the forcesig option is for signature only, not for authentication)
> 2) what can I do to have my card recognized on reinsert, without
> ressorting to killing gpg-agent
> --> probably with some scd-event magic that's beyond my know-how for
> now...

I'm using the attach 'scd-event' script to lock my display on card
removal and to unlock it on card-insert. The real work in the script is
at line 107++

Maybe it can serve you a bit.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ 
+49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
8. Mai 1945: Wer nicht feiert hat den Krieg verloren.
8 de mayo de 1945: Quien no festeja perdió la Guerra.
May 8, 1945: Who does not celebrate lost the War.
#!/bin/sh
#
# this script must be placed into GNUPGHOME dir and named 'scd-event';
# it is triggered by the scdaemon on card removal with the arg 'NOCARD'
# it will also run delayd after card insertion and *after* the first access to 
the card
#
# we use this to lock the KDE screen on card removal and run a loop of
# 'gpg2 --card-status' to unlock the screen after card insertion
#
# g...@unxarea.de, July 2017

echo $0 $* >> /tmp/scd-event.log

PGM=scd-event

reader_port=
old_code=0x
new_code=0x
status=

tick='`'
prev=
while [ $# -gt 0 ]; do
  arg="$1"
  case $arg in
  -*=*) optarg=$(echo "X$arg" | sed -e '1s/^X//' -e 's/[-_a-zA-Z0-9]*=//')
;;
 *) optarg=
;;
  esac
  if [ -n "$prev" ]; then
eval "$prev=\$arg"
prev=
shift
continue
  fi
  case $arg in
  --help|-h)
  cat <&2
  exit 1
  ;;

  *)
  break
  ;;
  esac
  shift
done
if [ -n "$prev" ]; then
  echo "$PGM: argument missing for option $tick$prev'" >&2
  exit 1
fi

cat <> /tmp/scd-event.log

port: $reader_port
old-code: $old_code
new-code: $new_code
status:   $status
EOF

DISPLAY=:0 export DISPLAY
if [ x$status = xNOCARD ]; then
echo DISPLAY: $DISPLAY >> /tmp/scd-event.log
echo /usr/local/lib/kde4/libexec/kscreenlocker_greet --immediateLock >> 
/tmp/scd-event.log
nohup /usr/local/lib/kde4/libexec/kscreenlocker_greet --immediateLock &
pid=$!
echo ${pid}  > /tmp/scd-event.pid
echo locked by PID ${pid} >> /tmp/scd-event.log
echo killing fetchmail >> /tmp/scd-event.log
fetchmail -q
while true; do
  # is the kscreenlocker_greet still running? user might have unlocked it 
with PAM
  /bin/kill -0 ${pid} || {
echo kscreenlocker_greet ${pid} disappeared >> /tmp/scd-event.log
break
  }
  # gpg2 --card-status >> /tmp/scd-event.log 2>> /tmp/scd-event.log
  # Signature key : 5E69 FBAC 1618 562C B3CB  FBC1 47CC F7E4 76FE 9D11
  gpg2 --card-status | grep '5E69 FBAC 1618 562C B3CB  FBC1 47CC F7E4 76FE 
9D11' >> /tmp/scd-event.log  && {
# OK, key is fine unlocking the movies
echo OK, key is fine unlocking the movies, killall kscreenlocker_greet 
>> /tmp/scd-event.log
killall kscreenlocker_greet
fetchmail
break
  }
  sleep 1  
done
fi


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcard not seen when reinserted

2017-10-02 Thread Franck Routier 
Le 01/10/2017 à 20:33, Matthias Apitz a écrit :
> El día domingo, octubre 01, 2017 a las 06:37:46p. m. +0200, Franck Routier 
> escribió:
>
>> Hi,
>>
>> I have a problem where my OpenPGP smartcard is not recognized when I
>> remove it from the reader and reinsert it.
>>
>> Moreover I like to remove the card and reinsert it when needed, as when
>> used for authentication with Poldi, I'm only asked for the PIN once, and
>> then the PIN is cached (at the smardcard level if I am to believe this
>> https://security.stackexchange.com/questions/147267/gpg-agent-keeps-saving-pin-for-a-smartcard/168312)
>>
>> ...
> I'm using a GnuPG-card for SSH and signing. I do not think, that it
> would be a good idea, that the secre on the card remain unlocked after
> withdraw (power reset) of the card, and mine does not cash it.
I agree with you, and I'm not asking for that. In fact I would like it
to ask for the pin each time I need to authenticate...
>  It works
> like this:
>
> card insert
> ssh server  --> PIN requested
> ssh server  --> no PIN requested
> gpg2 ... --sign ... --> no PIN requested
> gpg2 ... --decrypt  --> no PIN requested
> card remove
> card insert
> gpg2 ... --sign ... --> PIN requested
> ssh server  --> PIN requested
> ssh server  --> no PIN requested
Thanks Matthias for your input. I think I was not clear, so let me
restate my problem.

My problem, in addition to the pin being cached "forever" (as long as
the card is inserted, with no time limit), is that when I remove and
reinsert the card, it is not recognized unless I restart gpg-agent.

So here is what happens:

card inserted
pam_poldi.so called (sudo)   --> PIN requested
pam_poldi.so called (sudo)   --> no PIN requested 
pam_poldi.so called (sudo)   --> no PIN requested
card removed (I don't like to let my card inserted, with no PIN
validation needed !)
card inserted--> card not seen (card error,
OpenPGP card unavailable)
gpgconf --kill gpg-agent   --> card seen
pam_poldi.so called (sudo)   --> PIN requested
pam_poldi.so called (sudo)   --> no PIN requested 
etc...

Hence my questions:
1) can I force PIN for authentication each time I use it (it seems that
the forcesig option is for signature only, not for authentication)
2) what can I do to have my card recognized on reinsert, without
ressorting to killing gpg-agent
--> probably with some scd-event magic that's beyond my know-how for
now...

Thanks,
Franck



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 1024 key with large sub key

2017-10-02 Thread Nils Vogels 
In batch mode it can go higher. On 2 Oct 2017 2:53 am, "Robert J. Hansen"  wrote:this 1024 key has a 8192 sub key what is te meaning of such a large sub key?
You'd have to ask the owner.  If he used GnuPG to generate this key he'd
have to hack on the source code, because out of the box GnuPG only
generates up to 4096-bit keys.

___
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