From eocsor at gmail.com Thu Sep 2 13:09:34 2010 From: eocsor at gmail.com (Roscoe) Date: Thu, 2 Sep 2010 21:09:34 +1000 Subject: Questions about key generation and RNG In-Reply-To: <20100805123934.171040@gmx.net> References: <20100805123934.171040@gmx.net> Message-ID: On Thu, Aug 5, 2010 at 10:39 PM, Simon Nauberg wrote: > b) In the German Wikipedia, I've read the following quote: > "Aus Performancegr?nden wird in der Praxis oft nur der Seed eines Pseudo-Zufallszahlengenerators von /dev/random gelesen (z. B. in OpenSSL, PGP und GnuPG)." (http://de.wikipedia.org/wiki//dev/random) > Which means about, that only the seed of the PRNG from /dev/random would be used by gnupg. > This sounds like a limitation, so what exactly does it mean? Is it that gnupg has it's own PRNG (if so which one? BBS? Yarrow?) and uses /dev/random just to seed that one? Reading the comments at the start of random.c answers that :), as I imagine you've noticed. > c) When creating keys (especially the asymmetric keys) a good entropy is very critical. Is there kind of a "how to" what one should do or avoid in order to gain "best possible" entropy for that? E.g. things like, not generating a directly after booting, producting a lot of valuable entropy (e.g. via keybord/mouse events) before. Well, as you've observed the ultimate source of entropy under GNU/Linux is /dev/random and that in order for its output to be any good it has to be sufficiently seeded. > d) Should one use EGD rather than /dev/random (or whatever gnupg uses internally)? If so, why is it better? Depends. Is there some reason to trust EGD over /dev/random? You're probably going to have to do some research on that front....Though most of the world seems happy to use /dev/random. It certainly isn't perfect, as research will reveal. > e) When creating keys with "highest demands"... it probably makes sense to use TRNGs, right? > If so, does this still help if gnugp comes with its own PRNG and uses /dev/random just for seeding that (see (b) ). You could seed /dev/random, though if you distrust /dev/random a more direct way would be to write 600 bytes of TRNG output to ~/.gnupg/random_seed, and take steps to ensure an adversary could never read that file - for if they could, you'd be relying on /dev/random and the system time. > Is it suggested to use several TRNGs at once? Maybe. It certainly increases ones confidence. If you XOR together the output of a set of TRNGs, it'll be at least as good as the best TRNG in your set. > f) Any other hints for key-generation? e.g. obscure tricks like changing the system-time, if that one is taken into account for the RNG. Or stuff like that? Changing system time is a waste of time (ha!). -- Roscoe From wk at gnupg.org Thu Sep 2 15:02:44 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Sep 2010 15:02:44 +0200 Subject: Questions about key generation and RNG In-Reply-To: (Roscoe's message of "Thu, 2 Sep 2010 21:09:34 +1000") References: <20100805123934.171040@gmx.net> Message-ID: <871v9cjo23.fsf@gnupg.org> On Thu, 2 Sep 2010 13:09, eocsor at gmail.com said: > Depends. Is there some reason to trust EGD over /dev/random? You're EGD is a kludge for systems lacking /dev/random. The kernel is the best place to collect entropy; all kind of user processes to do this are a second choice. EGD was written to solve a problem with the internal rndunix entropy collector of GPG: GPG is a short living process and needs to run all the unix tools to collect entropy; after that entropy has been used GPG terminates and any left entropy is lost. EGD solves this wasting entropy problem. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From calestyo at scientia.net Fri Sep 3 19:26:03 2010 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Fri, 03 Sep 2010 19:26:03 +0200 Subject: Questions about key generation and RNG In-Reply-To: <871v9cjo23.fsf@gnupg.org> References: <20100805123934.171040@gmx.net> <871v9cjo23.fsf@gnupg.org> Message-ID: <1283534763.3244.52.camel@fermat.scientia.net> On Thu, 2010-09-02 at 15:02 +0200, Werner Koch wrote: > EGD is a kludge for systems lacking /dev/random. The kernel is the best > place to collect entropy; all kind of user processes to do this are a > second choice. You don't include the daemons used by TRNGs in order to seed the kernels PRNG, do you? Cheers, Chris. From gniibe at fsij.org Sun Sep 5 20:07:05 2010 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 06 Sep 2010 03:07:05 +0900 Subject: FSIJ USB Token version 2 and Gnuk Message-ID: <4C83DC49.6050804@fsij.org> Hi there, In 2008, we tried USB Token implementation for GnuPG with Atmel AVR. It worked a little. It was 8-bit processor with no USB controller and it was not for real use. This year, I am trying to build a new version with STM32. I named the software "Gnuk", and initial version is at: http://www.gniibe.org/oitoite/gnuk/gnuk-0.0.tar.gz It uses ChibiOS/RT, and uses polarSSL for RSA computation. For hardware, I am using STM32-H103 board by Olimex: http://www.olimex.com/dev/stm32-h103.html Currently, it only supports RSA 2048-bit digital signature. With Gnuk, I am learning OpenPGP card protocol version 2. Today, I just put a tar ball. We will have Git repository soon. Enjoy, -- From carlo.bramix at libero.it Thu Sep 9 16:52:44 2010 From: carlo.bramix at libero.it (carlo.bramix at libero.it) Date: Thu, 9 Sep 2010 16:52:44 +0200 (CEST) Subject: LIBKSBA fixes for Windows Message-ID: <26836308.445021284043964192.JavaMail.defaultUser@defaultHost> Hello, attached to this email there is a very simple fix that allows to compile libksba-1.0.8 on mingw+msys. I could not file a bug to bugzilla, I received an error of html page not found. Since it's so small, I hope it can be accepted by email too. Sincerely, Carlo Bramini. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: libksba.txt URL: From gniibe at fsij.org Mon Sep 13 05:05:16 2010 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 13 Sep 2010 12:05:16 +0900 Subject: FSIJ USB Token version 2 and Gnuk In-Reply-To: <4C83DC49.6050804@fsij.org> References: <4C83DC49.6050804@fsij.org> Message-ID: <4C8D94EC.3090300@fsij.org> 2010-09-06 03:07, NIIBE Yutaka wrote: > This year, I am trying to build a new version with STM32. I named > the software "Gnuk" [...] Now, we have a web page at: http://www.fsij.org/gnuk/ Read-only Git: http://www.gniibe.org/git/gnuk.git/ And I released version 0.2 today. I think that it is somewhat usable now. Enjoy, -- From wk at gnupg.org Mon Sep 13 12:58:03 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 13 Sep 2010 12:58:03 +0200 Subject: LIBKSBA fixes for Windows In-Reply-To: <26836308.445021284043964192.JavaMail.defaultUser@defaultHost> (carlo's message of "Thu, 9 Sep 2010 16:52:44 +0200 (CEST)") References: <26836308.445021284043964192.JavaMail.defaultUser@defaultHost> Message-ID: <87bp81kj0k.fsf@vigenere.g10code.de> On Thu, 9 Sep 2010 16:52, carlo.bramix at libero.it said: > Hello, > attached to this email there is a very simple fix that allows to compile > libksba-1.0.8 on mingw+msys. Although this is not supported I commited a similar change. > I could not file a bug to bugzilla, I received an error of html page not > found. There is no bugzilla but bugs.gnupg.org. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Sep 15 20:13:28 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 15 Sep 2010 20:13:28 +0200 Subject: FSIJ USB Token version 2 and Gnuk In-Reply-To: <4C8D94EC.3090300@fsij.org> (NIIBE Yutaka's message of "Mon, 13 Sep 2010 12:05:16 +0900") References: <4C83DC49.6050804@fsij.org> <4C8D94EC.3090300@fsij.org> Message-ID: <87pqweho3b.fsf@vigenere.g10code.de> On Mon, 13 Sep 2010 05:05, gniibe at fsij.org said: > Now, we have a web page at: http://www.fsij.org/gnuk/ > Read-only Git: http://www.gniibe.org/git/gnuk.git/ I have this version now running using openocd -f interface/neodb.cfg -f board/olimex_stm32_h103.cfg . I try to use it with GnuPG's internal CCID driver ("scdaemon --debug-ccid-driver --server"). This requires to ignore the test on "Auto configuration based on ATR" in dwFeatures. The problem now is a ERR01 from gnuk due to an unexepcted state - on the scdaemon side this is an usb_bulk_read_error. Quite some time passed since I wrote the internal driver and it is possible it does something which is not allowed by the USB specs. gnuk seems to be a nice tool to figure out such problems. BTW, does anyone know how to restrict openocd to listen for the telnet connection only on localhost? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Sep 15 21:00:18 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 15 Sep 2010 21:00:18 +0200 Subject: FSIJ USB Token version 2 and Gnuk In-Reply-To: <4C8D94EC.3090300@fsij.org> (NIIBE Yutaka's message of "Mon, 13 Sep 2010 12:05:16 +0900") References: <4C83DC49.6050804@fsij.org> <4C8D94EC.3090300@fsij.org> Message-ID: <878w32hlx9.fsf@vigenere.g10code.de> Hi, I looked into the problem with the GnuPG'c CCID driver and found this: DBG: ccid-driver: PC_to_RDR_IccPowerOn: DBG: ccid-driver: dwLength ..........: 0 DBG: ccid-driver: bSlot .............: 0 DBG: ccid-driver: bSeq ..............: 1 DBG: ccid-driver: bPowerSelect ......: 0x00 (auto) DBG: ccid-driver: [0008] 00 00 We sent the power on command DBG: ccid-driver: RDR_to_PC_DataBlock: DBG: ccid-driver: dwLength ..........: 12 DBG: ccid-driver: bSlot .............: 0 DBG: ccid-driver: bSeq ..............: 1 DBG: ccid-driver: bStatus ...........: 0 DBG: ccid-driver: [0010] 3B 94 11 81 31 FE DBG: ccid-driver: [0016] 55 46 53 49 4A 88 We received the ATR as response to the power on command. DBG: ccid-driver: PC_to_RDR_GetParameters: DBG: ccid-driver: dwLength ..........: 0 DBG: ccid-driver: bSlot .............: 0 DBG: ccid-driver: bSeq ..............: 2 DBG: ccid-driver: [0007] 00 00 00 We sent a GetParameters command to gnuk. This is not implemented and on the debug channel we get "ERR03". gnuk puts itsself back into the init state and did not sent and error response. DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable Thus GnuPG's try to read the response fails at the USB level.... DBG: ccid-driver: GetParameters failed and finally concludes that GetParameters failed. Because it does not know that gnuk is now in the init state again and all further commands result in "ERR01" (invalid command for the init state). I see a line with "6c" before the first "ERR01", though. I am not sure whether GetParameters must be implemented, I would ned to study the specs again. In any case I suggest to return a proper error response. What we can do in GnuPG's CCID driver is to issue a PowerOn command after an USB read failure. I hesitated to do this because it resets the card and a few read errors may happen from time to time without bad consequences. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Thu Sep 16 02:19:37 2010 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 16 Sep 2010 09:19:37 +0900 Subject: FSIJ USB Token version 2 and Gnuk In-Reply-To: <878w32hlx9.fsf@vigenere.g10code.de> References: <4C83DC49.6050804@fsij.org> <4C8D94EC.3090300@fsij.org> <878w32hlx9.fsf@vigenere.g10code.de> Message-ID: <4C916299.3080406@fsij.org> Hi, Thanks for testing Gnuk. The document I read was: http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_USB-ICC_ICCD_rev10.pdf I think that this is a subset of CCID specification. I read it as ICCD implementation allow to implement only three kinds of interactions. ===================================================== Section# PC->Target Target->PC ----------------------------------------------------- 6.1.1.1 PC_to_RDR_IccPowerOn RDR_PC_DataBlock 6.1.1.2 PC_to_RDR_IccPowerOff RDR_PC_SlotStatus 6.1.1.3 PC_to_RDR_XfrBlock RDR_PC_DataBlock ----------------------------------------------------- I don't know how an implementation should behave for unsupported commands. Let me think about the handling of unsupported commands. I think that there is better way than ignoring. Werner Koch wrote: > DBG: ccid-driver: PC_to_RDR_GetParameters: > DBG: ccid-driver: dwLength ..........: 0 > DBG: ccid-driver: bSlot .............: 0 > DBG: ccid-driver: bSeq ..............: 2 > DBG: ccid-driver: [0007] 00 00 00 > > We sent a GetParameters command to gnuk. This is not implemented and on > the debug channel we get "ERR03". gnuk puts itsself back into the init > state and did not sent and error response. > > DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable > DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable > DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable > DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable > > Thus GnuPG's try to read the response fails at the USB level.... Or, it would be easy for Gnuk to just implement GetParameters. In fact, Gnuk supports more commands, so that it works well with libccid implementation. Specifically, it supports: PC_to_RDR_GetSlotStatus RDR_to_PC_SlotStatus PC_to_RDR_SetParameters RDR_to_PC_Parameters Besides, it is known that libccid sends CCID class specific request of GET_DATA_RATES to control pipe (Endpoint 0), which Gnuk ignores. -- From gniibe at fsij.org Thu Sep 16 04:19:34 2010 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 16 Sep 2010 11:19:34 +0900 Subject: Gnuk change for CCID/ICCD protocol error In-Reply-To: <4C916299.3080406@fsij.org> References: <4C83DC49.6050804@fsij.org> <4C8D94EC.3090300@fsij.org> <878w32hlx9.fsf@vigenere.g10code.de> <4C916299.3080406@fsij.org> Message-ID: <4C917EB6.9010709@fsij.org> NIIBE Yutaka wrote: > I don't know how an implementation should behave for unsupported > commands. > > Let me think about the handling of unsupported commands. I think > that there is better way than ignoring. I am reading: "USB Integrated Circuit(s) Cards Interface Devices" http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_CCID_Rev110.pdf It says: ------------------------ 6. CCID Messages [...] A Bulk-OUT message is a command, and always receives at least one Bulk-IN message in response. The response messages always contain the exact same slot number, and sequence number fields from the header that was contained in the Bulk-OUT command message. ------------------------ So, ignoring Bulk-OUT message is not the option. We need to fix Gnuk. It says about failure: ------------------------ 6.2.7 Failure of a command A command fails when: ? The CCID does not support this command. Then the CCID sets the Slot Error register to `0' (index of bMessageType field). ? The CCID cannot parse one parameter or the ICC is not supporting one parameter. Then the Slot Error register contains the index of the first bad parameter as a positive number (1-127). For instance, if the CCID receives an ICC command to an unimplemented slot, then the Slot Error register shall be set to `5' (index of bSlot field). [...] ------------------------ It is not clear for me that what value of bMessageType should be for Bulk-IN responce message when we get error. When a command is not supported, an implementation of CCID doesn't know the responce message type for the command. So, I think that any value should be OK. I chose RDR_to_PC_SlotStatus. Besides, I think that state of CCID/ICCD implementation should not go Initial state (STATE_START in Gnuk) when it get unsupported command. Here is the change for Gnuk. 2010-09-16 NIIBE Yutaka * src/usb-icc.c (icc_error): New function. (icc_handle_data): Call icc_error. Don't go to STATE_START on errors. diff --git a/src/usb-icc.c b/src/usb-icc.c index bafa0ef..ab04304 100644 --- a/src/usb-icc.c +++ b/src/usb-icc.c @@ -57,6 +57,12 @@ #define ICC_ERROR_XFR_OVERRUN 0xFC +/* + * Since command-byte is at offset 0, + * error with offset 0 means "command not supported". + */ +#define ICC_OFFSET_CMD_NOT_SUPPORTED 0 +#define ICC_OFFSET_PARAM 8 struct icc_header { uint8_t msg_type; @@ -175,6 +181,41 @@ static const char ATR[] = { (0x94^0x11^0x81^0x31^0xFE^0x55^'F'^'S'^'I'^'J') }; +/* + * Send back error + */ +void +icc_error (int offset) +{ + icc_tx_data[0] = ICC_SLOT_STATUS_RET; /* Any value should be OK */ + icc_tx_data[1] = 0x00; + icc_tx_data[2] = 0x00; + icc_tx_data[3] = 0x00; + icc_tx_data[4] = 0x00; + icc_tx_data[5] = 0x00; /* Slot */ + icc_tx_data[ICC_MSG_SEQ_OFFSET] = icc_seq; + if (icc_state == ICC_STATE_START) + /* 1: ICC present but not activated 2: No ICC present */ + icc_tx_data[ICC_MSG_STATUS_OFFSET] = 1; + else + /* An ICC is present and active */ + icc_tx_data[ICC_MSG_STATUS_OFFSET] = 0; + icc_tx_data[ICC_MSG_STATUS_OFFSET] |= ICC_CMD_STATUS_ERROR; /* Failed */ + icc_tx_data[ICC_MSG_ERROR_OFFSET] = offset; + icc_tx_data[ICC_MSG_CHAIN_OFFSET] = 0x00; + + if (!icc_tx_ready ()) + { + DEBUG_INFO ("ERR0D\r\n"); + } + else + { + icc_tx_size = ICC_MSG_HEADER_SIZE; + USB_SIL_Write (EP1_IN, icc_tx_data, icc_tx_size); + SetEPTxValid (ENDP1); + } +} + /* Send back ATR (Answer To Reset) */ enum icc_state icc_power_on (void) @@ -334,8 +375,9 @@ icc_handle_data (void) else if (icc_header->msg_type == ICC_SLOT_STATUS) icc_send_status (); else - { /* XXX: error */ + { DEBUG_INFO ("ERR01\r\n"); + icc_error (ICC_OFFSET_CMD_NOT_SUPPORTED); } break; case ICC_STATE_WAIT: @@ -367,17 +409,18 @@ icc_handle_data (void) next_state = ICC_STATE_RECEIVE; } else - { /* XXX: error */; + { DEBUG_INFO ("ERR02\r\n"); + icc_error (ICC_OFFSET_PARAM); } } else if (icc_header->msg_type == ICC_SET_PARAMS) icc_send_params (); else - { /* XXX: error */ + { DEBUG_INFO ("ERR03\r\n"); DEBUG_BYTE (icc_header->msg_type); - next_state = ICC_STATE_START; + icc_error (ICC_OFFSET_CMD_NOT_SUPPORTED); } break; case ICC_STATE_EXECUTE: @@ -389,10 +432,10 @@ icc_handle_data (void) else if (icc_header->msg_type == ICC_SLOT_STATUS) icc_send_status (); else - { /* XXX: error */ + { DEBUG_INFO ("ERR04\r\n"); DEBUG_BYTE (icc_header->msg_type); - next_state = ICC_STATE_START; + icc_error (ICC_OFFSET_CMD_NOT_SUPPORTED); } break; case ICC_STATE_RECEIVE: @@ -418,8 +461,9 @@ icc_handle_data (void) else if (icc_header->param == 3) icc_send_data_block (0, 0, 0x10, NULL, 0); else - { /* XXX: error */ + { DEBUG_INFO ("ERR08\r\n"); + icc_error (ICC_OFFSET_PARAM); } } else /* Overrun */ @@ -430,10 +474,11 @@ icc_handle_data (void) } } else - { /* XXX: error */ + { DEBUG_INFO ("ERR05\r\n"); DEBUG_BYTE (icc_header->msg_type); - next_state = ICC_STATE_START; + icc_error (ICC_OFFSET_CMD_NOT_SUPPORTED); + next_state = ICC_STATE_WAIT; } break; case ICC_STATE_SEND: @@ -459,18 +504,20 @@ icc_handle_data (void) } } else - { /* XXX: error */ + { DEBUG_INFO ("ERR0A\r\n"); DEBUG_BYTE (icc_header->param >> 8); DEBUG_BYTE (icc_header->param & 0xff); + icc_error (ICC_OFFSET_PARAM); next_state = ICC_STATE_WAIT; } } else - { /* XXX: error */ + { DEBUG_INFO ("ERR06\r\n"); DEBUG_BYTE (icc_header->msg_type); - next_state = ICC_STATE_START; + icc_error (ICC_OFFSET_CMD_NOT_SUPPORTED); + next_state = ICC_STATE_WAIT; } break; } From smujohnson at gmail.com Thu Sep 16 05:18:02 2010 From: smujohnson at gmail.com (smu johnson) Date: Wed, 15 Sep 2010 20:18:02 -0700 Subject: Why are the signing digest orders in showpref not being used? Message-ID: Dear GnuPG, Have I found a bug? My key pref says SHA256 should be chosen first, so why does it use SHA1 instead when I encrypt for that key, and sign also with that key? If this is not a bug, what is the use of that preference order if it is just being ignored in the most basic case? I realize --digest-algo SHA256 would do what I want, but I mean... I thought the order of digests in the public key preferences was used to prevent me from having to do that. =============== Proof of order: =============== C:\tmp>gpg --edit-key smu gpg (GnuPG) 1.4.10; Copyright (C) 2009 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. pub 4096R/6FB7BD3F created: 2010-08-13 expires: 2020-08-10 usage: SC trust: ultimate validity: ultimate sub 4096R/E316B6A8 created: 2010-08-13 expires: 2020-08-10 usage: E [ultimate] (1). smu johnson Command> showpref [ultimate] (1). smu johnson Cipher: TWOFISH, CAMELLIA256, CAMELLIA192, CAMELLIA128, BLOWFISH, CAST5, AES, 3DES Digest: SHA256, SHA1, SHA384, SHA512, SHA224 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify Command> =========================== Proof of using SHA1 instead =========================== C:\tmp>echo piggy | gpg -a -se -r smu -u smu | gpg -v You need a passphrase to unlock the secret key for user: "smu johnson " 4096-bit RSA key, ID 6FB7BD3F, created 2010-08-13 gpg: armor header: Version: GnuPG v1.4.10 (MingW32) gpg: public key is E316B6A8 gpg: using subkey E316B6A8 instead of primary key 6FB7BD3F You need a passphrase to unlock the secret key for user: "smu johnson " gpg: using subkey E316B6A8 instead of primary key 6FB7BD3F 4096-bit RSA key, ID E316B6A8, created 2010-08-13 (main key ID 6FB7BD3F) gpg: encrypted with 4096-bit RSA key, ID E316B6A8, created 2010-08-13 "smu johnson " gpg: TWOFISH encrypted data gpg: original file name='' piggy gpg: Signature made 09/15/10 20:08:02 using RSA key ID 6FB7BD3F gpg: using PGP trust model gpg: Good signature from "smu johnson " gpg: binary signature, digest algorithm SHA1 ...there ya have it. Thanks in advance to anyone reading. -- smu johnson -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Sep 16 10:56:11 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Sep 2010 10:56:11 +0200 Subject: Gnuk change for CCID/ICCD protocol error In-Reply-To: <4C917EB6.9010709@fsij.org> (NIIBE Yutaka's message of "Thu, 16 Sep 2010 11:19:34 +0900") References: <4C83DC49.6050804@fsij.org> <4C8D94EC.3090300@fsij.org> <878w32hlx9.fsf@vigenere.g10code.de> <4C916299.3080406@fsij.org> <4C917EB6.9010709@fsij.org> Message-ID: <87fwxaf4no.fsf@vigenere.g10code.de> On Thu, 16 Sep 2010 04:19, gniibe at fsij.org said: > "USB Integrated Circuit(s) Cards Interface Devices" > http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_CCID_Rev110.pdf There is also DWG_Smart-Card_USB-ICC_ICCD_rev10.pdf which seems to be a kind of subset to the full CCID specs. At a quick check I have not found a way to distinguish this from the full CCID specs. > Besides, I think that state of CCID/ICCD implementation should not go > Initial state (STATE_START in Gnuk) when it get unsupported command. Agreed. With the current git I am able to access the card. However I need to see how to get Extended Length APDUs right at CCID level. My driver has mostly been tested with TPDU exchange, I don't have a reader which supports Extended Length APDU level exchange thus bugs in my code are very likley. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Thu Sep 16 23:44:11 2010 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 17 Sep 2010 06:44:11 +0900 Subject: Gnuk change for CCID/ICCD protocol error In-Reply-To: <87fwxaf4no.fsf@vigenere.g10code.de> References: <4C83DC49.6050804@fsij.org> <4C8D94EC.3090300@fsij.org> <878w32hlx9.fsf@vigenere.g10code.de> <4C916299.3080406@fsij.org> <4C917EB6.9010709@fsij.org> <87fwxaf4no.fsf@vigenere.g10code.de> Message-ID: <4C928FAB.9070403@fsij.org> Werner Koch wrote: > There is also DWG_Smart-Card_USB-ICC_ICCD_rev10.pdf which seems to be a > kind of subset to the full CCID specs. At a quick check I have not > found a way to distinguish this from the full CCID specs. I see the point. I agree that it is good for host side to have a way to distinguish ICCD only implementation. If not, ICCD only implementation should think about interaction based on full CCID specs. But, I have not found it, either. > Agreed. With the current git I am able to access the card. However I > need to see how to get Extended Length APDUs right at CCID level. I see this point too. For current gnuk, the information is only available at OpenPGP card protocol level (by Extended Capabilities). I thought dwMaxCCIDMessageLength would mention the length at APDU level, but I needed to limit this value to 64. That's because libccid seems to interpret this value as maximum size of packet at USB-ICC level (Bulk-IN/Bulk-OUT message). Perhaps, it would be libccid which need to be fixed. I think that the information of maximum size of packet at USB-ICC level is available in wMaxPacketSize in the endpoint descriptor. -- From openpgp at brainhub.org Sun Sep 19 09:30:52 2010 From: openpgp at brainhub.org (Andrey Jivsov) Date: Sun, 19 Sep 2010 00:30:52 -0700 Subject: GnuPG has now full ECC support (ECDSA, ECDH) Message-ID: <4C95BC2C.3090709@brainhub.org> Hello GnuPG! I am happy to announce that GnuPG now fully implements ECC encryption and signing capability. A user can generate an ECC key with gpg2 --gen-key and use it to encrypt or sign messages or keys. 256, 384, and 521 bit ECC keys are supported. This branched off implementation resides at the http://code.google.com/p/gnupg-ecc/ and follows the "ECC in OpenPGP" IETF draft http://sites.google.com/site/brainhub/pgp . Please refer to these sites for details and up-to-date status of the effort to bring ECC to users of OpenPGP format. Instead of wishing for this to happen for many years, I decided that the time is right to actually spend a few of my weekends and contribute the working source code to the OpenPGP community. The ideal destiny of the gnupg-ecc project is to be merged into mainline GnuPG source tree. I look forward working with GnuPG team to make this merge happen. Thank you. It's been my pleasure getting more familiar with gnupg and libgcrypt source code and I look forward finishing this effort up. From nicholas.cole at gmail.com Sun Sep 19 10:18:54 2010 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sun, 19 Sep 2010 09:18:54 +0100 Subject: OT: Padding Oracle Attacks Message-ID: There has been quite a lot on the net lately about Padding Oracle Attacks, said to affect many secure web applications. http://www.theregister.co.uk/2010/09/14/web_apps_crypto_flaw I was interested to see that the new Diaspora Social Networking software, which uses gpg internally (though presumably not for all things) is also said to suffer from this sort of flaw. I've come across two interesting descriptions of the attack: http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/ https://media.blackhat.com/bh-eu-10/whitepapers/Duong_Rizzo/BlackHat-EU-2010-Duong-Rizzo-Padding-Oracle-wp.pdf Am I right that this is exactly the sort of attack that the MDC in gpg is designed to prevent? Best wishes, Nicholas From wk at gnupg.org Sun Sep 19 19:06:49 2010 From: wk at gnupg.org (Werner Koch) Date: Sun, 19 Sep 2010 19:06:49 +0200 Subject: GnuPG has now full ECC support (ECDSA, ECDH) In-Reply-To: <4C95BC2C.3090709@brainhub.org> (Andrey Jivsov's message of "Sun, 19 Sep 2010 00:30:52 -0700") References: <4C95BC2C.3090709@brainhub.org> Message-ID: <87zkvdu0gm.fsf@vigenere.g10code.de> On Sun, 19 Sep 2010 09:30, openpgp at brainhub.org said: > I am happy to announce that GnuPG now fully implements ECC encryption > and signing capability. A user can generate an ECC key with gpg2 > --gen-key and use it to encrypt or sign messages or keys. 256, 384, > and 521 bit ECC keys are supported. Cool. I noticed that the documentation is really good. I'll look into the changes the next days. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From free10pro at gmail.com Sun Sep 19 23:01:01 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Sun, 19 Sep 2010 14:01:01 -0700 Subject: Why are the signing digest orders in showpref not being used? In-Reply-To: References: Message-ID: <4C967A0D.8080509@gmail.com> On Wed, 15 Sep 2010 20:18:02 -0700, smu johnson wrote: > Have I found a bug? My key pref says SHA256 should be chosen first, so why > does it use SHA1 instead when I encrypt for that key, and sign also with > that key? > > If this is not a bug, what is the use of that preference order if it is just > being ignored in the most basic case? I realize --digest-algo SHA256 would > do what I want, but I mean... I thought the order of digests in the public > key preferences was used to prevent me from having to do that. GnuPG is overriding the digest preferences in your key. The default is to require SHA-1. You have two choices--override the key's digest preferences or honor those preferences. To honor a key's digest preferences, use "--personal-digest-preferences none", or to safely mandate your preferences, use "--personal-digest-preferences digest_1,digest_2,digest_3". If you want to require a certain digest algorithm use "--personal-digest-preferences" rather than "--digest-algo", because if you use "--digest-algo", you could wind up using an algorithm that not all of your recipients can use. GnuPG will choose a digest that all recipients can handle if you use "--personal-digest-preferences". The manual for GnuPG provides the following explanation of "--personal-digest-preferences" (the *bold* emphasis is added to the below to indicate which portions of the manual used bold): *--personal-digest-preferences string* Set the list of personal digest preferences to *string*. Use *gpg --version* to get a list of available algorithms, and use *none* to set no preference at all. This allows the user to safely override the algorithm chosen by the recipient key preferences, as GPG will only select an algorithm that is usable by all recipients. The most highly ranked digest algorithm in this list is also used when signing without encryption (e.g. *--clearsign* or *--sign*). The default value is SHA-1. --Paul -- PGP Key ID: 0x3DB6D884 PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Sep 20 12:32:07 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Sep 2010 12:32:07 +0200 Subject: The last 9 months of GnuPG development Message-ID: <87k4mgu2mw.fsf@vigenere.g10code.de> Hi, I feel that I should give you a quick heads up on what's going on with GnuPG development. I have been quite silent the last months and only those following the commit list may have noticed the changes. In short Marcus and me ported GnuPG and related software to WindowsCE; to be more exact to Windows Mobile 6.5, testing on a HTC Touch pro 2. Obviously this is not something we would have done voluntary but someone convinced us by shifting money to the g10 Code account. As a side effect of this port we were able to clean up the code, fixing a couple of lingering bugs, introducing new bugs and also partly working on some stuff we had in mind for a long time. Let's have a look at the current NEWS list for the 2.1 development version (SVN trunk): * The GPGSM --audit-log feature is now more complete. This allows to better see what is going on with X.509 (S/MIME) certificate chain verification, CRL checks and so on. * The G13 tool for disk encryption key management has been added. This was already done last autumn. G13 is the forthcoming tool for disk encryption using OpenPGP key management. For now we only support EncFS but there are plans do do more. The general goal is to allow random access to encrypted data files managed with OpenPGP keys. * Support DNS lookups for SRV, PKA and CERT on W32. This was somehow missing for quite some time. * New and changed passphrases are now created with an iteration count requiring about 100ms of CPU work. Already backported to 2.0. * Support for Windows CE. The stuff which took up most of the time. * If the agent's --use-standard-socket option is active, all tools try to start and daemonize the agent on the fly. In the past this was only supported on W32; on non-W32 systems the new configure option --enable-standard-socket may now be used to use this feature by default. I think that this is important. I hope that it will make it easier to install and use GnuPG-2. * Dirmngr is now a part of this package. Dirmngr is now also expected to run as a system service and the configuration directories are changed to the GnuPG name space. Dirmngr is used to retrieve and check CRLs and do OCSP checking on behalf of GPGSM. For historic reasons it was a separate package but has now been merged into GnuPG-2, proper. * Given sufficient permissions Dirmngr is started automagically. We can do that only on some platforms; i.e. on mobile devices. Standard systems should start it like every other system service. * GPG does not anymore use secring.gpg but delegates all secret key operations to gpg-agent. The import command moves secret keys to the agent. That is something which should have happened much earlier. It makes the GPG code less complicate and thus eases maintenance. Note that in the past the gpg-agent was used by gpg-agent only for passphrase caching; now Gpg-Agent does all secret key operations (generate, sign, decrypt) for GPGSM and for GPG. This part is not finished; for example I am currently working on the OpenPGP export command and I also need to make some changes for smartcards. * The OpenPGP import command is now able to merge secret keys. This is a direct consequence of the above item. We get it more or less for free. A little drawback - but also something which has been asked for - is that importing a secret key now requires the user to enter the passphrase (because gpg-agent needs to re-protect it). There are some more tasks required before a first 2.1 release: * Let Dirmngr replace the key server helpers. This also prepares the infrastructure for queuing key retrieval (think of revocations). * Finish the GPG export command. * Decide whether GPG should auto-migrate secret keys to gpg-agent. * Implement a persistent passphrase cache. That is to allow users of gpg-agent to store passphrases along with meta information under a master key. The idea is that other applications can use this as a crypto key/value store. * Merge Andrey's ECC for OpenPGP code. I would also like to implement the new key storage backend for public keys but that might be too many changes at once. Thus I plan to do a first 2.1 release using the old pubring.gpg format. 2.1.x will be a development series anyway. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From tom at ritter.vg Mon Sep 20 17:25:33 2010 From: tom at ritter.vg (Tom Ritter) Date: Mon, 20 Sep 2010 11:25:33 -0400 Subject: OT: Padding Oracle Attacks In-Reply-To: References: Message-ID: > I've come across two interesting descriptions of the attack: > > http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/ > https://media.blackhat.com/bh-eu-10/whitepapers/Duong_Rizzo/BlackHat-EU-2010-Duong-Rizzo-Padding-Oracle-wp.pdf The GDS blog post is the best visual example of how the Padding Oracle can be used to decrypt data that I've seen. Thai and Julian's presentation linked, as well as the recent one at Ekoparty, are excellent weaponizations. > Am I right that this is exactly the sort of attack that the MDC in gpg > is designed to prevent? I don't know much about the MDC in gpg - I'm curious how it differs from a HMAC. If the MDC is checked before decryption is attempted, it should thwart the attack, because gpg would fail with an error indicating an incorrect MDC, rather than a message indicating the padding is incorrect (for the 255 bad padding values) or the MDC is incorrect (for the 1 good padding value but bad MDC). This ordering is vital, and what leads to the ASP.Net encrypted viewstate being vulnerable. There is an HMAC on the viewstate, but the HMAC is checked _after_ the viewstate decryption is attempted. Colin Percival has a good blog post explaining this concept as well: http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html -tom From calestyo at scientia.net Mon Sep 20 21:53:27 2010 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Mon, 20 Sep 2010 21:53:27 +0200 Subject: GnuPG has now full ECC support (ECDSA, ECDH) In-Reply-To: <4C95BC2C.3090709@brainhub.org> References: <4C95BC2C.3090709@brainhub.org> Message-ID: <1285012407.3334.58.camel@fermat.scientia.net> Hi Andrey. This is really great news :) Any expectations on when the draft becomes and rfc? I mean it hasn't changed a lot recently. Do we have any folks who audit the code? Not that I wouldn't trust you,.. ;) Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5677 bytes Desc: not available URL: From nicholas.cole at gmail.com Mon Sep 20 23:13:04 2010 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 20 Sep 2010 22:13:04 +0100 Subject: OT: Padding Oracle Attacks In-Reply-To: References: Message-ID: On Mon, Sep 20, 2010 at 4:25 PM, Tom Ritter wrote: >> I've come across two interesting descriptions of the attack: >> >> http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/ >> https://media.blackhat.com/bh-eu-10/whitepapers/Duong_Rizzo/BlackHat-EU-2010-Duong-Rizzo-Padding-Oracle-wp.pdf > > The GDS blog post is the best visual example of how the Padding Oracle > can be used to decrypt data that I've seen. ?Thai and Julian's > presentation linked, as well as the recent one at Ekoparty, are > excellent weaponizations. > >> Am I right that this is exactly the sort of attack that the MDC in gpg >> is designed to prevent? > > I don't know much about the MDC in gpg - I'm curious how it differs > from a HMAC. ?If the MDC is checked before decryption is attempted, it > should thwart the attack, because gpg would fail with an error > indicating an incorrect MDC, rather than a message indicating the > padding is incorrect (for the 255 bad padding values) or the MDC is > incorrect (for the 1 good padding value but bad MDC). ?This ordering > is vital, and what leads to the ASP.Net encrypted viewstate being > vulnerable. ?There is an HMAC on the viewstate, but the HMAC is > checked _after_ the viewstate decryption is attempted. > > Colin Percival has a good blog post explaining this concept as well: > http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html The workings of the MDC are set out here: http://tools.ietf.org/html/rfc4880 (see section 5.13). It isn't clear to me after reading that whether this kind of attack would be thwarted by the MDC or not. --Nicholas From openpgp at brainhub.org Tue Sep 21 09:36:51 2010 From: openpgp at brainhub.org (Andrey Jivsov) Date: Tue, 21 Sep 2010 00:36:51 -0700 Subject: [SPAM] Re: GnuPG has now full ECC support (ECDSA, ECDH) In-Reply-To: <1285012407.3334.58.camel@fermat.scientia.net> References: <4C95BC2C.3090709@brainhub.org> <1285012407.3334.58.camel@fermat.scientia.net> Message-ID: <4C986093.2030602@brainhub.org> On 09/20/2010 12:53 PM, Christoph Anton Mitterer wrote: > Hi Andrey. > > > This is really great news :) Thank you Christoph. I am very pleased so far with the reception of my work. > > Any expectations on when the draft becomes and rfc? I mean it hasn't > changed a lot recently. I always believed that I would have much more confidence in the quality of draft if other members in OpenPGP community went through complete implementation phase. The target audience for this draft is developers, so in my opinion nothing can substitute the experience gained from writing the code. It makes sense to wait a little more until the GnuPG code makes into mainline code. In any case, my target is to move the draft forward in 2011. > > > Do we have any folks who audit the code? Not that I wouldn't trust > you,.. ;) ... following the previous paragraph, it's only logical for me to hope that long-term experienced GnuPG developers, such as Werner Koch, go over my changes and polish them up. My main focus in the initial contribution has been the correctness of generated data. > > Cheers, > Chris. From bernhard at intevation.de Wed Sep 22 10:01:13 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 22 Sep 2010 10:01:13 +0200 Subject: [Gpg4win-devel] X509 Root certificates and trusting them Message-ID: <201009221001.16509.bernhard@intevation.de> Am Freitag, 21. Mai 2010 12:03:22 schrieb Bernhard Reiter: > The recommended way for a > production X509 /CMS system is that a list of trusted X509 root > certificates is maintained by the administrator of the system > directly for dirmngr and possibly the global gpgsm. For gpgsm to be able to use certificates, you need to have the full validated chain of certificates. [Forth edition] Especially for the root certificate, the person administrating the machines (e.g. you) must ensure four conditions are given. (Paths examples are for GNU systems, the paths will be different for Mac OS or Windows.) a) You need to have the root certificate and be sure that the file you have is really the root certificate you would like to trust. You need to do this best at installation time, because later - in the heat of the moment - users will go along with everthing unchecked just to get the task done. b.1) Make sure dirmngr trusts the root certificate. info dirmngr Installation konqueror info:/dirmngr/Installation http://gnupg.org/documentation/manuals/dirmngr/Installation.html In short, recommended is to use the system dirmngr, place the root certification file in .der format in /etc/dirmngr/trusted-certs and restart the dirmngr service. b.2) Current revocation status information must be available. gpgsm will ask dirmngr to validate each certificate. As administrator you need to make sure that dirmngr can do that check. Usually certificates contain information where to get the revocation list via http or ldap. So dirmngr should be able to do http and ldap calls to the internet. Secure connections are not necessary as revocation info is already signed. You can tune dirmngr to use proxies or always ask specific servers via ldap. There are a number of other ways, like OCSP, to get revocation information. Too much to list them here. With sane certificate authorities and network settings it will just work with the revocation lists out of the box. If you need to trouble shoot, you can turn off checking of revocation information for a moment to verify that this is the problem. Leaving this off for production will degrade security significantly. Users should have "prefer-system-dirmngr" in their local gpgsm.conf (Usually ~/.gnupg/gpgsm.conf). So that the system dirmngr is asked all the time. c) Make sure gpg-agent trusts the root certificate Recommended way is to do this system wide: c.1) Place the right line in /etc/gnupg/trustlist.txt Note that quite a few certificate authorities need the "relax" option because they fail to get some requirements right. So test everything later and if it does not work, try with "relax". References: Existence of configuration file: info gnupg2 Installation konqueror info:/gnupg2/Installation http://gnupg.org/documentation/manuals/gnupg/Installation.html Format of trustlist.txt: info gnupg2 "Invoking GPG-AGENT" "Agent Configuration" konqueror info:/gnupg2/Agent Configuration http://gnupg.org/documentation/manuals/gnupg/Agent-Configuration.html c.2) Make sure all users either * have no personal trustlist.txt or * have the option "include-default" in it. The file will usually searched at ~/.gnupg/trustlist.txt. I guess all gpg-agents will need a kick after the trustlist.txt change. Try sending a SIGHUP to all gpg-agent processes, e.g. pkill -SIGHUP gpg-agent or reboot. In general: If you wish to update all users' private configuration files, you can try using Gnupg's helper application called applygnupgdefaults Documentation starts here: info gnupg2 "Helper Tools" applygnupgdefaults konqueror info:/gnupg2/applygnupgdefaults http://gnupg.org/documentation/manuals/gnupg/applygnupgdefaults.html Hints for reading the documentation: Using the documentation of your installed version is preferred, because it usually is most correct. Use "info" on the commandline, if you are familiar with it. It will be installed on many GNU systems. There are other exotic texinfo console viewers of course like tkman or pinfo. If you have konqueror installed using "info:gnupg2" as URL will also work. Konqueror internally uses the script /usr/share/apps/kio_info/kde-info2html which on Debian Lenny comes with the kdebase-kio-plugins package. This is my prefered method. Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Sep 23 12:22:04 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 23 Sep 2010 12:22:04 +0200 Subject: 1.4.11 release candidate (was: Overflow bug in bzip2) In-Reply-To: <88A4EB44-1149-47C5-B6B4-CF450A2BD27E@jabberwocky.com> (David Shaw's message of "Tue, 21 Sep 2010 23:01:28 -0400") References: <88A4EB44-1149-47C5-B6B4-CF450A2BD27E@jabberwocky.com> Message-ID: <87aan869pv.fsf@vigenere.g10code.de> Hi, The Windows installer version of GnuPG 1.4 uses a statically linked bzip library. Thus the bzip2 bug affects this version. We have not done a gnupg 1.4 release for more than a year. I believe it is best to first do a release candidate. There a couple of bug fixes collected over the last year to go into 1.4.11, but nothing really important. However to build the 1.4 windows installer we better use the new source along with an updated bzip. Here we go: GnuPG 1.4.11 release candidate 1 is availabale at ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.11rc1.tar.bz2 (3360k) ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.11rc1.tar.bz2.sig and the Windows installer with the updated bzip2 at: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-w32cli-1.4.11rc1.exe (1607k) ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-w32cli-1.4.11rc1.exe.sig SHA-1 checksums are: 56a9da797bf17f6447f1243ac682d4e7b91e24f0 gnupg-1.4.11rc1.tar.bz2 c6f421a7874c734d1d66bd756d1a5ee3cd5a44ee gnupg-w32cli-1.4.11rc1.exe Please check it out and report problems to this list. Note that translations are not completely up to date. We are also preparing a new version of Gpg4win; this may take a couple of days. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Sep 24 10:13:27 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Sep 2010 10:13:27 +0200 Subject: OT: Padding Oracle Attacks In-Reply-To: (Nicholas Cole's message of "Mon, 20 Sep 2010 22:13:04 +0100") References: Message-ID: <87lj6r4l08.fsf@vigenere.g10code.de> On Mon, 20 Sep 2010 23:13, nicholas.cole at gmail.com said: > It isn't clear to me after reading that whether this kind of attack would > be thwarted by the MDC or not. First of all you can't mount a padding attack on an OpenPGP ciphertext because CFB mode is used which does not need any padding by design. The MDC was introduced to detect message manipulation for encrypted-only messages. The more common case is to sign and encrypt a message which adds an explicit manipulation detection and would not need for an MDC; we use it anyway. Thwarting oracle attacks is never easy but there are some simple rules you can follow: Do not return detailed error codes, batch up requests and responses, detect the use of your service as an oracle (similar to DoS prevention). For OpenPGP this is in fact all easy doable because it is not an online protocol. If you try to use it with an online protocol (i.e. through CGIs) you need to take the above precautions. In any case we tried to make it hard to use GPG as an oracle. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rickard.bellgrim at iis.se Fri Sep 24 16:05:31 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 24 Sep 2010 16:05:31 +0200 Subject: Scute - pkcs11.h is outdated Message-ID: <8E4035E3-0A58-4038-9E34-88B693C9440D@iis.se> Hi The PKCS#11 header file you are using in the Scute project is missing the latest amendments for PKCS#11 v2.20. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/otp-pkcs11.h ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/ct-kip.h ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20a3.h And the following defines was also missing They were included in the original v2.20: #define CKK_CAST5 (0x18) #define CKM_DES_OFB64 (0x150) #define CKM_DES_OFB8 (0x151) #define CKM_DES_CFB64 (0x152) #define CKM_DES_CFB8 (0x153) #define CKM_TLS_PRF (0x378) #define CKM_SHA256_KEY_DERIVATION (0x393) #define CKM_SHA384_KEY_DERIVATION (0x394) #define CKM_SHA512_KEY_DERIVATION (0x395) #define CKM_WTLS_PRE_MASTER_KEY_GEN (0x3d0) #define CKM_WTLS_MASTER_KEY_DERIVE (0x3d1) #define CKM_WTLS_MASTER_KEY_DERVIE_DH_ECC (0x3d2) #define CKM_WTLS_PRF (0x3d3) #define CKM_WTLS_SERVER_KEY_AND_MAC_DERIVE (0x3d4) #define CKM_WTLS_CLIENT_KEY_AND_MAC_DERIVE (0x3d5) #define CKM_CMS_SIG (0x500) #define CKM_BLOWFISH_KEY_GEN (0x1090) #define CKM_BLOWFISH_CBC (0x1091) #define CKM_TWOFISH_KEY_GEN (0x1092) #define CKM_TWOFISH_CBC (0x1093) #define CKM_DES_ECB_ENCRYPT_DATA (0x1100) #define CKM_DES_CBC_ENCRYPT_DATA (0x1101) #define CKM_DES3_ECB_ENCRYPT_DATA (0x1102) #define CKM_DES3_CBC_ENCRYPT_DATA (0x1103) #define CKM_AES_ECB_ENCRYPT_DATA (0x1104) #define CKM_AES_CBC_ENCRYPT_DATA (0x1105) Any plans on updating the header file? Thanks // Rickard From alex at willner.ws Fri Sep 24 18:50:01 2010 From: alex at willner.ws (Alexander Willner) Date: Fri, 24 Sep 2010 18:50:01 +0200 Subject: GnuPG / OpenPGP implementation in JavaScript Message-ID: Hi there, do you know any JavaScript library that allows to decrypt OpenPGP data? Herbert Hanewinkel has developed an OpenPGP message encryption demo[1] in 2005 but I cannot find any resource on the web that allows me to decrypt a message again. Best regards, Alex [1] http://www.hanewin.net/encrypt/ From sms at antinode.info Fri Sep 24 22:14:57 2010 From: sms at antinode.info (Steven M. Schweda) Date: Fri, 24 Sep 2010 15:14:57 -0500 (CDT) Subject: 1.4.11 release candidate (was: Overflow bug in bzip2) Message-ID: <10092415145768_202004A6@antinode.info> From: Werner Koch > GnuPG 1.4.11 release candidate 1 is availabale at > > ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.11rc1.tar.bz2 (3360k) Any chance of inserting some should-be-harmless VMS-related changes into the main code stream at some point (possibly here)? The change from "readonly" to "read_only" in a couple of places was appreciated, but there are still about twenty other source files which need some changes for use on VMS (plus a whole bunch of VMS-only source and builder files). Some of the differences seem (to me) to be general improvements, like making the #include's of and in "g10/passphrase.c" conditional on ENABLE_AGENT_SUPPORT instead of (only) "!defined(HAVE_DOSISH_SYSTEM) && !defined(__riscos__)". And, in config.h.in, this: # ifdef __VMS # define GNUPG_HOMEDIR "/SYS\$LOGIN/gnupg" was a nice gesture, but no one on VMS needs or wants a backslash escape for that dollar sign in this context. I haven't packaged a complete 1.4.11rc1 source kit, but I've gone through the 1.4.11rc1 code and re-made the usual changes, so if there is any interest in merging any of these changes, please let me know how to proceed. Older stuff (not much different), including the change notes, should be available in the usual place: http://antinode.info/dec/sw/gnupg.html ------------------------------------------------------------------------ Steven M. Schweda sms at antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 From flameeyes at gmail.com Mon Sep 27 19:04:06 2010 From: flameeyes at gmail.com (Diego Elio =?ISO-8859-1?Q?Petten=F2?=) Date: Mon, 27 Sep 2010 19:04:06 +0200 Subject: [PATCH] Allow SHA2 hash functions on gnupg 2 with scdaemon Message-ID: <1285607046.13141.23.camel@yamato.local> Hi, I'm attaching a patch that implement support for the SHA2 hash functions in GnuPG 2 when using scdaemon. A similar issue was reported and fixed (although in a different, IMHO less optimal, way) in early 2010 [1] but the same issue held true for GnuPG 2. Without this patch, if ~/.gnupg/gpg.conf contains these lines: personal-digest-preferences SHA256 cert-digest-algo SHA256 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed then a sign action would report this: gpg: checking created signature failed: Bad signature gpg: signing failed: Bad signature gpg: [stdin]: clearsign failed: Bad signature after applying the patch.. well, this email is signed, I hope :) As it is, it applies fine over 2.0.16 and svn branch. HTH, [1] http://www.gossamer-threads.com/lists/gnupg/users/51293 -- Diego Elio Petten? ? ?Flameeyes? http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-2.0.16-opengpgv2-sha2.patch Type: text/x-patch Size: 1291 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From wk at gnupg.org Tue Sep 28 10:22:36 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Sep 2010 10:22:36 +0200 Subject: [PATCH] Allow SHA2 hash functions on gnupg 2 with scdaemon In-Reply-To: <1285607046.13141.23.camel@yamato.local> ("Diego Elio =?utf-8?Q?Petten=C3=B2=22's?= message of "Mon, 27 Sep 2010 19:04:06 +0200") References: <1285607046.13141.23.camel@yamato.local> Message-ID: <87aan22s6r.fsf@vigenere.g10code.de> On Mon, 27 Sep 2010 19:04, flameeyes at gmail.com said: > I'm attaching a patch that implement support for the SHA2 hash functions > in GnuPG 2 when using scdaemon. I just commited a similar change. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 28 12:15:52 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Sep 2010 12:15:52 +0200 Subject: 1.4.11 release candidate In-Reply-To: <10092415145768_202004A6@antinode.info> (Steven M. Schweda's message of "Fri, 24 Sep 2010 15:14:57 -0500 (CDT)") References: <10092415145768_202004A6@antinode.info> Message-ID: <8762xq2mxz.fsf@vigenere.g10code.de> On Fri, 24 Sep 2010 22:14, sms at antinode.info said: > improvements, like making the #include's of and > in "g10/passphrase.c" conditional on ENABLE_AGENT_SUPPORT > instead of (only) "!defined(HAVE_DOSISH_SYSTEM) && I am not sure whetehr this is required at all; in any case I idefed them on ENABLE_AGENT_SUPPORT. > # define GNUPG_HOMEDIR "/SYS\$LOGIN/gnupg" Changed to # define GNUPG_HOMEDIR "/SYS$LOGIN/gnupg" > through the 1.4.11rc1 code and re-made the usual changes, so if there is > any interest in merging any of these changes, please let me know how to > proceed. Older stuff (not much different), including the change notes, I went over the diffs from 1.4.10b and hopefully applied all of the *.[ch] changes. I have no way to check them. Please let me know if I missed something. (svn rev5425 in branches/STABLE-BRANCH-1-4). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From flameeyes at gmail.com Tue Sep 28 16:25:34 2010 From: flameeyes at gmail.com (Diego Elio =?ISO-8859-1?Q?Petten=F2?=) Date: Tue, 28 Sep 2010 16:25:34 +0200 Subject: [PATCH] Allow SHA2 hash functions on gnupg 2 with scdaemon In-Reply-To: <87aan22s6r.fsf@vigenere.g10code.de> References: <1285607046.13141.23.camel@yamato.local> <87aan22s6r.fsf@vigenere.g10code.de> Message-ID: <1285683934.13141.37.camel@yamato.local> Il giorno mar, 28/09/2010 alle 10.22 +0200, Werner Koch ha scritto: > I just commited a similar change. > Thanks, but it's broken, the original (and my version) had a trailing whitespace on the --hash parameter strings, your commit doesn't have those so it ends up mangling the PKSIGN commandline: scdaemon[32606.7] DBG: <- PKSIGN --hash=sha256XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX scdaemon[32606.7] DBG: -> ERR 100663576 IPC parameter error - invalid hash algorithm > -- Diego Elio Petten? ? ?Flameeyes? http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ From dkg at fifthhorseman.net Tue Sep 28 19:23:42 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 28 Sep 2010 13:23:42 -0400 Subject: DSA keys limited to 3072 bits in GnuPG -- should have harder failure mode? Message-ID: <4CA2249E.4030900@fifthhorseman.net> hi folks-- in writing up a little benchmarking script, i noticed that DSA keys are limited to 3072 bits max. i don't see a need to do more than that myself (i just wanted to have some comparison figures), but i was surprised to find that gpg just went ahead and created a smaller key than requested, instead of failing outright. printf 'Key-Type: DSA\nKey-Length: 4096\nName-Real: test\n' | \ gpg --batch --gen-key produces the warning message: gpg: keysize invalid; using 3072 bits i understand gnupg needing to make things slightly stronger than the user requested. But it seems odd that GnuPG would go ahead in a weaker mode than requested by the user. shouldn't there be some sort of harder failure? The attached patch is a proposal to fail hard in this situation. Hope this is useful! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: hard-fail-on-unsupported-DSA-size.patch Type: text/x-diff Size: 470 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Sep 29 10:36:59 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Sep 2010 10:36:59 +0200 Subject: [PATCH] Allow SHA2 hash functions on gnupg 2 with scdaemon In-Reply-To: <1285683934.13141.37.camel@yamato.local> ("Diego Elio =?utf-8?Q?Petten=C3=B2=22's?= message of "Tue, 28 Sep 2010 16:25:34 +0200") References: <1285607046.13141.23.camel@yamato.local> <87aan22s6r.fsf@vigenere.g10code.de> <1285683934.13141.37.camel@yamato.local> Message-ID: <87lj6l0wus.fsf@vigenere.g10code.de> On Tue, 28 Sep 2010 16:25, flameeyes at gmail.com said: > Thanks, but it's broken, the original (and my version) had a trailing > whitespace on the --hash parameter strings, your commit doesn't have Fixed. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Sep 29 10:44:31 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Sep 2010 10:44:31 +0200 Subject: DSA keys limited to 3072 bits in GnuPG -- should have harder failure mode? In-Reply-To: <4CA2249E.4030900@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 28 Sep 2010 13:23:42 -0400") References: <4CA2249E.4030900@fifthhorseman.net> Message-ID: <87hbh90wi7.fsf@vigenere.g10code.de> On Tue, 28 Sep 2010 19:23, dkg at fifthhorseman.net said: > in writing up a little benchmarking script, i noticed that DSA keys are > limited to 3072 bits max. That is per FIPS 186-3. > The attached patch is a proposal to fail hard in this situation. Which would break a couple of frontends. This also allows us to silently allow larger keys once it has been defined - despite that nobody will ever use DSA keys > 3072. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Sep 29 16:33:36 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 29 Sep 2010 10:33:36 -0400 Subject: DSA keys limited to 3072 bits in GnuPG -- should have harder failure mode? In-Reply-To: <87hbh90wi7.fsf@vigenere.g10code.de> References: <4CA2249E.4030900@fifthhorseman.net> <87hbh90wi7.fsf@vigenere.g10code.de> Message-ID: <4CA34E40.5010104@fifthhorseman.net> On 09/29/2010 04:44 AM, Werner Koch wrote: > On Tue, 28 Sep 2010 19:23, dkg at fifthhorseman.net said: > >> in writing up a little benchmarking script, i noticed that DSA keys are >> limited to 3072 bits max. > > That is per FIPS 186-3. yup, understood. >> The attached patch is a proposal to fail hard in this situation. > > Which would break a couple of frontends. frontends which currently silently fail to meet their users' requests and proceed anyway? > This also allows us to > silently allow larger keys once it has been defined at that point, you would presumably move the upper limit in the same lines affected by the patch. > - despite that > nobody will ever use DSA keys > 3072. :) So why not explicitly fail when people ask for them? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: