Page MenuHome GnuPG
Create Task
Maniphest T1114

Can't use 3072-bit encryption key
Closed, ResolvedPublic
Actions

Description

3072 encryption keys don't function with the g10code GPG smartcard. 2048 keys do
work, as do 3072 signing keys. Not sure on authentication keys just yet. Seems
to be the same issue as T1105 but I can't add
a comment on it. I'm running Ubuntu karmic on amd64,

mcasadevall@daybreak:~$ gpg2 --version
gpg (GnuPG) 2.0.12
libgcrypt 1.4.4
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,

CAMELLIA192, CAMELLIA256

Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

mcasadevall@daybreak:~$ gpg2 --card-status
Application ID ...: D27600012401020000050000005D0000
Version ..........: 2.0
Manufacturer .....: ZeitControl
Serial number ....: 0000005D
Name of cardholder: Michael Casadevall
Language prefs ...: en
Sex ..............: male
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: 3072R 2048R 3072R
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 2
Signature key ....: 3396 1F69 327C 1645 B0CF 057E 89D1 1A4A 4E4D 5498
Encryption key....: B3D8 25C9 AE46 67CA 4357 1DEA EBBA 6FA1 7450 D014
Authentication key: FFFC 04A6 3FE8 AF4C F9A6 F660 A3C2 A7CD 1A8B DA08

Any attempts to use a 3074G bit key causes a Card Error. I'm happy to use a
2048R key if this is something that can't be worked around, but as I'm
regenerating a new GPG key as part of my move to the smartcard, I'd like to
reduce the number of subkeys on my keyring.

The cardreader is libccid supported. Not sure what else to put in here

Related Objects

Event Timeline

mcasadevall added projects: gnupg, Bug Report.Aug 25 2009, 8:41 AM
mcasadevall added a subscriber: mcasadevall.
mcasadevall added a comment.Aug 25 2009, 11:25 PM

I did some more debugging on this, it seems something can't handle the large
APDU messages generated when doing decryption with a 3072-bit key. Checking the
ISO documentation, a 64xx error is an execution error, so it seems either a bad
request is going to the card, or the card simply can't handle a long message:

Here's the log output from the 3072-bit key:
scdaemon[3777.0] DBG: -> S SERIALNO D27600012401020000050000005D0000 0
scdaemon[3777.0] DBG: -> OK
scdaemon[3777.0] DBG: <- SETDATA
ABF8CE25A22C7FB784C3844561F66D270B65921DCA7D1D97DB1B206E61FC034D2D8318C19E035C3506246C1DA35AE831F2119A6BF393D8FA23D1F661228BC11E34289D55BEACA21F1D32114F625DD8C58A0CABC34B825ED3737522A46E767F6370E371C80657E75CD2F060E195C3191EF9E79B8DB66276D4A6DD4CB80EE3D1E8166BAF3FD56ABCE0BDFD0A10B013747272B7459D40404C57A291ECC339E78A501768A1E37829F068592C1E451448DB08E88319BCB4D3B60570318AD4B81AD039EF50B1E3544AD5519FD59B9F0DACD87B8178AA2C5DE60B056D324694CEAC8A7CB03766CA546154AFEC40BCD79481E19C26BFF84A3894F3BD38000E5D56589116ACDCF7FA7320280A2355F1CF0295DC87EEFBE87C42554D9209E21BBA054298D6196C77D11F7DA55509F49373DD108E4217FD40ACC3D183F994914BD38CA976C5D2471287C1077131B5A938DE55A245574E2E6D08BF3DBBBD90B28229420606334FDE63A0F89ACD5F3473F34941DDD5235B91DAD29C42007C172A415871811E5F
scdaemon[3777.0] DBG: -> OK
scdaemon[3777.0] DBG: <- PKDECRYPT
D27600012401020000050000005D0000/114E692CD22F89C1F0EA4AE883AAF05EA3833408
2009-08-25 15:54:32 scdaemon[3777] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1
le=256 em=0
2009-08-25 15:54:32 scdaemon[3777] DBG: PCSC_data: 00 CA 00 6E 00
2009-08-25 15:54:32 scdaemon[3777] DBG: response: sw=9000 datalen=217
2009-08-25 15:54:32 scdaemon[3777] DBG: dump: 4F 10 D2 76 00 01 24 01 02
00 00 05 00 00 00 5D 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A
7C 00 08 00 08 00 08 00 08 00 C1 06 01 0C 00 00 20 00 C2 06 01 0C 00 00 20 00 C3
06 01 0C 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C 33 96 1F 69 32 7C 16 45 B0
CF 05 7E 89 D1 1A 4A 4E 4D 54 98 11 4E 69 2C D2 2F 89 C1 F0 EA 4A E8 83 AA F0 5E
A3 83 34 08 FF FC 04 A6 3F E8 AF 4C F9 A6 F6 60 A3 C2 A7 CD 1A 8B DA 08 C6 3C 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 CD 0C 4A 93 57 F8 4A 93 58 65 4A 93 58 C5
2009-08-25 15:54:32 scdaemon[3777] DBG: asking for PIN '||Please enter the PIN'
scdaemon[3777.0] DBG: -> INQUIRE NEEDPIN ||Please enter the PIN
2009-08-25 15:54:32 scdaemon[3777] updating slot 0 status: 0x0000->0x0007 (0->1)
2009-08-25 15:54:32 scdaemon[3777] sending signal 12 to client 3339
scdaemon[3777.0] DBG: <- [ 44 20 73 72 37 31 6c 6f 63 6b 64 6f ...(80 bytes
skipped) ]
scdaemon[3777.0] DBG: <- END
2009-08-25 15:54:36 scdaemon[3777] DBG: send apdu: c=00 i=20 p1=00 p2=82 lc=12
le=-1 em=0
2009-08-25 15:54:36 scdaemon[3777] DBG: PCSC_data: 00 20 00 82 0C 73 72 37 31
6C 6F 63 6B 64 6F 77 6E
2009-08-25 15:54:36 scdaemon[3777] DBG: response: sw=9000 datalen=0
2009-08-25 15:54:36 scdaemon[3777] DBG: dump:
2009-08-25 15:54:36 scdaemon[3777] DBG: send apdu: c=00 i=2A p1=80 p2=86 lc=385
le=256 em=1
2009-08-25 15:54:36 scdaemon[3777] DBG: PCSC_data: 00 2A 80 86 00 01 81 00 AB
F8 CE 25 A2 2C 7F B7 84 C3 84 45 61 F6 6D 27 0B 65 92 1D CA 7D 1D 97 DB 1B 20 6E
61 FC 03 4D 2D 83 18 C1 9E 03 5C 35 06 24 6C 1D A3 5A E8 31 F2 11 9A 6B F3 93 D8
FA 23 D1 F6 61 22 8B C1 1E 34 28 9D 55 BE AC A2 1F 1D 32 11 4F 62 5D D8 C5 8A 0C
AB C3 4B 82 5E D3 73 75 22 A4 6E 76 7F 63 70 E3 71 C8 06 57 E7 5C D2 F0 60 E1 95
C3 19 1E F9 E7 9B 8D B6 62 76 D4 A6 DD 4C B8 0E E3 D1 E8 16 6B AF 3F D5 6A BC E0
BD FD 0A 10 B0 13 74 72 72 B7 45 9D 40 40 4C 57 A2 91 EC C3 39 E7 8A 50 17 68 A1
E3 78 29 F0 68 59 2C 1E 45 14 48 DB 08 E8 83 19 BC B4 D3 B6 05 70 31 8A D4 B8 1A
D0 39 EF 50 B1 E3 54 4A D5 51 9F D5 9B 9F 0D AC D8 7B 81 78 AA 2C 5D E6 0B 05 6D
32 46 94 CE AC 8A 7C B0 37 66 CA 54 61 54 AF EC 40 BC D7 94 81 E1 9C 26 BF F8 4A
38 94 F3 BD 38 00 0E 5D 56 58 91 16 AC DC F7 FA 73 20 28 0A 23 55 F1 CF 02 95 DC
87 EE FB E8 7C 42 55 4D 92 09 E2 1B BA 05 42 98 D6 19 6C 77 D1 1F 7D A5 55 09 F4
93 73 DD 10 8E 42 17 FD 40 AC C3 D1 83 F9 94 91 4B D3 8C A9 76 C5 D2 47 12 87 C1
07 71 31 B5 A9 38 DE 55 A2 45 57 4E 2E 6D 08 BF 3D BB BD 90 B2 82 29 42 06 06 33
4F DE 63 A0 F8 9A CD 5F 34 73 F3 49 41 DD D5 23 5B 91 DA D2 9C 42 00 7C 17 2A 41
58 71 81 1E 5F 01 00
2009-08-25 15:54:38 scdaemon[3777] DBG: response: sw=640A datalen=0
2009-08-25 15:54:38 scdaemon[3777] operation decipher result: Card error
2009-08-25 15:54:38 scdaemon[3777] app_decipher failed: Card error
scdaemon[3777.0] DBG: -> ERR 100663404 Card error <SCD>
scdaemon[3777.0] DBG: <- RESTART
scdaemon[3777.0] DBG: -> OK

Here's the log from using a 2048-bit key:
2009-08-25 17:22:52 scdaemon[4232] updating slot 0 status: 0x0000->0x0007 (0->1)
2009-08-25 17:22:52 scdaemon[4232] sending signal 12 to client 3444
scdaemon[4232.0] DBG: <- SERIALNO openpgp
scdaemon[4232.0] DBG: -> S SERIALNO D27600012401020000050000005D0000 0
scdaemon[4232.0] DBG: -> OK
scdaemon[4232.0] DBG: <- SETDATA
A3820369D90CFA5F959277D8277CC9E15E6A0070EFEF5E6605D73D7453A5B79F613AA60398C6F87716B7AC46EFC816B6AD730A1B9742A649B3A08DFDF073F9D23B6CA1E737E798FB59450A6F74433D1373C169B77A77EB7BA5FACD6CD2EE8C18B1ADF6FEF9F9888F6DBACC1B0F9C9A5D9C85583054D8644BC9100C1F902997DA158F4D5A7E65975603A12E1C3D3796B3634F8C8F14836DC41F6026BFCE7DF746DB6652C58EDC37C1FE597795FD88ED37DCC64C03D9E5AA63643598FD41DD4581DD4CEA84DBDD7D72230110C25A2D40CC6BB19A4006ED3857B292D50B6613B453D312734FEDE15C0E22CB353699823358E9CAEDC84CF0C9AA311BB34091ACEAD8
scdaemon[4232.0] DBG: -> OK
scdaemon[4232.0] DBG: <- PKDECRYPT
D27600012401020000050000005D0000/3BFEFA581EAB6C5928C7425C0CCC67071B675210
2009-08-25 17:23:06 scdaemon[4232] DBG: asking for PIN '||Please enter the PIN'
scdaemon[4232.0] DBG: -> INQUIRE NEEDPIN ||Please enter the PIN
scdaemon[4232.0] DBG: <- [ 44 20 73 72 37 31 6c 6f 63 6b 64 6f ...(80 bytes
skipped) ]
scdaemon[4232.0] DBG: <- END
2009-08-25 17:23:10 scdaemon[4232] DBG: send apdu: c=00 i=20 p1=00 p2=82 lc=12
le=-1 em=0
2009-08-25 17:23:10 scdaemon[4232] DBG: PCSC_data: 00 20 00 82 0C 73 72 37 31
6C 6F 63 6B 64 6F 77 6E
2009-08-25 17:23:10 scdaemon[4232] DBG: response: sw=9000 datalen=0
2009-08-25 17:23:10 scdaemon[4232] DBG: dump:
2009-08-25 17:23:10 scdaemon[4232] DBG: send apdu: c=00 i=2A p1=80 p2=86 lc=257
le=256 em=1
2009-08-25 17:23:10 scdaemon[4232] DBG: PCSC_data: 00 2A 80 86 00 01 01 00 A3
82 03 69 D9 0C FA 5F 95 92 77 D8 27 7C C9 E1 5E 6A 00 70 EF EF 5E 66 05 D7 3D 74
53 A5 B7 9F 61 3A A6 03 98 C6 F8 77 16 B7 AC 46 EF C8 16 B6 AD 73 0A 1B 97 42 A6
49 B3 A0 8D FD F0 73 F9 D2 3B 6C A1 E7 37 E7 98 FB 59 45 0A 6F 74 43 3D 13 73 C1
69 B7 7A 77 EB 7B A5 FA CD 6C D2 EE 8C 18 B1 AD F6 FE F9 F9 88 8F 6D BA CC 1B 0F
9C 9A 5D 9C 85 58 30 54 D8 64 4B C9 10 0C 1F 90 29 97 DA 15 8F 4D 5A 7E 65 97 56
03 A1 2E 1C 3D 37 96 B3 63 4F 8C 8F 14 83 6D C4 1F 60 26 BF CE 7D F7 46 DB 66 52
C5 8E DC 37 C1 FE 59 77 95 FD 88 ED 37 DC C6 4C 03 D9 E5 AA 63 64 35 98 FD 41 DD
45 81 DD 4C EA 84 DB DD 7D 72 23 01 10 C2 5A 2D 40 CC 6B B1 9A 40 06 ED 38 57 B2
92 D5 0B 66 13 B4 53 D3 12 73 4F ED E1 5C 0E 22 CB 35 36 99 82 33 58 E9 CA ED C8
4C F0 C9 AA 31 1B B3 40 91 AC EA D8 01 00
2009-08-25 17:23:11 scdaemon[4232] DBG: response: sw=9000 datalen=35
2009-08-25 17:23:11 scdaemon[4232] DBG: dump: 09 E0 B4 A7 BC 53 8C 7B 2C
2D 67 AC 6A BF 0C 20 D9 0E 7A AB 39 85 CE 6A F4 01 B5 0E B3 74 70 DC E0 10 1F
2009-08-25 17:23:11 scdaemon[4232] operation decipher result: Success
scdaemon[4232.0] DBG: -> [ 44 20 09 e0 b4 a7 bc 53 8c 7b 2c 2d ...(25 bytes
skipped) ]
scdaemon[4232.0] DBG: -> OK
scdaemon[4232.0] DBG: <- RESTART
scdaemon[4232.0] DBG: -> OK

The main difference is the length of the command data field (if I understand the
APDU specs correctly). Is scdaemon malforming the packet when it gets to this
size, or is it an issue with the card not able to parse this sized packet?

• werner added a subscriber: • werner.Aug 26 2009, 3:09 PM

Is "3074G bit" a type or do you really try to use an Elgamal key? The card does
only support RSA keys.

mcasadevall added a comment.Aug 27 2009, 11:15 AM

Sorry, I typoed, it was 3072R that I generated and failed to use. Its the same
type of key used in T1105. A 2048R key works
fine.

tsndcb mentioned this in T1113: sign + encryption OK but decryption failed with 3072 bits key on smartcard V2.Mar 30 2017, 7:11 PM
• werner added a comment.Sep 1 2009, 11:15 AM

What reader are you using? USB vendor and product id (lsusb).

mcasadevall added a comment.Sep 1 2009, 1:39 PM

Here's the output from lsusb:

Bus 008 Device 002: ID 17ef:1003 Lenovo
Device Descriptor:

bLength                18
bDescriptorType         1
bcdUSB               2.00
bDeviceClass            0 (Defined at Interface level)
bDeviceSubClass         0 
bDeviceProtocol         0 
bMaxPacketSize0         8
idVendor           0x17ef Lenovo
idProduct          0x1003 
bcdDevice            1.00
iManufacturer           1 Lenovo
iProduct                2 Integrated Smart Card Reader
iSerial                 0 
bNumConfigurations      1
Configuration Descriptor:
  bLength                 9
  bDescriptorType         2
  wTotalLength           93
  bNumInterfaces          1
  bConfigurationValue     1
  iConfiguration          0 
  bmAttributes         0xa0
    (Bus Powered)
    Remote Wakeup
  MaxPower              100mA
  Interface Descriptor:
    bLength                 9
    bDescriptorType         4
    bInterfaceNumber        0
    bAlternateSetting       0
    bNumEndpoints           3
    bInterfaceClass        11 Chip/SmartCard
    bInterfaceSubClass      0 
    bInterfaceProtocol      0 
    iInterface              0 
    ** UNRECOGNIZED:  36 21 00 01 00 07 03 00 00 00 a0 0f 00 00 a0 0f 00 00 00

00 2a 00 00 20 a1 07 00 00 fe 00 00 00 00 00 00 00 00 00 00 00 30 02 01 00 0f 01
00 00 00 00 00 00 00 01

Endpoint Descriptor:
  bLength                 7
  bDescriptorType         5
  bEndpointAddress     0x02  EP 2 OUT
  bmAttributes            2
    Transfer Type            Bulk
    Synch Type               None
    Usage Type               Data
  wMaxPacketSize     0x0040  1x 64 bytes
  bInterval               0
Endpoint Descriptor:
  bLength                 7
  bDescriptorType         5
  bEndpointAddress     0x82  EP 2 IN
  bmAttributes            2
    Transfer Type            Bulk
    Synch Type               None
    Usage Type               Data
  wMaxPacketSize     0x0040  1x 64 bytes
  bInterval               0
Endpoint Descriptor:
  bLength                 7
  bDescriptorType         5
  bEndpointAddress     0x81  EP 1 IN
  bmAttributes            3
    Transfer Type            Interrupt
    Synch Type               None
    Usage Type               Data
  wMaxPacketSize     0x0008  1x 8 bytes
  bInterval              24

Device Status: 0x0000

(Bus Powered)
• werner added a comment.Sep 1 2009, 8:36 PM

According to http://pcsclite.alioth.debian.org/supported.html#0x17EF0x1003
this is a supported reader. I will have a closer look at your log file tomorrow.

• werner added a comment.Sep 2 2009, 7:37 PM

There is one bug in gpg: The Le field of the APDU is set to 256 but we expect a
larger return value. I fixed that problem in the just released 1.4.10.

The other bug seems to be in the card's OS. Needs further investigation.

mcasadevall added a comment.Sep 2 2009, 8:13 PM

I was using gnupg2 during these tests, was that affected by the APDU field size
issue?

• werner added a comment.Sep 2 2009, 9:16 PM

Yes, it is the same code.

• werner closed this task as Resolved.May 12 2010, 12:10 PM
• werner claimed this task.

Note: The bug in the card's firmware has been fixed for some time now.