From ueno at unixuser.org Mon Oct 3 04:57:23 2011 From: ueno at unixuser.org (Daiki Ueno) Date: Mon, 03 Oct 2011 11:57:23 +0900 Subject: GPGME Ruby binding 2.0.0 released Message-ID: Hi, I usually don't announce the releases here, but I do this time since the latest version 2.0.0 is a major overhaul of the API from 1.x series. It also adopts a modern development toolset including bundler, minitest, and yard. Credit must go to Albert Llop for making the rework. Installation: $ gem install gpgme Documentation: http://rdoc.info/gems/gpgme Source code: https://github.com/ueno/ruby-gpgme Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From albrecht.dress at arcor.de Tue Oct 4 21:19:28 2011 From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Tue, 04 Oct 2011 21:19:28 +0200 Subject: Q: gpgsm says "Unsupported certificate" Message-ID: <1317755969.2273.1@antares> Hi all, a while ago, I added gpg and gpgsm support to the MUA balsa (see ), building on top of gpgme. One user asked why a s/mime signed mail in Evolution is marked as "good", whereas gpgme (from gpgsm) and in turn balsa reports the same signature as having a GPGME_VALIDITY_UNKNOWN validity. Using the same code, all my trusted certs report GPGME_VALIDITY_FULL, so unfortunately, I'm lost here... The gpgsm log (activated via the conf file reports: ----8<------------------------------------------------------------- DBG: gcry_pk_verify: Success root certificate is good DBG: connection to agent established DBG: gcry_pk_verify: Success checking the trust list failed: Unsupported certificate validation model used: shell invalid certification chain: Unsupported certificate enabled debug flags: x509 mpi crypto memory cache memstat hashing assuan ----8<------------------------------------------------------------- The certificate chain seems to be present, as 'gpgsm --list-chain' reports ----8<------------------------------------------------------------- gpgsm: enabled debug flags: x509 mpi crypto memory cache memstat hashing assuan /home/pawsa/.gnupg/pubring.kbx ------------------------------ ID: 0x7B5AAEE8 S/N: 0726F0 Issuer: /CN=Certum Level IV CA/OU=Certum Certification Authority/O=Unizeto Technologies S.A./C=PL Subject: /CN=Idea Bank S.A./OU=IT/O=IdeaBank/L=Warszawa/ST=mazowieckie/C=PL/EMail=kontakt at ideabank.pl aka: kontakt at ideabank.pl validity: 2010-12-09 12:00:26 through 2012-12-09 12:00:26 key type: 2048 bit RSA key usage: digitalSignature nonRepudiation keyEncipherment dataEncipherment ext key usage: clientAuth (suggested), emailProtection (suggested) policies: 1.2.616.1.113527.2.2.4:N: fingerprint: FB:1E:3E:EA:76:D9:FF:1B:B6:7E:A6:A8:C2:1F:3E:49:7B:5A:AE:E8 Certified by ID: 0xFFFFFFFF9491906A S/N: 047A54 Issuer: /CN=Certum CA/O=Unizeto Sp. z o.o./C=PL Subject: /CN=Certum Level IV CA/OU=Certum Certification Authority/O=Unizeto Technologies S.A./C=PL validity: 2009-03-03 12:54:25 through 2024-03-03 12:54:25 key type: 2048 bit RSA key usage: certSign crlSign policies: 2.5.29.32.0:N: chain length: unlimited fingerprint: 70:7C:9A:C5:3A:B2:3D:6E:39:63:61:DA:75:27:48:3A:94:91:90:6A Certified by ID: 0x51B18118 S/N: 010020 Issuer: /CN=Certum CA/O=Unizeto Sp. z o.o./C=PL Subject: /CN=Certum CA/O=Unizeto Sp. z o.o./C=PL validity: 2002-06-11 10:46:39 through 2027-06-11 10:46:39 key type: 2048 bit RSA chain length: unlimited fingerprint: 62:52:DC:40:F7:11:43:A2:2F:DE:9E:F7:34:8E:06:42:51:B1:81:18 random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 secmem usage: 0/16384 bytes in 0 blocks ----8<------------------------------------------------------------- Any idea what goes wrong here? Thanks in advance, Albrecht. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From wk at gnupg.org Wed Oct 5 11:54:56 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Oct 2011 11:54:56 +0200 Subject: Q: gpgsm says "Unsupported certificate" In-Reply-To: <1317755969.2273.1@antares> ("Albrecht =?utf-8?Q?Dre=C3=9F=22?= =?utf-8?Q?'s?= message of "Tue, 04 Oct 2011 21:19:28 +0200") References: <1317755969.2273.1@antares> Message-ID: <8739f7g3v3.fsf@vigenere.g10code.de> On Tue, 4 Oct 2011 21:19, albrecht.dress at arcor.de said: > The certificate chain seems to be present, as 'gpgsm --list-chain' reports Run gpgsm --list-chain --with-validation To disable CRL checks add --disable-crl-checks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From albrecht.dress at arcor.de Wed Oct 5 22:05:35 2011 From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Wed, 05 Oct 2011 22:05:35 +0200 Subject: Q: gpgsm says "Unsupported certificate" In-Reply-To: <8739f7g3v3.fsf@vigenere.g10code.de> (from wk@gnupg.org on Wed Oct 5 11:54:56 2011) References: <1317755969.2273.1@antares> <8739f7g3v3.fsf@vigenere.g10code.de> Message-ID: <1317845135.4633.6@antares> Hi Werner: thanks for your reply! Am 05.10.11 11:54 schrieb(en) Werner Koch: > On Tue, 4 Oct 2011 21:19, albrecht.dress at arcor.de said: > > > The certificate chain seems to be present, as 'gpgsm --list-chain' reports > > Run > > gpgsm --list-chain --with-validation > > To disable CRL checks add --disable-crl-checks. I forwarded your message to the user, and the resulting log is attached. Thanks, Albrecht. -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgsm.log Type: text/x-log Size: 13084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From wk at gnupg.org Thu Oct 6 14:03:24 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Oct 2011 14:03:24 +0200 Subject: Q: gpgsm says "Unsupported certificate" In-Reply-To: <1317845135.4633.6@antares> ("Albrecht =?utf-8?Q?Dre=C3=9F=22?= =?utf-8?Q?'s?= message of "Wed, 05 Oct 2011 22:05:35 +0200") References: <1317755969.2273.1@antares> <8739f7g3v3.fsf@vigenere.g10code.de> <1317845135.4633.6@antares> Message-ID: <878voye38z.fsf@vigenere.g10code.de> Hi, given that you get the "Unsupported certifciate" error on all certificates and that you don't see any more diagnostics, the problem is in dirmngr: log_error (_("critical certificate extension %s is not supported"), oid); rc = gpg_error (GPG_ERR_UNSUPPORTED_CERT); I guess we should rework some diagnostics to also include the error source in the text, so that you would seen: [certificate is bad: Unsupported certificate (dirmngr)] To workwround this problem you may use a dirmngr option: @item --ignore-cert-extension @var{oid} @opindex ignore-cert-extension Add @var{oid} to the list of ignored certificate extensions. The @var{oid} is expected to be in dotted decimal form, like @code{2.5.29.3}. This option may be used more than once. Critical flagged certificate extensions matching one of the OIDs in the list are treated as if they are actually handled and thus the certificate won't be rejected due to an unknown critical extension. Use this option with care because extensions are usually flagged as critical for a reason. If you enable a dirmngr log file wou will notice the error shown above which includes the OID of the extension. Add this extension to /etc/dimngr/dirmngr.conf (if run as system services) or ~/.gnupg/dirmngr.conf (if run under user control). Does this help? BTW, to get a more detailed view of a certifciate, you may use gpgsm --dump-cert USER_ID_ETC Note that the dirmngr may use certificates which are not in GPGSM's certificate store. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Oct 6 14:13:26 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Oct 2011 14:13:26 +0200 Subject: GPGME Ruby binding 2.0.0 released In-Reply-To: (Daiki Ueno's message of "Mon, 03 Oct 2011 11:57:23 +0900") References: Message-ID: <874nzme2s9.fsf@vigenere.g10code.de> On Mon, 3 Oct 2011 04:57, ueno at unixuser.org said: > https://github.com/ueno/ruby-gpgme Shall we add a pointer to this at gnupg.org? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Thu Oct 6 17:35:21 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 6 Oct 2011 17:35:21 +0200 Subject: GPGME Ruby binding 2.0.0 released In-Reply-To: <874nzme2s9.fsf@vigenere.g10code.de> References: <874nzme2s9.fsf@vigenere.g10code.de> Message-ID: <201110061735.25795.bernhard@intevation.de> Am Thursday, 6. October 2011 14:13:26 schrieb Werner Koch: > On Mon, ?3 Oct 2011 04:57, ueno at unixuser.org said: > > https://github.com/ueno/ruby-gpgme > > Shall we add a pointer to this at gnupg.org? Sure, why not? :) -- Managing Director + Owner: www.Intevation.net <- A Free Software Company Kolabsys.com: Board Member FSFE.org: Founding GA Member 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 ott at mirix.org Fri Oct 7 22:51:37 2011 From: ott at mirix.org (Matthias-Christian Ott) Date: Fri, 7 Oct 2011 22:51:37 +0200 Subject: [PATCH] Support Cherry SmartTerminal ST-2000 Message-ID: <1318020697-2070-1-git-send-email-ott@mirix.org> --- scd/ccid-driver.c | 16 ++++++++++------ 1 files changed, 10 insertions(+), 6 deletions(-) diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index 8c362d7..4ed909b 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -1135,17 +1135,20 @@ scan_or_find_usb_device (int scan_mode, for (set_no=0; set_no < interface->num_altsetting; set_no++) { ifcdesc = (interface->altsetting + set_no); - /* The second condition is for older SCM SPR 532 who did - not know about the assigned CCID class. Instead of - trying to interpret the strings we simply check the - product ID. */ + /* The second condition is for older SCM SPR 532 and Cherry + SmartTerminal ST-2000 who did not know about the assigned + CCID class. Instead of trying to interpret the strings + we simply check the product ID. */ if (ifcdesc && ifcdesc->extra && ((ifcdesc->bInterfaceClass == 11 && ifcdesc->bInterfaceSubClass == 0 && ifcdesc->bInterfaceProtocol == 0) || (ifcdesc->bInterfaceClass == 255 && dev->descriptor.idVendor == VENDOR_SCM - && dev->descriptor.idProduct == 0xe003))) + && dev->descriptor.idProduct == 0xe003) + || (ifcdesc->bInterfaceClass == 255 + && dev->descriptor.idVendor == VENDOR_CHERRY + && dev->descriptor.idProduct == 0x003e))) { idev = usb_open (dev); if (!idev) @@ -3080,7 +3083,8 @@ ccid_transceive_secure (ccid_driver_t handle, Lc byte to the APDU. It seems that it will be replaced with the actual length instead of being appended before the APDU is send to the card. */ - cherry_mode = 1; + if (handle->id_product = 0x003e) + cherry_mode = 1; break; default: return CCID_DRIVER_ERR_NOT_SUPPORTED; -- 1.7.6.3 From ott at mirix.org Fri Oct 7 22:58:35 2011 From: ott at mirix.org (Matthias-Christian Ott) Date: Fri, 7 Oct 2011 22:58:35 +0200 Subject: [PATCH] Support Cherry SmartTerminal ST-2000 Message-ID: <1318021115-2231-1-git-send-email-ott@mirix.org> --- scd/ccid-driver.c | 16 ++++++++++------ 1 files changed, 10 insertions(+), 6 deletions(-) diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index 8c362d7..b0c403b 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -1135,17 +1135,20 @@ scan_or_find_usb_device (int scan_mode, for (set_no=0; set_no < interface->num_altsetting; set_no++) { ifcdesc = (interface->altsetting + set_no); - /* The second condition is for older SCM SPR 532 who did - not know about the assigned CCID class. Instead of - trying to interpret the strings we simply check the - product ID. */ + /* The second condition is for older SCM SPR 532 and Cherry + SmartTerminal ST-2000 who did not know about the assigned + CCID class. Instead of trying to interpret the strings + we simply check the product ID. */ if (ifcdesc && ifcdesc->extra && ((ifcdesc->bInterfaceClass == 11 && ifcdesc->bInterfaceSubClass == 0 && ifcdesc->bInterfaceProtocol == 0) || (ifcdesc->bInterfaceClass == 255 && dev->descriptor.idVendor == VENDOR_SCM - && dev->descriptor.idProduct == 0xe003))) + && dev->descriptor.idProduct == 0xe003) + || (ifcdesc->bInterfaceClass == 255 + && dev->descriptor.idVendor == VENDOR_CHERRY + && dev->descriptor.idProduct == 0x003e))) { idev = usb_open (dev); if (!idev) @@ -3080,7 +3083,8 @@ ccid_transceive_secure (ccid_driver_t handle, Lc byte to the APDU. It seems that it will be replaced with the actual length instead of being appended before the APDU is send to the card. */ - cherry_mode = 1; + if (handle->id_product != 0x003e) + cherry_mode = 1; break; default: return CCID_DRIVER_ERR_NOT_SUPPORTED; -- 1.7.6.3 From jeanjacquesbrucker at gmail.com Mon Oct 10 00:36:31 2011 From: jeanjacquesbrucker at gmail.com (Jbar) Date: Mon, 10 Oct 2011 00:36:31 +0200 Subject: convert .asc to .gpg (and eventually vice-versa) Message-ID: <201110100036.38789.jeanjacquesbrucker@gmail.com> Hi, It is maybe a dumb question, but I don't have found an easy way to convert a signed message from .asc to a .gpg ? I have to send signed message trough text-only channel, but i would like to store only binary version to save disk space. (I have to keep the signature with the message) Should I uuencode .gpg message before to send it through the text-only channel, or is there a (easy) way to convert .asc to .gpg (and also .gpg to .asc) ? Thanks a lot folks Jean-Jacques. -------------- 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 jerome at jeromebaum.com Mon Oct 10 01:42:21 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Mon, 10 Oct 2011 01:42:21 +0200 Subject: convert .asc to .gpg (and eventually vice-versa) In-Reply-To: <201110100036.38789.jeanjacquesbrucker@gmail.com> References: <201110100036.38789.jeanjacquesbrucker@gmail.com> Message-ID: <4E92315D.8030109@jeromebaum.com> On 2011-10-10 00:36, Jbar wrote: > Hi, It is maybe a dumb question, but I don't have found an easy way to convert a signed message from .asc to a .gpg ? > Should I uuencode .gpg message before to send it through the text-only channel, or is there a (easy) way to convert .asc to .gpg > (and also .gpg to .asc) ? $ echo foo | gpg -aer jerome - | gpg --list-only --list-packets gpg: jerome: skipped: public key already present :pubkey enc packet: version 3, algo 1, keyid 0000000000000000 data: [2046 bits] :encrypted data packet: length: 63 mdc_method: 2 $ echo foo | gpg -aer jerome - | sed -e '1d;$d' | openssl base64 -d | gpg --list-only --list-packets gpg: jerome: skipped: public key already present :pubkey enc packet: version 3, algo 1, keyid 0000000000000000 data: [2048 bits] :encrypted data packet: length: 63 mdc_method: 2 So you should be fine if you just remove the first and last lines ("-----...") and base64-decode. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA From dshaw at jabberwocky.com Mon Oct 10 03:06:01 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 9 Oct 2011 21:06:01 -0400 Subject: convert .asc to .gpg (and eventually vice-versa) In-Reply-To: <201110100036.38789.jeanjacquesbrucker@gmail.com> References: <201110100036.38789.jeanjacquesbrucker@gmail.com> Message-ID: On Oct 9, 2011, at 6:36 PM, Jbar wrote: > Hi, It is maybe a dumb question, but I don't have found an easy way to convert a signed message from .asc to a .gpg ? > > I have to send signed message trough text-only channel, but i would like to store only binary version to save disk space. (I have > to keep the signature with the message) > > Should I uuencode .gpg message before to send it through the text-only channel, or is there a (easy) way to convert .asc to .gpg > (and also .gpg to .asc) ? "gpg --dearmor the-asc-file.asc" will convert from .asc to .gpg To go from .gpg to .asc is a little trickier since it doesn't know what sort of message it is (that is, it could be a public key, an encrypted or signed message, a detached signature, etc). In your case you say it's a signed message so that's a "PGP MESSAGE", so you can do it with "gpg --enarmor the-gpg-file.gpg" and then edit the file and change "BEGIN PGP ARMORED FILE" to "BEGIN PGP MESSAGE" at the top and a similar change at the end. Or assuming you have sed handy you could do something like: cat the-gpg-file.gpg | gpg --enarmor | sed 's|ARMORED FILE|MESSAGE|' > my-new-asc-file.asc David From jeanjacquesbrucker at gmail.com Mon Oct 10 15:16:28 2011 From: jeanjacquesbrucker at gmail.com (Jean-Jacques Brucker) Date: Mon, 10 Oct 2011 15:16:28 +0200 Subject: convert .asc to .gpg (and eventually vice-versa) In-Reply-To: References: <201110100036.38789.jeanjacquesbrucker@gmail.com> Message-ID: Perfect, Thx a lot. 2011/10/10 David Shaw : > On Oct 9, 2011, at 6:36 PM, Jbar wrote: > >> Hi, It is maybe a dumb question, but I don't have found an easy way to convert a signed message from .asc to a .gpg ? >> >> I have to send signed message trough text-only channel, but i would like to store only binary version to save disk space. (I have >> to keep the signature with the message) >> >> Should I uuencode .gpg message before to send it through the text-only channel, or is there a (easy) way to convert .asc to .gpg >> (and also .gpg to .asc) ? > > "gpg --dearmor the-asc-file.asc" will convert from .asc to .gpg > > To go from .gpg to .asc is a little trickier since it doesn't know what sort of message it is (that is, it could be a public key, an encrypted or signed message, a detached signature, etc). ?In your case you say it's a signed message so that's a "PGP MESSAGE", so you can do it with > "gpg --enarmor the-gpg-file.gpg" and then edit the file and change "BEGIN PGP ARMORED FILE" to "BEGIN PGP MESSAGE" at the top and a similar change at the end. ?Or assuming you have sed handy you could do something like: > > cat the-gpg-file.gpg | gpg --enarmor | sed 's|ARMORED FILE|MESSAGE|' > my-new-asc-file.asc > > David > > From albrecht.dress at arcor.de Mon Oct 10 19:11:00 2011 From: albrecht.dress at arcor.de (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Mon, 10 Oct 2011 19:11:00 +0200 Subject: Q: gpgsm says "Unsupported certificate" In-Reply-To: <878voye38z.fsf@vigenere.g10code.de> (from wk@gnupg.org on Thu Oct 6 14:03:24 2011) References: <1317755969.2273.1@antares> <8739f7g3v3.fsf@vigenere.g10code.de> <1317845135.4633.6@antares> <878voye38z.fsf@vigenere.g10code.de> Message-ID: <1318266667.2076.0@antares> Hi Werner: Am 06.10.11 14:03 schrieb(en) Werner Koch: > given that you get the "Unsupported certifciate" error on all certificates and that you don't see any more diagnostics, the problem is in dirmngr: It turned out that the user did not have a gpg-agent running. Once he started it, he was asked whether he wants to trust the cert, and the verification process works as expected. Would be great if gpgme could provide a little more information about such situations (although I would fully agree if you said that there is no good reason why a session manager should *not* start the agent...). Thanks for your help, Albrecht. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From wk at gnupg.org Mon Oct 10 20:54:37 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 10 Oct 2011 20:54:37 +0200 Subject: The audit log (was: Q: gpgsm says "Unsupported certificate") In-Reply-To: <1318266667.2076.0@antares> ("Albrecht =?utf-8?Q?Dre=C3=9F=22?= =?utf-8?Q?'s?= message of "Mon, 10 Oct 2011 19:11:00 +0200") References: <1317755969.2273.1@antares> <8739f7g3v3.fsf@vigenere.g10code.de> <1317845135.4633.6@antares> <878voye38z.fsf@vigenere.g10code.de> <1318266667.2076.0@antares> Message-ID: <871uukad8y.fsf_-_@vigenere.g10code.de> On Mon, 10 Oct 2011 19:11, albrecht.dress at arcor.de said: > Would be great if gpgme could provide a little more information about such situations (although I would fully agree if you said that there is no good reason why a session manager should *not* start the agent...). Actually there is a way to display a more readable report on failures in gpgsm. gpgsm --audit-log audit.log .... or if you prefer a HTML formatted output, use --html-audit-log. Kmail shows this audit log if you hit the details button. Unfortunately this feature has never been documented, maybe because it is not yet complete and covers only a few error cases. GPGME provides this interface: /* Flags for the audit log functions. */ #define GPGME_AUDITLOG_HTML 1 #define GPGME_AUDITLOG_WITH_HELP 128 /* A dummy for now. */ /* Return the auditlog for the current session. This may be called after a successful or failed operation. If no audit log is available GPG_ERR_NO_DATA is returned. */ gpgme_error_t gpgme_op_getauditlog_start (gpgme_ctx_t ctx, gpgme_data_t output, unsigned int flags); gpgme_error_t gpgme_op_getauditlog (gpgme_ctx_t ctx, gpgme_data_t output, unsigned int flags); gpgme-tool supports this as well and it gives you an example on how to use it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri Oct 14 04:26:12 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 14 Oct 2011 11:26:12 +0900 Subject: Gnuk version 0.14 Message-ID: <4E979DC4.5010103@fsij.org> Hi, Gnuk version 0.14 is out. Gnuk is software implementation of a USB token for GNU Privacy Guard. Gnuk supports OpenPGP card protocol version 2, and it runs on STM32 processor. Highlight is (in gnuk-0.14/NEWS): * Random number generator change NeuG, Gniibe's True RNG implementation for STM32F103, has been integrated to Gnuk. It is not needed to put random number bytes (generated by host) to Token any more. * * * I think that Gnuk is stable enough now. Thus, I created a new branch for ECC support. http://www.gniibe.org/gitweb?p=gnuk.git;a=shortlog;h=refs/heads/ecc_p256 Currently, only ECC functions of NIST Curve P256 are there, not yet integrated to Gnuk. Computation of multiplication of EC point over GF(P256) (which is used for ECDH) takes 0.24 second, which is fast enough, I think. ECDSA is three times faster (0.08 sec) as we can take advantage of fix point (base point). This numbers are taken on STM32F103 at 72MHz with my current code (no processor specific tuning, just in plain C code). Besides, I am developing my own board for Gnuk / NeuG (I learn KiCAD in this summer). It's name is FST-01 (Flying Stone Tiny 01). If you like it, please vote for my project at: http://www.seeedstudio.com/wish/?p=783 Thanks in advance. -- From stefw at collabora.co.uk Fri Oct 14 07:49:52 2011 From: stefw at collabora.co.uk (Stef Walter) Date: Fri, 14 Oct 2011 07:49:52 +0200 Subject: GnuPG icons in vector form? Message-ID: <4E97CD80.5050302@collabora.co.uk> Anyone know where the GnuPG icons in vector form are? I'm redesigning seahorse, and I'd like to use the GnuPG icon in seahorse to represent the "Place" where gnupg keys come from. I'm interested in the vector form because the icon would be included in various sizes. ie: http://git.gnome.org/browse/gcr/tree/gcr/icons Cheers, Stef From wk at gnupg.org Fri Oct 14 11:10:35 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 14 Oct 2011 11:10:35 +0200 Subject: GnuPG icons in vector form? In-Reply-To: <4E97CD80.5050302@collabora.co.uk> (Stef Walter's message of "Fri, 14 Oct 2011 07:49:52 +0200") References: <4E97CD80.5050302@collabora.co.uk> Message-ID: <87k4886ir8.fsf@vigenere.g10code.de> On Fri, 14 Oct 2011 07:49, stefw at collabora.co.uk said: > Anyone know where the GnuPG icons in vector form are? I'm redesigning > seahorse, and I'd like to use the GnuPG icon in seahorse to represent > the "Place" where gnupg keys come from. As a command line utility GnuPG has no icons. GPA has a set of icons but I don't know whether there is vector format for them. Kleopatra has another set of icons and as KDE uses vectors, they should be available in SVG format. You find them in the oxygen repo. Below is an excerpt of the icons we install from oxygen for Kleopatra in Gpg4win; if that is of any help. Shalom-Salam, Werner ======= SetOutPath "$INSTDIR\share\icons\oxygen\128x128\actions" File ${prefix}/share/icons/oxygen/128x128/actions/application-exit.png File ${prefix}/share/icons/oxygen/128x128/actions/configure.png File ${prefix}/share/icons/oxygen/128x128/actions/dialog-ok-apply.png File ${prefix}/share/icons/oxygen/128x128/actions/dialog-ok.png File ${prefix}/share/icons/oxygen/128x128/actions/edit-find.png File ${prefix}/share/icons/oxygen/128x128/actions/go-bottom.png File ${prefix}/share/icons/oxygen/128x128/actions/go-down.png File ${prefix}/share/icons/oxygen/128x128/actions/go-first.png File ${prefix}/share/icons/oxygen/128x128/actions/go-last.png File ${prefix}/share/icons/oxygen/128x128/actions/go-next.png File ${prefix}/share/icons/oxygen/128x128/actions/go-previous.png File ${prefix}/share/icons/oxygen/128x128/actions/go-top.png File ${prefix}/share/icons/oxygen/128x128/actions/go-up.png File ${prefix}/share/icons/oxygen/128x128/actions/list-remove.png File ${prefix}/share/icons/oxygen/128x128/actions/tools-report-bug.png SetOutPath "$INSTDIR\share\icons\oxygen\128x128\apps" File ${prefix}/share/icons/oxygen/128x128/apps/kde.png SetOutPath "$INSTDIR\share\icons\oxygen\128x128\categories" File ${prefix}/share/icons/oxygen/128x128/categories/applications-graphics.png File ${prefix}/share/icons/oxygen/128x128/categories/preferences-system-network.png SetOutPath "$INSTDIR\share\icons\oxygen\128x128\devices" File ${prefix}/share/icons/oxygen/128x128/devices/secure-card.png SetOutPath "$INSTDIR\share\icons\oxygen\128x128\status" File ${prefix}/share/icons/oxygen/128x128/status/dialog-error.png File ${prefix}/share/icons/oxygen/128x128/status/dialog-information.png File ${prefix}/share/icons/oxygen/128x128/status/dialog-password.png File ${prefix}/share/icons/oxygen/128x128/status/dialog-warning.png File ${prefix}/share/icons/oxygen/128x128/status/security-high.png File ${prefix}/share/icons/oxygen/128x128/status/security-low.png File ${prefix}/share/icons/oxygen/128x128/status/security-medium.png SetOutPath "$INSTDIR\share\icons\oxygen\16x16\actions" File ${prefix}/share/icons/oxygen/16x16/actions/application-exit.png File ${prefix}/share/icons/oxygen/16x16/actions/arrow-down.png File ${prefix}/share/icons/oxygen/16x16/actions/arrow-up.png File ${prefix}/share/icons/oxygen/16x16/actions/configure-shortcuts.png File ${prefix}/share/icons/oxygen/16x16/actions/configure-toolbars.png File ${prefix}/share/icons/oxygen/16x16/actions/configure.png File ${prefix}/share/icons/oxygen/16x16/actions/dialog-cancel.png File ${prefix}/share/icons/oxygen/16x16/actions/dialog-close.png File ${prefix}/share/icons/oxygen/16x16/actions/dialog-ok-apply.png File ${prefix}/share/icons/oxygen/16x16/actions/dialog-ok.png File ${prefix}/share/icons/oxygen/16x16/actions/document-edit-decrypt-verify.png File ${prefix}/share/icons/oxygen/16x16/actions/document-edit-decrypt.png File ${prefix}/share/icons/oxygen/16x16/actions/document-edit-encrypt.png File ${prefix}/share/icons/oxygen/16x16/actions/document-edit-sign-encrypt.png File ${prefix}/share/icons/oxygen/16x16/actions/document-edit-sign.png File ${prefix}/share/icons/oxygen/16x16/actions/document-edit-verify.png File ${prefix}/share/icons/oxygen/16x16/actions/document-encrypt.png File ${prefix}/share/icons/oxygen/16x16/actions/document-open.png File ${prefix}/share/icons/oxygen/16x16/actions/document-print.png File ${prefix}/share/icons/oxygen/16x16/actions/document-revert.png File ${prefix}/share/icons/oxygen/16x16/actions/edit-clear-locationbar-rtl.png File ${prefix}/share/icons/oxygen/16x16/actions/edit-delete.png File ${prefix}/share/icons/oxygen/16x16/actions/edit-find.png File ${prefix}/share/icons/oxygen/16x16/actions/edit-redo.png File ${prefix}/share/icons/oxygen/16x16/actions/edit-rename.png File ${prefix}/share/icons/oxygen/16x16/actions/edit-undo.png File ${prefix}/share/icons/oxygen/16x16/actions/go-bottom.png File ${prefix}/share/icons/oxygen/16x16/actions/go-down.png File ${prefix}/share/icons/oxygen/16x16/actions/go-first.png File ${prefix}/share/icons/oxygen/16x16/actions/go-last.png File ${prefix}/share/icons/oxygen/16x16/actions/go-next.png File ${prefix}/share/icons/oxygen/16x16/actions/go-previous.png File ${prefix}/share/icons/oxygen/16x16/actions/go-top.png File ${prefix}/share/icons/oxygen/16x16/actions/go-up.png File ${prefix}/share/icons/oxygen/16x16/actions/help-contents.png File ${prefix}/share/icons/oxygen/16x16/actions/help-contextual.png File ${prefix}/share/icons/oxygen/16x16/actions/list-add.png File ${prefix}/share/icons/oxygen/16x16/actions/list-remove.png File ${prefix}/share/icons/oxygen/16x16/actions/process-stop.png File ${prefix}/share/icons/oxygen/16x16/actions/tab-close.png File ${prefix}/share/icons/oxygen/16x16/actions/tab-duplicate.png File ${prefix}/share/icons/oxygen/16x16/actions/tab-new-background.png File ${prefix}/share/icons/oxygen/16x16/actions/tools-report-bug.png File ${prefix}/share/icons/oxygen/16x16/actions/view-certificate-add.png File ${prefix}/share/icons/oxygen/16x16/actions/view-certificate-export-secret.png File ${prefix}/share/icons/oxygen/16x16/actions/view-certificate-export-server.png File ${prefix}/share/icons/oxygen/16x16/actions/view-certificate-export.png File ${prefix}/share/icons/oxygen/16x16/actions/view-certificate-import.png File ${prefix}/share/icons/oxygen/16x16/actions/view-certificate-server-configure.png File ${prefix}/share/icons/oxygen/16x16/actions/view-certificate-sign.png File ${prefix}/share/icons/oxygen/16x16/actions/view-refresh.png File ${prefix}/share/icons/oxygen/16x16/actions/window-close.png SetOutPath "$INSTDIR\share\icons\oxygen\16x16\animations" File ${prefix}/share/icons/oxygen/16x16/animations/process-working-kde.png SetOutPath "$INSTDIR\share\icons\oxygen\16x16\apps" File ${prefix}/share/icons/oxygen/16x16/apps/kde.png SetOutPath "$INSTDIR\share\icons\oxygen\16x16\categories" File ${prefix}/share/icons/oxygen/16x16/categories/applications-graphics.png File ${prefix}/share/icons/oxygen/16x16/categories/preferences-system-network.png SetOutPath "$INSTDIR\share\icons\oxygen\16x16\devices" File ${prefix}/share/icons/oxygen/16x16/devices/secure-card.png SetOutPath "$INSTDIR\share\icons\oxygen\16x16\status" File ${prefix}/share/icons/oxygen/16x16/status/dialog-error.png File ${prefix}/share/icons/oxygen/16x16/status/dialog-information.png File ${prefix}/share/icons/oxygen/16x16/status/dialog-password.png File ${prefix}/share/icons/oxygen/16x16/status/dialog-warning.png File ${prefix}/share/icons/oxygen/16x16/status/security-high.png File ${prefix}/share/icons/oxygen/16x16/status/security-low.png File ${prefix}/share/icons/oxygen/16x16/status/security-medium.png SetOutPath "$INSTDIR\share\icons\oxygen\22x22\actions" File ${prefix}/share/icons/oxygen/22x22/actions/application-exit.png File ${prefix}/share/icons/oxygen/22x22/actions/arrow-down.png File ${prefix}/share/icons/oxygen/22x22/actions/arrow-up.png File ${prefix}/share/icons/oxygen/22x22/actions/configure-shortcuts.png File ${prefix}/share/icons/oxygen/22x22/actions/configure-toolbars.png File ${prefix}/share/icons/oxygen/22x22/actions/configure.png File ${prefix}/share/icons/oxygen/22x22/actions/dialog-cancel.png File ${prefix}/share/icons/oxygen/22x22/actions/dialog-close.png File ${prefix}/share/icons/oxygen/22x22/actions/dialog-ok-apply.png File ${prefix}/share/icons/oxygen/22x22/actions/dialog-ok.png File ${prefix}/share/icons/oxygen/22x22/actions/document-edit-decrypt-verify.png File ${prefix}/share/icons/oxygen/22x22/actions/document-edit-decrypt.png File ${prefix}/share/icons/oxygen/22x22/actions/document-edit-encrypt.png File ${prefix}/share/icons/oxygen/22x22/actions/document-edit-sign-encrypt.png File ${prefix}/share/icons/oxygen/22x22/actions/document-edit-sign.png File ${prefix}/share/icons/oxygen/22x22/actions/document-edit-verify.png File ${prefix}/share/icons/oxygen/22x22/actions/document-encrypt.png File ${prefix}/share/icons/oxygen/22x22/actions/document-open.png File ${prefix}/share/icons/oxygen/22x22/actions/document-print.png File ${prefix}/share/icons/oxygen/22x22/actions/document-revert.png File ${prefix}/share/icons/oxygen/22x22/actions/edit-clear-locationbar-rtl.png File ${prefix}/share/icons/oxygen/22x22/actions/edit-delete.png File ${prefix}/share/icons/oxygen/22x22/actions/edit-find.png File ${prefix}/share/icons/oxygen/22x22/actions/edit-redo.png File ${prefix}/share/icons/oxygen/22x22/actions/edit-rename.png File ${prefix}/share/icons/oxygen/22x22/actions/edit-undo.png File ${prefix}/share/icons/oxygen/22x22/actions/go-bottom.png File ${prefix}/share/icons/oxygen/22x22/actions/go-down.png File ${prefix}/share/icons/oxygen/22x22/actions/go-first.png File ${prefix}/share/icons/oxygen/22x22/actions/go-last.png File ${prefix}/share/icons/oxygen/22x22/actions/go-next.png File ${prefix}/share/icons/oxygen/22x22/actions/go-previous.png File ${prefix}/share/icons/oxygen/22x22/actions/go-top.png File ${prefix}/share/icons/oxygen/22x22/actions/go-up.png File ${prefix}/share/icons/oxygen/22x22/actions/help-contents.png File ${prefix}/share/icons/oxygen/22x22/actions/help-contextual.png File ${prefix}/share/icons/oxygen/22x22/actions/list-add.png File ${prefix}/share/icons/oxygen/22x22/actions/list-remove.png File ${prefix}/share/icons/oxygen/22x22/actions/process-stop.png File ${prefix}/share/icons/oxygen/22x22/actions/tab-close.png File ${prefix}/share/icons/oxygen/22x22/actions/tab-duplicate.png File ${prefix}/share/icons/oxygen/22x22/actions/tab-new-background.png File ${prefix}/share/icons/oxygen/22x22/actions/tools-report-bug.png File ${prefix}/share/icons/oxygen/22x22/actions/view-certificate-add.png File ${prefix}/share/icons/oxygen/22x22/actions/view-certificate-export-secret.png File ${prefix}/share/icons/oxygen/22x22/actions/view-certificate-export-server.png File ${prefix}/share/icons/oxygen/22x22/actions/view-certificate-export.png File ${prefix}/share/icons/oxygen/22x22/actions/view-certificate-import.png File ${prefix}/share/icons/oxygen/22x22/actions/view-certificate-server-configure.png File ${prefix}/share/icons/oxygen/22x22/actions/view-certificate-sign.png File ${prefix}/share/icons/oxygen/22x22/actions/view-refresh.png File ${prefix}/share/icons/oxygen/22x22/actions/window-close.png SetOutPath "$INSTDIR\share\icons\oxygen\22x22\animations" File ${prefix}/share/icons/oxygen/22x22/animations/process-working-kde.png SetOutPath "$INSTDIR\share\icons\oxygen\22x22\apps" File ${prefix}/share/icons/oxygen/22x22/apps/kde.png SetOutPath "$INSTDIR\share\icons\oxygen\22x22\categories" File ${prefix}/share/icons/oxygen/22x22/categories/applications-graphics.png File ${prefix}/share/icons/oxygen/22x22/categories/preferences-system-network.png SetOutPath "$INSTDIR\share\icons\oxygen\22x22\devices" File ${prefix}/share/icons/oxygen/22x22/devices/secure-card.png SetOutPath "$INSTDIR\share\icons\oxygen\22x22\status" File ${prefix}/share/icons/oxygen/22x22/status/dialog-error.png File ${prefix}/share/icons/oxygen/22x22/status/dialog-information.png File ${prefix}/share/icons/oxygen/22x22/status/dialog-password.png File ${prefix}/share/icons/oxygen/22x22/status/dialog-warning.png File ${prefix}/share/icons/oxygen/22x22/status/security-high.png File ${prefix}/share/icons/oxygen/22x22/status/security-low.png File ${prefix}/share/icons/oxygen/22x22/status/security-medium.png SetOutPath "$INSTDIR\share\icons\oxygen\256x256\categories" File ${prefix}/share/icons/oxygen/256x256/categories/applications-graphics.png File ${prefix}/share/icons/oxygen/256x256/categories/preferences-system-network.png SetOutPath "$INSTDIR\share\icons\oxygen\256x256\devices" File ${prefix}/share/icons/oxygen/256x256/devices/secure-card.png SetOutPath "$INSTDIR\share\icons\oxygen\32x32\actions" File ${prefix}/share/icons/oxygen/32x32/actions/application-exit.png File ${prefix}/share/icons/oxygen/32x32/actions/arrow-down.png File ${prefix}/share/icons/oxygen/32x32/actions/arrow-up.png File ${prefix}/share/icons/oxygen/32x32/actions/configure-shortcuts.png File ${prefix}/share/icons/oxygen/32x32/actions/configure-toolbars.png File ${prefix}/share/icons/oxygen/32x32/actions/configure.png File ${prefix}/share/icons/oxygen/32x32/actions/dialog-cancel.png File ${prefix}/share/icons/oxygen/32x32/actions/dialog-close.png File ${prefix}/share/icons/oxygen/32x32/actions/dialog-ok-apply.png File ${prefix}/share/icons/oxygen/32x32/actions/dialog-ok.png File ${prefix}/share/icons/oxygen/32x32/actions/document-edit-decrypt-verify.png File ${prefix}/share/icons/oxygen/32x32/actions/document-edit-decrypt.png File ${prefix}/share/icons/oxygen/32x32/actions/document-edit-encrypt.png File ${prefix}/share/icons/oxygen/32x32/actions/document-edit-sign-encrypt.png File ${prefix}/share/icons/oxygen/32x32/actions/document-edit-sign.png File ${prefix}/share/icons/oxygen/32x32/actions/document-edit-verify.png File ${prefix}/share/icons/oxygen/32x32/actions/document-encrypt.png File ${prefix}/share/icons/oxygen/32x32/actions/document-open.png File ${prefix}/share/icons/oxygen/32x32/actions/document-print.png File ${prefix}/share/icons/oxygen/32x32/actions/document-revert.png File ${prefix}/share/icons/oxygen/32x32/actions/edit-clear-locationbar-rtl.png File ${prefix}/share/icons/oxygen/32x32/actions/edit-delete.png File ${prefix}/share/icons/oxygen/32x32/actions/edit-find.png File ${prefix}/share/icons/oxygen/32x32/actions/edit-redo.png File ${prefix}/share/icons/oxygen/32x32/actions/edit-rename.png File ${prefix}/share/icons/oxygen/32x32/actions/edit-undo.png File ${prefix}/share/icons/oxygen/32x32/actions/go-bottom.png File ${prefix}/share/icons/oxygen/32x32/actions/go-down.png File ${prefix}/share/icons/oxygen/32x32/actions/go-first.png File ${prefix}/share/icons/oxygen/32x32/actions/go-last.png File ${prefix}/share/icons/oxygen/32x32/actions/go-next.png File ${prefix}/share/icons/oxygen/32x32/actions/go-previous.png File ${prefix}/share/icons/oxygen/32x32/actions/go-top.png File ${prefix}/share/icons/oxygen/32x32/actions/go-up.png File ${prefix}/share/icons/oxygen/32x32/actions/help-contents.png File ${prefix}/share/icons/oxygen/32x32/actions/help-contextual.png File ${prefix}/share/icons/oxygen/32x32/actions/list-add.png File ${prefix}/share/icons/oxygen/32x32/actions/list-remove.png File ${prefix}/share/icons/oxygen/32x32/actions/process-stop.png File ${prefix}/share/icons/oxygen/32x32/actions/tab-close.png File ${prefix}/share/icons/oxygen/32x32/actions/tab-duplicate.png File ${prefix}/share/icons/oxygen/32x32/actions/tab-new-background.png File ${prefix}/share/icons/oxygen/32x32/actions/tools-report-bug.png File ${prefix}/share/icons/oxygen/32x32/actions/view-certificate-add.png File ${prefix}/share/icons/oxygen/32x32/actions/view-certificate-export-secret.png File ${prefix}/share/icons/oxygen/32x32/actions/view-certificate-export-server.png File ${prefix}/share/icons/oxygen/32x32/actions/view-certificate-export.png File ${prefix}/share/icons/oxygen/32x32/actions/view-certificate-import.png File ${prefix}/share/icons/oxygen/32x32/actions/view-certificate-server-configure.png File ${prefix}/share/icons/oxygen/32x32/actions/view-certificate-sign.png File ${prefix}/share/icons/oxygen/32x32/actions/view-refresh.png File ${prefix}/share/icons/oxygen/32x32/actions/window-close.png SetOutPath "$INSTDIR\share\icons\oxygen\32x32\animations" File ${prefix}/share/icons/oxygen/32x32/animations/process-working-kde.png SetOutPath "$INSTDIR\share\icons\oxygen\32x32\apps" File ${prefix}/share/icons/oxygen/32x32/apps/kde.png SetOutPath "$INSTDIR\share\icons\oxygen\32x32\categories" File ${prefix}/share/icons/oxygen/32x32/categories/applications-graphics.png File ${prefix}/share/icons/oxygen/32x32/categories/preferences-system-network.png SetOutPath "$INSTDIR\share\icons\oxygen\32x32\devices" File ${prefix}/share/icons/oxygen/32x32/devices/secure-card.png SetOutPath "$INSTDIR\share\icons\oxygen\32x32\status" File ${prefix}/share/icons/oxygen/32x32/status/dialog-error.png File ${prefix}/share/icons/oxygen/32x32/status/dialog-information.png File ${prefix}/share/icons/oxygen/32x32/status/dialog-password.png File ${prefix}/share/icons/oxygen/32x32/status/dialog-warning.png File ${prefix}/share/icons/oxygen/32x32/status/security-high.png File ${prefix}/share/icons/oxygen/32x32/status/security-low.png File ${prefix}/share/icons/oxygen/32x32/status/security-medium.png SetOutPath "$INSTDIR\share\icons\oxygen\48x48\actions" File ${prefix}/share/icons/oxygen/48x48/actions/application-exit.png File ${prefix}/share/icons/oxygen/48x48/actions/arrow-down.png File ${prefix}/share/icons/oxygen/48x48/actions/arrow-up.png File ${prefix}/share/icons/oxygen/48x48/actions/configure-shortcuts.png File ${prefix}/share/icons/oxygen/48x48/actions/configure-toolbars.png File ${prefix}/share/icons/oxygen/48x48/actions/configure.png File ${prefix}/share/icons/oxygen/48x48/actions/dialog-cancel.png File ${prefix}/share/icons/oxygen/48x48/actions/dialog-close.png File ${prefix}/share/icons/oxygen/48x48/actions/dialog-ok-apply.png File ${prefix}/share/icons/oxygen/48x48/actions/dialog-ok.png File ${prefix}/share/icons/oxygen/48x48/actions/document-edit-decrypt-verify.png File ${prefix}/share/icons/oxygen/48x48/actions/document-edit-decrypt.png File ${prefix}/share/icons/oxygen/48x48/actions/document-edit-encrypt.png File ${prefix}/share/icons/oxygen/48x48/actions/document-edit-sign-encrypt.png File ${prefix}/share/icons/oxygen/48x48/actions/document-edit-sign.png File ${prefix}/share/icons/oxygen/48x48/actions/document-edit-verify.png File ${prefix}/share/icons/oxygen/48x48/actions/document-encrypt.png File ${prefix}/share/icons/oxygen/48x48/actions/document-open.png File ${prefix}/share/icons/oxygen/48x48/actions/document-print.png File ${prefix}/share/icons/oxygen/48x48/actions/document-revert.png File ${prefix}/share/icons/oxygen/48x48/actions/edit-clear-locationbar-rtl.png File ${prefix}/share/icons/oxygen/48x48/actions/edit-delete.png File ${prefix}/share/icons/oxygen/48x48/actions/edit-find.png File ${prefix}/share/icons/oxygen/48x48/actions/edit-redo.png File ${prefix}/share/icons/oxygen/48x48/actions/edit-rename.png File ${prefix}/share/icons/oxygen/48x48/actions/edit-undo.png File ${prefix}/share/icons/oxygen/48x48/actions/go-bottom.png File ${prefix}/share/icons/oxygen/48x48/actions/go-down.png File ${prefix}/share/icons/oxygen/48x48/actions/go-first.png File ${prefix}/share/icons/oxygen/48x48/actions/go-last.png File ${prefix}/share/icons/oxygen/48x48/actions/go-next.png File ${prefix}/share/icons/oxygen/48x48/actions/go-previous.png File ${prefix}/share/icons/oxygen/48x48/actions/go-top.png File ${prefix}/share/icons/oxygen/48x48/actions/go-up.png File ${prefix}/share/icons/oxygen/48x48/actions/help-contents.png File ${prefix}/share/icons/oxygen/48x48/actions/help-contextual.png File ${prefix}/share/icons/oxygen/48x48/actions/list-add.png File ${prefix}/share/icons/oxygen/48x48/actions/list-remove.png File ${prefix}/share/icons/oxygen/48x48/actions/process-stop.png File ${prefix}/share/icons/oxygen/48x48/actions/tab-close.png File ${prefix}/share/icons/oxygen/48x48/actions/tab-duplicate.png File ${prefix}/share/icons/oxygen/48x48/actions/tab-new-background.png File ${prefix}/share/icons/oxygen/48x48/actions/tools-report-bug.png File ${prefix}/share/icons/oxygen/48x48/actions/view-certificate-add.png File ${prefix}/share/icons/oxygen/48x48/actions/view-certificate-export-secret.png File ${prefix}/share/icons/oxygen/48x48/actions/view-certificate-export-server.png File ${prefix}/share/icons/oxygen/48x48/actions/view-certificate-export.png File ${prefix}/share/icons/oxygen/48x48/actions/view-certificate-import.png File ${prefix}/share/icons/oxygen/48x48/actions/view-certificate-server-configure.png File ${prefix}/share/icons/oxygen/48x48/actions/view-certificate-sign.png File ${prefix}/share/icons/oxygen/48x48/actions/view-refresh.png File ${prefix}/share/icons/oxygen/48x48/actions/window-close.png SetOutPath "$INSTDIR\share\icons\oxygen\48x48\animations" File ${prefix}/share/icons/oxygen/48x48/animations/process-working-kde.png SetOutPath "$INSTDIR\share\icons\oxygen\48x48\apps" File ${prefix}/share/icons/oxygen/48x48/apps/kde.png SetOutPath "$INSTDIR\share\icons\oxygen\48x48\categories" File ${prefix}/share/icons/oxygen/48x48/categories/applications-graphics.png File ${prefix}/share/icons/oxygen/48x48/categories/preferences-system-network.png SetOutPath "$INSTDIR\share\icons\oxygen\48x48\devices" File ${prefix}/share/icons/oxygen/48x48/devices/secure-card.png SetOutPath "$INSTDIR\share\icons\oxygen\48x48\status" File ${prefix}/share/icons/oxygen/48x48/status/dialog-error.png File ${prefix}/share/icons/oxygen/48x48/status/dialog-information.png File ${prefix}/share/icons/oxygen/48x48/status/dialog-password.png File ${prefix}/share/icons/oxygen/48x48/status/dialog-warning.png File ${prefix}/share/icons/oxygen/48x48/status/security-high.png File ${prefix}/share/icons/oxygen/48x48/status/security-low.png File ${prefix}/share/icons/oxygen/48x48/status/security-medium.png SetOutPath "$INSTDIR\share\icons\oxygen\64x64\actions" File ${prefix}/share/icons/oxygen/64x64/actions/application-exit.png File ${prefix}/share/icons/oxygen/64x64/actions/configure.png File ${prefix}/share/icons/oxygen/64x64/actions/dialog-ok-apply.png File ${prefix}/share/icons/oxygen/64x64/actions/dialog-ok.png File ${prefix}/share/icons/oxygen/64x64/actions/edit-find.png File ${prefix}/share/icons/oxygen/64x64/actions/go-bottom.png File ${prefix}/share/icons/oxygen/64x64/actions/go-down.png File ${prefix}/share/icons/oxygen/64x64/actions/go-first.png File ${prefix}/share/icons/oxygen/64x64/actions/go-last.png File ${prefix}/share/icons/oxygen/64x64/actions/go-next.png File ${prefix}/share/icons/oxygen/64x64/actions/go-previous.png File ${prefix}/share/icons/oxygen/64x64/actions/go-top.png File ${prefix}/share/icons/oxygen/64x64/actions/go-up.png File ${prefix}/share/icons/oxygen/64x64/actions/list-remove.png File ${prefix}/share/icons/oxygen/64x64/actions/tools-report-bug.png SetOutPath "$INSTDIR\share\icons\oxygen\64x64\apps" File ${prefix}/share/icons/oxygen/64x64/apps/kde.png SetOutPath "$INSTDIR\share\icons\oxygen\64x64\categories" File ${prefix}/share/icons/oxygen/64x64/categories/applications-graphics.png File ${prefix}/share/icons/oxygen/64x64/categories/preferences-system-network.png SetOutPath "$INSTDIR\share\icons\oxygen\64x64\status" File ${prefix}/share/icons/oxygen/64x64/status/dialog-error.png File ${prefix}/share/icons/oxygen/64x64/status/dialog-information.png File ${prefix}/share/icons/oxygen/64x64/status/dialog-password.png File ${prefix}/share/icons/oxygen/64x64/status/dialog-warning.png File ${prefix}/share/icons/oxygen/64x64/status/security-high.png File ${prefix}/share/icons/oxygen/64x64/status/security-low.png File ${prefix}/share/icons/oxygen/64x64/status/security-medium.png -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From stefw at collabora.co.uk Fri Oct 14 18:11:33 2011 From: stefw at collabora.co.uk (Stef Walter) Date: Fri, 14 Oct 2011 18:11:33 +0200 Subject: GnuPG icons in vector form? In-Reply-To: <87k4886ir8.fsf@vigenere.g10code.de> References: <4E97CD80.5050302@collabora.co.uk> <87k4886ir8.fsf@vigenere.g10code.de> Message-ID: <4E985F35.7060207@collabora.co.uk> On 2011-10-14 11:10, Werner Koch wrote: > On Fri, 14 Oct 2011 07:49, stefw at collabora.co.uk said: >> Anyone know where the GnuPG icons in vector form are? I'm redesigning >> seahorse, and I'd like to use the GnuPG icon in seahorse to represent >> the "Place" where gnupg keys come from. > > As a command line utility GnuPG has no icons. GPA has a set of icons > but I don't know whether there is vector format for them. Ah, I should have been more specific. I was referring to the logo on the home page of gnupg.org. What does that image correspond to? Cheers, Stef From ott at mirix.org Fri Oct 14 20:32:16 2011 From: ott at mirix.org (Matthias-Christian Ott) Date: Fri, 14 Oct 2011 20:32:16 +0200 Subject: [PATCH] Support Cherry SmartTerminal ST-2000 In-Reply-To: <1318021115-2231-1-git-send-email-ott@mirix.org> References: <1318021115-2231-1-git-send-email-ott@mirix.org> Message-ID: <20111014183215.GB2689@qp> Sorry, for posting the first broken patch without a description. Is there anything that prevents the later patch to be merged? I tested basic functionalities and seemed to work, so I don't see what prevents merging it. Regards, Matthias-Christian From wk at gnupg.org Fri Oct 14 22:12:15 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 14 Oct 2011 22:12:15 +0200 Subject: GnuPG icons in vector form? In-Reply-To: <4E985F35.7060207@collabora.co.uk> (Stef Walter's message of "Fri, 14 Oct 2011 18:11:33 +0200") References: <4E97CD80.5050302@collabora.co.uk> <87k4886ir8.fsf@vigenere.g10code.de> <4E985F35.7060207@collabora.co.uk> Message-ID: <87fwiv72ow.fsf@vigenere.g10code.de> On Fri, 14 Oct 2011 18:11, stefw at collabora.co.uk said: > Ah, I should have been more specific. I was referring to the logo on the > home page of gnupg.org. What does that image correspond to? http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=tree;f=artwork;hb=HEAD Look for the svg files Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Oct 15 10:54:11 2011 From: wk at gnupg.org (Werner Koch) Date: Sat, 15 Oct 2011 10:54:11 +0200 Subject: [PATCH] Support Cherry SmartTerminal ST-2000 In-Reply-To: <20111014183215.GB2689@qp> (Matthias-Christian Ott's message of "Fri, 14 Oct 2011 20:32:16 +0200") References: <1318021115-2231-1-git-send-email-ott@mirix.org> <20111014183215.GB2689@qp> Message-ID: <87boti7hzg.fsf@vigenere.g10code.de> On Fri, 14 Oct 2011 20:32, ott at mirix.org said: > Sorry, for posting the first broken patch without a description. Is > there anything that prevents the later patch to be merged? I tested > basic functionalities and seemed to work, so I don't see what prevents > merging it. This is due to a lack of time. The patch seems small enough to be applied w/o exchanging legal papers with the FSF. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From stefw at collabora.co.uk Mon Oct 17 09:01:48 2011 From: stefw at collabora.co.uk (Stef Walter) Date: Mon, 17 Oct 2011 09:01:48 +0200 Subject: Changes to PKCS#11 definitions Message-ID: <4E9BD2DC.1060207@collabora.co.uk> Hey Marcus, I've made some minor fixes to the pkcs11.h header that comes from the Scute project, and wanted to contribute them back as requested. The patch makes all the relevant constants in pkcs11.h unsigned longs rather than integers. This allows use of the constants in places where need the size to be correct (such as varargs). The patch is rather large, bit it just makes that one change. Let me know if I should prepare it differently. Cheers, Stef -------------- next part -------------- A non-text attachment was scrubbed... Name: pkcs11-h-unsigned-long.patch Type: text/x-patch Size: 36335 bytes Desc: not available URL: From wk at gnupg.org Mon Oct 17 20:11:29 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 17 Oct 2011 20:11:29 +0200 Subject: STEED - Usable end-to-end encryption Message-ID: <87ty774hf2.fsf@vigenere.g10code.de> Hi! Over the last year Marcus and me discussed ideas on how to make encryption easier for non-crypto geeks. We explained our plans to several people and finally decided to start a project to develop such a system. Obviously it is based on GnuPG but this is only one component of the whole system. We prepared a short paper; if you are interested you may download it from http://g10code.com/docs/steed-usable-e2ee.pdf There is also a brief (for now) web page dedicated to this project: http://g10code.com/steed.html Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mb at g10code.com Tue Oct 18 14:07:14 2011 From: mb at g10code.com (Marcus Brinkmann) Date: 18 Oct 2011 14:07:14 +0200 Subject: Changes to PKCS#11 definitions In-Reply-To: <4E9BD2DC.1060207@collabora.co.uk> References: <4E9BD2DC.1060207@collabora.co.uk> Message-ID: <4E9D6BF2.60803@g10code.com> On 10/17/2011 09:01 AM, Stef Walter wrote: > Hey Marcus, > > I've made some minor fixes to the pkcs11.h header that comes from the Scute > project, and wanted to contribute them back as requested. > > The patch makes all the relevant constants in pkcs11.h unsigned longs rather > than integers. This allows use of the constants in places where need the size > to be correct (such as varargs). > > The patch is rather large, bit it just makes that one change. Let me know if I > should prepare it differently. I am unsure. On the one hand, all these constants are supposed to be used for ULONG datatypes, and thus it could be argued they should be UL. On the other hand, the official pkcs11.h header file doesn't do that. So, in order to be compatible, you can not rely on it, and have to cast anyway. The pkcs11.h file is supposed to be a drop in replacement for the official header file (at least in CRYPTOKI_COMPAT mode). It is true that adding the UL would be backwards compatible, but you will then write code that can not be backported to the official pkcs11.h without a visible indicator or compiler warning of that. Do we really want that? Do you use the CRYPTOKI_COMPAT mode? Thanks, Marcus From bernhard at intevation.de Wed Oct 19 11:07:49 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 19 Oct 2011 11:07:49 +0200 Subject: STEED - Usable end-to-end encryption In-Reply-To: <87ty774hf2.fsf@vigenere.g10code.de> References: <87ty774hf2.fsf@vigenere.g10code.de> Message-ID: <201110191107.50139.bernhard@intevation.de> Am Monday, 17. October 2011 20:11:29 schrieb Werner Koch: > Over the last year Marcus and me discussed ideas on how to make > encryption easier for non-crypto geeks. ?We explained our plans to > several people and finally decided to start a project to develop such a > system. This is a very important initiative! We all should make sure there is enough help and funding to move this foward quickly. > Obviously it is based on GnuPG but this is only one component > of the whole system. ? And STEED is a concept that all applications can implement, there is nothing GnuPG specific to it. GnuPG could just become a first product to support it. > We prepared a short paper; if you are interested > you may download it from > > ? http://g10code.com/docs/steed-usable-e2ee.pdf > > There is also a brief (for now) web page dedicated to this project: > > ? http://g10code.com/steed.html Well done! I think next we should create an understandable explanation on the webside. How can we help to improve the webside? Anyone feels like helping with graphic here? Best, Bernhard -- Managing Director + Owner: www.Intevation.net <- A Free Software Company Kolabsys.com: Board Member FSFE.org: Founding GA Member 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 stefw at collabora.co.uk Wed Oct 19 18:06:54 2011 From: stefw at collabora.co.uk (Stef Walter) Date: Wed, 19 Oct 2011 18:06:54 +0200 Subject: Changes to PKCS#11 definitions In-Reply-To: <4E9D6BF2.60803@g10code.com> References: <4E9BD2DC.1060207@collabora.co.uk> <4E9D6BF2.60803@g10code.com> Message-ID: <4E9EF59E.9080801@collabora.co.uk> On 2011-10-18 14:07, Marcus Brinkmann wrote: > On 10/17/2011 09:01 AM, Stef Walter wrote: >> Hey Marcus, >> >> I've made some minor fixes to the pkcs11.h header that comes from the Scute >> project, and wanted to contribute them back as requested. >> >> The patch makes all the relevant constants in pkcs11.h unsigned longs rather >> than integers. This allows use of the constants in places where need the size >> to be correct (such as varargs). >> >> The patch is rather large, bit it just makes that one change. Let me know if I >> should prepare it differently. > > I am unsure. On the one hand, all these constants are supposed to be used for > ULONG datatypes, and thus it could be argued they should be UL. > > On the other hand, the official pkcs11.h header file doesn't do that. So, in > order to be compatible, you can not rely on it, and have to cast anyway. I see. That's a good point. > The pkcs11.h file is supposed to be a drop in replacement for the official > header file (at least in CRYPTOKI_COMPAT mode). It is true that adding the UL > would be backwards compatible, but you will then write code that can not be > backported to the official pkcs11.h without a visible indicator or compiler > warning of that. > > Do we really want that? > > Do you use the CRYPTOKI_COMPAT mode? Yup, plain ol PKCS#11 definitions. The bummer is that we have varargs functions in libgck [1], which accept these ulongs, so our shipped pkcs11.h header defines everything as UL so that the definitions can be easily used with those functions. Cheers, Stef [1] like this one: http://developer.gnome.org/gck/unstable/gck-GckObject.html#gck-object-get From marcus.brinkmann at ruhr-uni-bochum.de Wed Oct 19 17:16:09 2011 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 19 Oct 2011 17:16:09 +0200 Subject: STEED - Usable end-to-end encryption In-Reply-To: <201110191107.50139.bernhard@intevation.de> References: <87ty774hf2.fsf@vigenere.g10code.de> <201110191107.50139.bernhard@intevation.de> Message-ID: <4E9EE9B9.40202@ruhr-uni-bochum.de> On 10/19/2011 11:07 AM, Bernhard Reiter wrote: >> http://g10code.com/steed.html > > Well done! I think next we should create an understandable explanation on the > webside. How can we help to improve the webside? Anyone feels like helping > with graphic here? I added a logo I made yesterday. But the site and/or the paper could really do with some diagrams and other technical illustrations. Thanks, Marcus From harakiri_23 at yahoo.com Wed Oct 19 20:07:45 2011 From: harakiri_23 at yahoo.com (Harakiri) Date: Wed, 19 Oct 2011 11:07:45 -0700 (PDT) Subject: STEED - Usable end-to-end encryption In-Reply-To: <87ty774hf2.fsf@vigenere.g10code.de> Message-ID: <1319047665.75751.YahooMailClassic@web130223.mail.mud.yahoo.com> --- On Mon, 10/17/11, Werner Koch wrote: > From: Werner Koch > Subject: STEED - Usable end-to-end encryption > To: gnupg-devel at gnupg.org > Cc: "Marcus Brinkmann" , gnupg-users at gnupg.org > Date: Monday, October 17, 2011, 2:11 PM > Hi! > > ? http://g10code.com/docs/steed-usable-e2ee.pdf > > There is also a brief (for now) web page dedicated to this > project: > > ? http://g10code.com/steed.html Here is some input, you might not like it - but still: I dont see any ground breaking new approaches to the topic - key search via DNS has been in commercial products for over 10 years already - nothing new - heck isnt there even an RFC that describes this? Letting the keys automatically be generated by the client is not a new approach either commercial solutions do this too - however - did you think of the keys the user already has? His ID for example - you are sponsored by the german government - the first thing which should have come into your mind is that everybody can use his "Personalausweis" as a Smartcard because it already has a private/public keypair. Other european countries could follow... Also - inventing just ANOTHER protocol for email encryption that mail clients should implement? Heck, the only protocol available in all major mail clients right now for out of the box encryption is only smime - for PGP you need plugins - even after so many years there is no out of the box solution for the other major standard - lets not talk about all the compatibility issues with smime in all existing clients. And you just want add another NEW standard which will solve issues? I dont think so. Use existing tools most user have installed on his machine by default - work with these and get a suiteable end-to-end encryption going! From smujohnson at gmail.com Wed Oct 19 22:09:46 2011 From: smujohnson at gmail.com (smu johnson) Date: Wed, 19 Oct 2011 13:09:46 -0700 Subject: STEED - Usable end-to-end encryption In-Reply-To: <87ty774hf2.fsf@vigenere.g10code.de> References: <87ty774hf2.fsf@vigenere.g10code.de> Message-ID: Hi, I read this briefly, and I'd actually like to read it over later and maybe contribute some ideas. The lack of people caring about cryptography is quite apparent, and may be solved with some good ideas of making things less annoying / hard to use. I'd be happy to help. On Mon, Oct 17, 2011 at 11:11 AM, Werner Koch wrote: > Hi! > > Over the last year Marcus and me discussed ideas on how to make > encryption easier for non-crypto geeks. We explained our plans to > several people and finally decided to start a project to develop such a > system. Obviously it is based on GnuPG but this is only one component > of the whole system. We prepared a short paper; if you are interested > you may download it from > > http://g10code.com/docs/steed-usable-e2ee.pdf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.brinkmann at ruhr-uni-bochum.de Thu Oct 20 03:33:04 2011 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 20 Oct 2011 03:33:04 +0200 Subject: STEED - Usable end-to-end encryption In-Reply-To: <1319047665.75751.YahooMailClassic@web130223.mail.mud.yahoo.com> References: <1319047665.75751.YahooMailClassic@web130223.mail.mud.yahoo.com> Message-ID: <4E9F7A50.8010803@ruhr-uni-bochum.de> On 10/19/2011 08:07 PM, Harakiri wrote: > Here is some input, you might not like it - but still: Thanks, we certainly appreciate your feedback! > I dont see any ground breaking new approaches to the topic - key search via DNS has been in commercial products for over 10 years already - nothing new - heck isnt there even an RFC that describes this? Right, and we don't claim to have ground breaking new ideas, just a careful combination of well established and tested ideas. I consider this to be a strength, not a weakness. > Letting the keys automatically be generated by the client is not a new approach either commercial solutions do this too - however - did you think of the keys the user already has? His ID for example - you are sponsored by the german government - the first thing which should have come into your mind is that everybody can use his "Personalausweis" as a Smartcard because it already has a private/public keypair. Other european countries could follow... Usability is tricky business. A lot of it seems obvious or trivial, yet over and over again we fail to create usable software systems due to various pressures that lead us astray. We outlined in the paper how usability barriers can hopefully be overcome consistently (previous efforts have focussed on individual problems in isolation). Automatic key generation is as important as automatic key distribution and the other suggestions that work in combination for maximum effect. But automatic key generation alone is not sufficient, and the paper is about the combination of features rather than each individual feature in isolation. As for pre-existing keys, we do not mention nationally issued certificates in particular, but we do mention smart cards and other reasons to use pre-existing keys (that we consider to be more relevant and probably than a desire to use nationally issued certificates in the near future). A provision can be made for them, but they can not be mandatory, for technical, usability and privacy reasons. > Also - inventing just ANOTHER protocol for email encryption that mail clients should implement? Heck, the only protocol available in all major mail clients right now for out of the box encryption is only smime - for PGP you need plugins - even after so many years there is no out of the box solution for the other major standard - lets not talk about all the compatibility issues with smime in all existing clients. And you just want add another NEW standard which will solve issues? I dont think so. STEED does not create a new protocol for email encryption but reuses and is fully compatible to OpenPGP and S/MIME, although we do propose a different trust model. We agree that OpenPGP and S/MIME are successful encapsulations, but we think their trust models are insufficient to achieve ubiquitous mail encryption. > Use existing tools most user have installed on his machine by default - work with these and get a suiteable end-to-end encryption going! I don't know how you suggest this could be done, but I would be very interested in alternative proposals. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Thu Oct 20 03:37:09 2011 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 20 Oct 2011 03:37:09 +0200 Subject: Changes to PKCS#11 definitions In-Reply-To: <4E9EF59E.9080801@collabora.co.uk> References: <4E9BD2DC.1060207@collabora.co.uk> <4E9D6BF2.60803@g10code.com> <4E9EF59E.9080801@collabora.co.uk> Message-ID: <4E9F7B45.8020808@ruhr-uni-bochum.de> On 10/19/2011 06:06 PM, Stef Walter wrote: > On 2011-10-18 14:07, Marcus Brinkmann wrote: >> On 10/17/2011 09:01 AM, Stef Walter wrote: >>> Hey Marcus, >>> >>> I've made some minor fixes to the pkcs11.h header that comes from the Scute >>> project, and wanted to contribute them back as requested. >>> >>> The patch makes all the relevant constants in pkcs11.h unsigned longs rather >>> than integers. This allows use of the constants in places where need the size >>> to be correct (such as varargs). >>> >>> The patch is rather large, bit it just makes that one change. Let me know if I >>> should prepare it differently. >> >> I am unsure. On the one hand, all these constants are supposed to be used for >> ULONG datatypes, and thus it could be argued they should be UL. >> >> On the other hand, the official pkcs11.h header file doesn't do that. So, in >> order to be compatible, you can not rely on it, and have to cast anyway. > > I see. That's a good point. > >> The pkcs11.h file is supposed to be a drop in replacement for the official >> header file (at least in CRYPTOKI_COMPAT mode). It is true that adding the UL >> would be backwards compatible, but you will then write code that can not be >> backported to the official pkcs11.h without a visible indicator or compiler >> warning of that. >> >> Do we really want that? >> >> Do you use the CRYPTOKI_COMPAT mode? > > Yup, plain ol PKCS#11 definitions. > > The bummer is that we have varargs functions in libgck [1], which accept > these ulongs, so our shipped pkcs11.h header defines everything as UL so > that the definitions can be easily used with those functions. I wish I could just say we could add the UL, but what if somebody else already uses the constants in varargs and relies on the lack of UL? We would break their code, and that in an incompatible way to the official pkcs11.h. Seems to me we are pretty much forced not to do the change. Or do you see a way out? Maybe if we make it dependent on a macro PKCS11_UL_CONSTANTS that needs to be defined before including pkcs11.h? I am not sure that would help your library interface (if the user includes pkcs11.h before your header file, you'd be hosed). Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Thu Oct 20 04:16:01 2011 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 20 Oct 2011 04:16:01 +0200 Subject: STEED - Usable end-to-end encryption In-Reply-To: <4E9F2568.6080709@digitalbrains.com> References: <87ty774hf2.fsf@vigenere.g10code.de> <4E9F2568.6080709@digitalbrains.com> Message-ID: <4E9F8461.5030706@ruhr-uni-bochum.de> Hi Peter, thanks for your feedback. On 10/19/2011 09:30 PM, Peter Lebbing wrote: > However, I think you're not ambitious enough when you opt for using DNS for key > distribution. Yes, the infrastructure and RR types[1] are already there. But it > brings this nasty dependency on the provider. Because the part of the client > updates to the DNS is a key missing part in the DNS infrastructure as today, and > I don't see providers adding that soon. You are right that it is a challenge to get the support in the providers, but note that changes in the mail client are required anyway. Sure, changing the client and changing the DNS infrastructure are two different kind of beasts, but we probably can not do without the providers completely if we want ubiquitous support. > I'm thinking more of things like DHT, Distributed Hash Tables, in BitTorrent, or > similar concepts in other peer-to-peer networks. I have no idea how it works :), > but it does. You fire up your BitTorrent, all the data it needs is the hash of a > torrent file, and suddenly it learns IP-addresses of other people who share that > torrent file. If you could do something similar for mapping e-mail addresses to > certificates, you don't need ISP's to implement extra stuff. Because I think > that is a really major hurdle; probably a too steep one, IMHO. Yes, P2P networks are great, let's do more of those. But why stop at certificates? Just use a P2P network for all of DNS. See what happened? I just turned it around. :) The paper notes how we can utilize DNSSEC to strengthen our trust model. Similarly, we can utilize a P2P based DNS system. Now instead of one problem, we got two :) P2P systems are tricky to get right, and have their own tradeoffs. Also, while acceptance for our proposal among service providers will be tough to get, I'd expect that getting acceptance for a P2P based system would be even harder. A lot of things have to fall into place to make a P2P network a viable alternative, and not all of them are technical. Thanks, Marcus From lists-gnupgdev at lina.inka.de Thu Oct 20 05:30:50 2011 From: lists-gnupgdev at lina.inka.de (Bernd Eckenfels) Date: Thu, 20 Oct 2011 05:30:50 +0200 Subject: STEED - Usable end-to-end encryption In-Reply-To: <4E9F8461.5030706@ruhr-uni-bochum.de> References: <87ty774hf2.fsf@vigenere.g10code.de> <4E9F2568.6080709@digitalbrains.com> <4E9F8461.5030706@ruhr-uni-bochum.de> Message-ID: <4E9F95EA.9090205@lina.inka.de> Am 20.10.2011 04:16, schrieb Marcus Brinkmann: > You are right that it is a challenge to get the support in the providers the lowest efford are discovery via personal web pages like doing XDR or maybe webfinger. Most users wont be able to have special RRs - not even for their own domains (which is also rather seldom). I would use like openID does. Gruss Bernd From wk at gnupg.org Thu Oct 20 11:04:15 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Oct 2011 11:04:15 +0200 Subject: STEED - Usable end-to-end encryption In-Reply-To: <4E9F95EA.9090205@lina.inka.de> (Bernd Eckenfels's message of "Thu, 20 Oct 2011 05:30:50 +0200") References: <87ty774hf2.fsf@vigenere.g10code.de> <4E9F2568.6080709@digitalbrains.com> <4E9F8461.5030706@ruhr-uni-bochum.de> <4E9F95EA.9090205@lina.inka.de> Message-ID: <87hb34xcds.fsf@vigenere.g10code.de> On Thu, 20 Oct 2011 05:30, lists-gnupgdev at lina.inka.de said: > the lowest efford are discovery via personal web pages like doing XDR or > maybe webfinger. Most users wont be able to have special RRs - not even Most users don't have personal web pages. So what now? Well many users have a facebook page - but this would make facebook mandatory and we woold need support from them (at least to guarantee that they don't break any assumptions). Not much different to work with ISPs. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jerome at jeromebaum.com Thu Oct 20 13:14:06 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 20 Oct 2011 13:14:06 +0200 Subject: STEED - Usable end-to-end encryption In-Reply-To: <87hb34xcds.fsf@vigenere.g10code.de> References: <87ty774hf2.fsf@vigenere.g10code.de> <4E9F2568.6080709@digitalbrains.com> <4E9F8461.5030706@ruhr-uni-bochum.de> <4E9F95EA.9090205@lina.inka.de> <87hb34xcds.fsf@vigenere.g10code.de> Message-ID: <4EA0027E.6090007@jeromebaum.com> >> the lowest efford are discovery via personal web pages like doing XDR or >> maybe webfinger. Most users wont be able to have special RRs - not even > > Most users don't have personal web pages. So what now? Well many users > have a facebook page - but this would make facebook mandatory and we > woold need support from them (at least to guarantee that they don't > break any assumptions). Not much different to work with ISPs. Look at how OpenID does it. I can use my personal web page if I want, or I can go to one of the many providers and they'll create a "profile page" for me. Some of them even support using my domain if I have one, so I can have http://example.com/ without hosting worries. I don't think a implementation is "difficult" in any way and not having a personal web page is an empty argument. But the real problem (and part of why OpenID is still so un-popular) is that people don't like usernames that start with "http://" ("h-tee-tee-pee-colon-forward-slash-forward-slash"). The core problem is that the lookup isn't email-to-certificate but url-to-certificate, but the end-user wants to send something to my email, not to my url. I suppose there are some things we could do about this: 1. Drop the "http://" (make it an implicit default) 2. Add some type of element to the page so I can go from url to email. Now I can "email" jerome.example.com and it'll go to that page, lookup my email and cert, encrypt to my cert and send to my email. Just another random idea that could lead somewhere, or nowhere at all. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA From wk at gnupg.org Thu Oct 20 21:59:57 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Oct 2011 21:59:57 +0200 Subject: STEED - Usable end-to-end encryption In-Reply-To: <4EA0027E.6090007@jeromebaum.com> (Jerome Baum's message of "Thu, 20 Oct 2011 13:14:06 +0200") References: <87ty774hf2.fsf@vigenere.g10code.de> <4E9F2568.6080709@digitalbrains.com> <4E9F8461.5030706@ruhr-uni-bochum.de> <4E9F95EA.9090205@lina.inka.de> <87hb34xcds.fsf@vigenere.g10code.de> <4EA0027E.6090007@jeromebaum.com> Message-ID: <87hb33wi0y.fsf@vigenere.g10code.de> On Thu, 20 Oct 2011 13:14, jerome at jeromebaum.com said: > Look at how OpenID does it. I can use my personal web page if I want, or > I can go to one of the many providers and they'll create a "profile > page" for me. Some of them even support using my domain if I have one, That is exactly what we want to avoid. See the footnote on page 3: 1 Using a separate provider for public key storage has the problem that it again separates mail address and public key. [from the user's POV]. GnuPG even supports an alternate root for the PKA lookup but it is a solution for geeks or companies who want to sell a service to email users. The whole point is that we don't want an optional service but encrypted email all of a piece. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jerome at jeromebaum.com Thu Oct 20 22:05:03 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 20 Oct 2011 22:05:03 +0200 Subject: STEED - Usable end-to-end encryption In-Reply-To: <87hb33wi0y.fsf@vigenere.g10code.de> References: <87ty774hf2.fsf@vigenere.g10code.de> <4E9F2568.6080709@digitalbrains.com> <4E9F8461.5030706@ruhr-uni-bochum.de> <4E9F95EA.9090205@lina.inka.de> <87hb34xcds.fsf@vigenere.g10code.de> <4EA0027E.6090007@jeromebaum.com> <87hb33wi0y.fsf@vigenere.g10code.de> Message-ID: <4EA07EEF.1050806@jeromebaum.com> >> Look at how OpenID does it. I can use my personal web page if I want, or >> I can go to one of the many providers and they'll create a "profile >> page" for me. Some of them even support using my domain if I have one, > > That is exactly what we want to avoid. See the footnote on page 3: > > 1 Using a separate provider for public key storage has the problem > that it again separates mail address and public key. > > [from the user's POV]. But later down in my email I suggest a new kind of "mail address" that is basically a pointer to the key and real email address. So instead of jerome at provider1.example.com you might type jerome.provider2.example.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA From ott at mirix.org Thu Oct 20 22:25:58 2011 From: ott at mirix.org (Matthias-Christian Ott) Date: Thu, 20 Oct 2011 22:25:58 +0200 Subject: STEED - Usable end-to-end encryption In-Reply-To: <4E9F8461.5030706@ruhr-uni-bochum.de> References: <87ty774hf2.fsf@vigenere.g10code.de> <4E9F2568.6080709@digitalbrains.com> <4E9F8461.5030706@ruhr-uni-bochum.de> Message-ID: <20111020202558.GA2761@qp> On Thu, Oct 20, 2011 at 04:16:01AM +0200, Marcus Brinkmann wrote: > On 10/19/2011 09:30 PM, Peter Lebbing wrote: > > However, I think you're not ambitious enough when you opt for using DNS for key > > distribution. Yes, the infrastructure and RR types[1] are already there. But it > > brings this nasty dependency on the provider. Because the part of the client > > updates to the DNS is a key missing part in the DNS infrastructure as today, and > > I don't see providers adding that soon. > > You are right that it is a challenge to get the support in the providers, but > note that changes in the mail client are required anyway. Sure, changing the > client and changing the DNS infrastructure are two different kind of beasts, > but we probably can not do without the providers completely if we want > ubiquitous support. But who are the providers? Except for people who work in computer science, physics or similar fields I don't know people who run their own mail servers or are part of a cooperative. Most other people use a handful of providers who often offer free service in exchange for the loss of privacy or at least some form of semi-targeted advertisement. Do you expect those providers to ruin their business models by implementing this proposal? I wouldn't count on them. Perhaps the providers could also be forced by law not to implement this, because (if I remember correctly) come countries require that they store at least the header information (including subject, which should also be encryted by the system) for traffic analysis. So in the worst case the providers couldn't implement this without breaking the law (I doubt that citizens could use the system without breaking the law in this situation either, but individuals are often more venturous than organisations). What about making everyone their own provider? The efforts in this direction intiated by Eben Moglen that lead to the FreedomBox and other projects seem to go in the right direction. It doesn't seem to me less realistic than requiring cooperation from providers. Regards, Matthias-Christian From marcus.brinkmann at ruhr-uni-bochum.de Fri Oct 21 01:46:02 2011 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 21 Oct 2011 01:46:02 +0200 Subject: STEED - Usable end-to-end encryption In-Reply-To: <20111020202558.GA2761@qp> References: <87ty774hf2.fsf@vigenere.g10code.de> <4E9F2568.6080709@digitalbrains.com> <4E9F8461.5030706@ruhr-uni-bochum.de> <20111020202558.GA2761@qp> Message-ID: <4EA0B2BA.30303@ruhr-uni-bochum.de> On 10/20/2011 10:25 PM, Matthias-Christian Ott wrote: > But who are the providers? Except for people who work in computer > science, physics or similar fields I don't know people who run their own > mail servers or are part of a cooperative. Most other people use a > handful of providers who often offer free service in exchange for the > loss of privacy or at least some form of semi-targeted advertisement. Do > you expect those providers to ruin their business models by implementing > this proposal? I wouldn't count on them. Maybe. But the only way to fail for certain is by not trying. There are other business models and market pressures beside those that you are highlighting. It's not easy to predict. > Perhaps the providers could also be forced by law not to implement > this, because (if I remember correctly) come countries require that > they store at least the header information (including subject, which > should also be encryted by the system) for traffic analysis. So in > the worst case the providers couldn't implement this without breaking > the law (I doubt that citizens could use the system without breaking the > law in this situation either, but individuals are often more venturous > than organisations). STEED is fully compatible with existing mail encryption, so we do not include the headers in the plaintext. I am not an expert, but as far as I know the regulation usually demands to store connection data that is available, it does not ask for data that is not available for whatever reason. I think your interpretation of the regulations in that area is overly pessimistic, but I could be wrong. Maybe you can verify this? > What about making everyone their own provider? The efforts in this > direction intiated by Eben Moglen that lead to the FreedomBox and other > projects seem to go in the right direction. It doesn't seem to me less > realistic than requiring cooperation from providers. I think everybody deserves private email communication, not only those who are willing to be their own provider. We don't expect people to carry out their own snail mail letters either, and the business model of the post office does not require spying on the letters. Now, it may be the case that the freedom box is (or will be) a more attractive way for people to do email, and everybody will use it and nobody will use proprietary email service providers. That would be excellent! The FreedomBox project is a very important project, and it deserves our strongest support possible. If it is a better alternative, we still need to convince the FreedomBox project to adopt the STEED proposal (not a single word in the paper would have to change). And I agree that this is an overall more appealing task than trying to convince the proprietary providers. But, we have to go where the users are, and we have to try our best to get the providers cooperation. There is no benefit in ignoring them and their users just for our convenience. If this is too daunting for you, please remember that we do not have to get their active cooperation. If they accept it grudgingly because not following along would be bad business (or illegal), then that's good enough. That requires that we raise the state of the art in the field. Maybe you are still not convinced. Then let me give you an illustrative analogy. (Disclaimer: I am not associated with SawStop or anybody involved, nor have I met anybody involved or used their product). An inventor created a table saw that can prevent injury by stopping the blade as soon as it is touched by human flesh ("SawStop"). According to the inventory, he could not get the technology to be marketed by the big table saw companies. His claim is that the companies think that by raising the safety measures in the table saw, they would be more liable for table saw accidents, which would make them subject to litigation. Eventually he created his own SawStop product line. Now, after several years, lawmakers and regulators have taken notice and might make sawstop like technology mandatory in table saws. Now, maybe SawStop is bad technology, maybe it's good. But at least something is true: As long as no candidate technology like it exists, the question doesn't even come up. That's the state we are at with email encryption. Everybody who tried has learned that email encryption is not worth the hassle. Everybody who hasn't tried just expects email to be secure and might not even be aware that it is not. It's time to change that equation, don't you think? The good news is that STEED will integrate extremely well in P2P systems. The dependency on a provider in STEED is not integral to the proposal, but just a consequence of people already relying on their providers infrastructure for everything else. If users use different infrastructure, STEED will also work over that infrastructure just as well. Thanks, Marcus From wk at gnupg.org Fri Oct 21 10:14:40 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Oct 2011 10:14:40 +0200 Subject: STEED - Usable end-to-end encryption In-Reply-To: <4EA0B2BA.30303@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "21 Oct 2011 01:46:02 +0200") References: <87ty774hf2.fsf@vigenere.g10code.de> <4E9F2568.6080709@digitalbrains.com> <4E9F8461.5030706@ruhr-uni-bochum.de> <20111020202558.GA2761@qp> <4EA0B2BA.30303@ruhr-uni-bochum.de> Message-ID: <87aa8uwykv.fsf@vigenere.g10code.de> On Fri, 21 Oct 2011 01:46, marcus.brinkmann at ruhr-uni-bochum.de said: > not ask for data that is not available for whatever reason. I think your > interpretation of the regulations in that area is overly pessimistic, but I > could be wrong. Maybe you can verify this? Actually the German Federal commissioner for data protection demands the use of strong encryption. According to him the message-escrow-able de-mail.de law and services are not suitable for private messages. [1] Salam-Shalom, Werner [1] In German: -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From stefw at collabora.co.uk Fri Oct 21 12:40:29 2011 From: stefw at collabora.co.uk (Stef Walter) Date: Fri, 21 Oct 2011 12:40:29 +0200 Subject: GnuPG icons in vector form? In-Reply-To: <87fwiv72ow.fsf@vigenere.g10code.de> References: <4E97CD80.5050302@collabora.co.uk> <87k4886ir8.fsf@vigenere.g10code.de> <4E985F35.7060207@collabora.co.uk> <87fwiv72ow.fsf@vigenere.g10code.de> Message-ID: <4EA14C1D.1080204@collabora.co.uk> On 2011-10-14 22:12, Werner Koch wrote: > On Fri, 14 Oct 2011 18:11, stefw at collabora.co.uk said: > >> Ah, I should have been more specific. I was referring to the logo on the >> home page of gnupg.org. What does that image correspond to? > > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=tree;f=artwork;hb=HEAD > > Look for the svg files Thanks! Made some in the various GNOME sizes: http://git.gnome.org/browse/gcr/plain/gcr/icons/src/gcr-gnupg.svg http://git.gnome.org/browse/gcr/tree/gcr/icons And you can see it a screenshot here: http://stef.thewalter.net/2011/10/redesigning-seahorse-experience.html Cheers, Stef From bernhard at intevation.de Fri Oct 21 14:13:46 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 21 Oct 2011 14:13:46 +0200 Subject: web for: STEED - Usable end-to-end encryption In-Reply-To: <4E9EE9B9.40202@ruhr-uni-bochum.de> References: <87ty774hf2.fsf@vigenere.g10code.de> <201110191107.50139.bernhard@intevation.de> <4E9EE9B9.40202@ruhr-uni-bochum.de> Message-ID: <201110211413.50637.bernhard@intevation.de> Am Wednesday, 19. October 2011 17:16:09 schrieb Marcus Brinkmann: > On 10/19/2011 11:07 AM, Bernhard Reiter wrote: > >> ? http://g10code.com/steed.html > > > > Well done! I think next we should create an understandable explanation on > > the webside. How can we help to improve the webside? Anyone feels like > > helping with graphic here? > > I added a logo I made yesterday. Well done! > But the site and/or the paper could > really do with some diagrams and other technical illustrations. True, but it also needs a better explanation to complement the whitepaper. My suggestion is that we set up a wiki and start getting this crafted. Best, Bernhard -- Managing Director + Owner: www.Intevation.net <- A Free Software Company Kolabsys.com: Board Member FSFE.org: Founding GA Member 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 gniibe at fsij.org Fri Oct 21 15:56:36 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 21 Oct 2011 22:56:36 +0900 Subject: [PATCH] fix double-free in g10/export.c Message-ID: <1319205396.2013.15.camel@latx1.gniibe.org> Using gnupg of Git master branch, I encountered SEGV (at malloc) when I did "gpg2 --export-secret-keys". I think that there is double free in g10/export.c for variable 'list'. For me, following patch fixed SEGV. diff --git a/g10/export.c b/g10/export.c index 7deee6b..9a34852 100644 --- a/g10/export.c +++ b/g10/export.c @@ -507,7 +507,7 @@ transfer_format_to_openpgp (gcry_sexp_t s_pgp, PKT_public_key *pk) } skey[skeyidx++] = NULL; - gcry_sexp_release (list); + gcry_sexp_release (list); list = NULL; /* We have no need for the CSUM valuel thus we don't parse it. */ /* list = gcry_sexp_find_token (top_list, "csum", 0); */ -- 1.7.6.3 From ott at mirix.org Sun Oct 23 18:50:16 2011 From: ott at mirix.org (Matthias-Christian Ott) Date: Sun, 23 Oct 2011 18:50:16 +0200 Subject: STEED - Usable end-to-end encryption In-Reply-To: <4EA0B2BA.30303@ruhr-uni-bochum.de> References: <87ty774hf2.fsf@vigenere.g10code.de> <4E9F2568.6080709@digitalbrains.com> <4E9F8461.5030706@ruhr-uni-bochum.de> <20111020202558.GA2761@qp> <4EA0B2BA.30303@ruhr-uni-bochum.de> Message-ID: <20111023164459.GA3339@qp> On Fri, Oct 21, 2011 at 01:46:02AM +0200, Marcus Brinkmann wrote: > On 10/20/2011 10:25 PM, Matthias-Christian Ott wrote: > > But who are the providers? Except for people who work in computer > > science, physics or similar fields I don't know people who run their own > > mail servers or are part of a cooperative. Most other people use a > > handful of providers who often offer free service in exchange for the > > loss of privacy or at least some form of semi-targeted advertisement. Do > > you expect those providers to ruin their business models by implementing > > this proposal? I wouldn't count on them. > > Maybe. But the only way to fail for certain is by not trying. There are > other business models and market pressures beside those that you are > highlighting. It's not easy to predict. I agree, there are other business models and perhaps there will be demand for this, but I just summarised the service providers almost all ?non-technical? people I communicate with use. > > Perhaps the providers could also be forced by law not to implement > > this, because (if I remember correctly) come countries require that > > they store at least the header information (including subject, which > > should also be encryted by the system) for traffic analysis. So in > > the worst case the providers couldn't implement this without breaking > > the law (I doubt that citizens could use the system without breaking the > > law in this situation either, but individuals are often more venturous > > than organisations). > > STEED is fully compatible with existing mail encryption, so we do not include > the headers in the plaintext. I am not an expert, but as far as I know the > regulation usually demands to store connection data that is available, it does > not ask for data that is not available for whatever reason. I think your > interpretation of the regulations in that area is overly pessimistic, but I > could be wrong. Maybe you can verify this? I'm not aware of any overview of e-mail data rentention, so I don't have complete picture, but a quick search on EU data retention laws showed that only SMTP envelope data is officially stored, so at least in these countries it's not a problem (though I think the subject should be encrypted as well). Moreover, I agree that as long as the body and thus the actual contents are not stored there is reason why a provider could break the law by providing STEED services to their costumers. Fortunately many countries have laws to garantuee (at leas in theory) privacy of correspondance and these laws of a long tradition, so it seems hard to abolish them. However, I see the possibility that providers could be forced to cooperate with government agencies, but this would have little impact and would require bigger efforts to ?break? STEED this way (e.g. MITM attacks by publishing false keys for new contacts). > > What about making everyone their own provider? The efforts in this > > direction intiated by Eben Moglen that lead to the FreedomBox and other > > projects seem to go in the right direction. It doesn't seem to me less > > realistic than requiring cooperation from providers. > > I think everybody deserves private email communication, not only those who are > willing to be their own provider. We don't expect people to carry out their > own snail mail letters either, and the business model of the post office does > not require spying on the letters. I agree, but I also talked to people who don't care about privacy (nothing to hide) and don't understand it. Therefore, it is important not to rely on the market to provide the means for private e-mail communication (do it yourself instead of relying on other people to do it). > But, we have to go where the users are, and we have to try our best to get the > providers cooperation. There is no benefit in ignoring them and their users > just for our convenience. Let's say you had the opportunity to convince a smaller independent hosting provider that e.g. sells web hosting, e-mail and resells internet connectivity, how would you do this? There had to be real demand and easily installable and maintainable software to convince them to implement STEED. Recently I did some search and inquiries on DNSSEC, for which there is argueably real demands from private and enterprise customers and there is working software, but only relatively few companies worldwide offer it and I don't expect it to be widely deployed within the next years. However, people running their own server have it running or at leas prepared (waiting for the registras to close the trust chain by submitting their public key to the registry) for some time now. > Maybe you are still not convinced. Then let me give you an illustrative > analogy. (Disclaimer: I am not associated with SawStop or anybody involved, > nor have I met anybody involved or used their product). An inventor created a > table saw that can prevent injury by stopping the blade as soon as it is > touched by human flesh ("SawStop"). According to the inventory, he could not > get the technology to be marketed by the big table saw companies. His claim > is that the companies think that by raising the safety measures in the table > saw, they would be more liable for table saw accidents, which would make them > subject to litigation. Eventually he created his own SawStop product line. > Now, after several years, lawmakers and regulators have taken notice and might > make sawstop like technology mandatory in table saws. > > Now, maybe SawStop is bad technology, maybe it's good. But at least something > is true: As long as no candidate technology like it exists, the question > doesn't even come up. That's the state we are at with email encryption. > Everybody who tried has learned that email encryption is not worth the hassle. > Everybody who hasn't tried just expects email to be secure and might not even > be aware that it is not. It's time to change that equation, don't you think? I agree, but there is a lot to be done. If the technical specification is done and there is working software, there really hard work just begins as I tried to demonstrate by taking DNSSEC as an example. Regards, Matthias-Christian From phcoder at gmail.com Sun Oct 23 20:44:54 2011 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Sun, 23 Oct 2011 20:44:54 +0200 Subject: Fix few warnings in libgcrypt/cipher Message-ID: <4EA460A6.6050309@gmail.com> -- Regards Vladimir '?-coder/phcoder' Serbinenko -------------- next part -------------- A non-text attachment was scrubbed... Name: libgcrypt.diff Type: text/x-diff Size: 1832 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 294 bytes Desc: OpenPGP digital signature URL: From marcus.brinkmann at ruhr-uni-bochum.de Sun Oct 23 22:56:57 2011 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 23 Oct 2011 22:56:57 +0200 Subject: STEED - Usable end-to-end encryption In-Reply-To: <20111023164459.GA3339@qp> References: <87ty774hf2.fsf@vigenere.g10code.de> <4E9F2568.6080709@digitalbrains.com> <4E9F8461.5030706@ruhr-uni-bochum.de> <20111020202558.GA2761@qp> <4EA0B2BA.30303@ruhr-uni-bochum.de> <20111023164459.GA3339@qp> Message-ID: <4EA47F99.8040106@ruhr-uni-bochum.de> Hi Matthias-Christian, thanks for your comments, I think they are entirely correct. With respect to convincing ISPs, STEED is not a complete proposal yet. The STEED paper covers the technical aspects of making email encryption usable for the user. It does not cover the policies of the parties involved and strategies to break down walls of tradition. I think there are good reasons for this. It is easier to present the technical aspects in the form of a paper, while the policy stuff is probably more a learning process that involves entering a dialogue of multiple parties. Also, success of STEED may depend on external policy changes to some extent. When those happen, we should already be in place, though. So, you summed it up best: "there is a lot to be done" Thanks, Marcus From jeanjacquesbrucker at gmail.com Fri Oct 28 14:33:22 2011 From: jeanjacquesbrucker at gmail.com (Jean-Jacques Brucker) Date: Fri, 28 Oct 2011 14:33:22 +0200 Subject: export cleaned certificate. Message-ID: Hi, I d like to export some cleaned certificate : without any signature except the last one auto-signature on each uid. The tip using the character '!' work fine to export only one key, but and don't have find how to remove signatures (and old auto-signature if more that once) without editing the certificate manually... Can you help ? Thx. NB: Again, the question is relative with this project : https://github.com/Open-UDC/open-udc which might interest people involved with freedom box. From wk at gnupg.org Fri Oct 28 16:05:32 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 28 Oct 2011 16:05:32 +0200 Subject: export cleaned certificate. In-Reply-To: (Jean-Jacques Brucker's message of "Fri, 28 Oct 2011 14:33:22 +0200") References: Message-ID: <87vcr9qkib.fsf@vigenere.g10code.de> On Fri, 28 Oct 2011 14:33, jeanjacquesbrucker at gmail.com said: > I d like to export some cleaned certificate : without any signature > except the last one auto-signature on each uid. gpg --export-options export-minimal --export or gpg --export-options export-clean --export export-clean Compact (remove all signatures from) user IDs on the key being exported if the user IDs are not usable. Also, do not export any signatures that are not usable. This includes signatures that were issued by keys that are not present on the keyring. This option is the same as running the --edit-key command "clean" before export except that the local copy of the key is not modified. Defaults to no. export-minimal Export the smallest key possible. This removes all signatures except the most recent self-signature on each user ID. This option is the same as running the --edit-key command "minimize" before export except that the local copy of the key is not modified. Defaults to no. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jeanjacquesbrucker at gmail.com Fri Oct 28 17:54:07 2011 From: jeanjacquesbrucker at gmail.com (Jean-Jacques Brucker) Date: Fri, 28 Oct 2011 17:54:07 +0200 Subject: export cleaned certificate. In-Reply-To: <87vcr9qkib.fsf@vigenere.g10code.de> References: <87vcr9qkib.fsf@vigenere.g10code.de> Message-ID: This options missed to my available french man. I should more unset LANGUAGE sometime ... ( $ LANGUAGE= man gpg ) ...or spend more time translating to my language (I don't even know best pointer to update this french man... man-pages-fr-3.03.0 ! ? ) Thx a lot. 2011/10/28 Werner Koch : > On Fri, 28 Oct 2011 14:33, jeanjacquesbrucker at gmail.com said: > >> I d like to export some cleaned certificate : without any signature >> except the last one auto-signature on each uid. > > ?gpg --export-options export-minimal --export > > or > > ?gpg --export-options export-clean --export > > > ?export-clean > > ? ? Compact (remove all signatures from) user IDs on the key > ? ? being exported if the user IDs are not usable. Also, do not export > ? ? any signatures that are not usable. ?This includes signatures that > ? ? were issued by keys that are not present on the keyring. This > ? ? option is the same as running the --edit-key command "clean" before > ? ? export except that the local copy of the key is not > ? ? modified. Defaults to no. > > > ?export-minimal > > ? ? Export the smallest key possible. This removes all signatures > ? ? except the most recent self-signature on each user ID. This option > ? ? is the same as running the --edit-key command "minimize" before > ? ? export except that the local copy of the key is not > ? ? modified. Defaults to no. > > > > Salam-Shalom, > > ? Werner > > -- > Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. > > From micah at riseup.net Fri Oct 28 22:01:22 2011 From: micah at riseup.net (Micah Anderson) Date: Fri, 28 Oct 2011 16:01:22 -0400 Subject: STEED - Usable end-to-end encryption References: <87ty774hf2.fsf@vigenere.g10code.de> <4E9F2568.6080709@digitalbrains.com> <4E9F8461.5030706@ruhr-uni-bochum.de> Message-ID: <87hb2slwbx.fsf@algae.riseup.net> Hello, Thanks for working on the STEED concept, I do think that ubiquitous, easy-to-use encryption is needed and I hope that this moves us closer to that goal. I have not fully digested the paper yet, but one thing I wanted to bring up: "Marcus Brinkmann" writes: > P2P systems are tricky to get right, and have their own tradeoffs. Also, > while acceptance for our proposal among service providers will be tough to > get, I'd expect that getting acceptance for a P2P based system would be even > harder. A lot of things have to fall into place to make a P2P network a > viable alternative, and not all of them are technical. In the paper, section "III. Opportunistic Encryption" you propose storing and retreiving certificates be DNS because "... The proposal automatically benefits from security improvements to DNS. In particular, DNSSEC disables man-in-the-middle attacks." It has been shown, many times, how DNSSEC does *not* disable MiTM attacks. All you are doing by including certificates in DNSSEC is transferring your trust into a centralized, largely unaccountable, group of organizations. Haven't we learned from the Certificate Authority system's problems? The TLD .com is administered by VeriSign, they are NOT a company that I trust to refrain from doing nefarious things, and why should I? The Garfinkel citation seems to include two properties that go against opportunistic encryption, according to your proposal. One is encrypting the headers of email; the second is to include the certificates in the email. The rationale for rejecting the certificates being included is that you lose secure initial contact, which I cannot disagree with. However, if we weren't completely throwing out the decentralized, strong cryptographic models that OpenPGP's PKI has (which guards us against centralized failure modes) to adopt a completely centralized model that DNSSEC brings us, then we could consider a hybrid model of trust where individual users have control over who to trust to verify authenticity, but also have the flexibility to delegate trust where they desire. I dont know the solution here, but replacing the OpenPGP PKI with DNSSEC seems suboptimal. you could instead ship the certificate AND use DNSEC, and allow for other mechanism, notaries etc. This provides secondary, or tertiary network perspectives from which to correlate and verify certificates, rather than handing it all over to a centralized authority. Its easy to MiTM DNSEC if you are a government, but if you were *also* shipping the certificate in the email, then the burden of compromise has been increased, you now also have to also own the transports between the two MTAs, which may be difficult if they are doing TLS, but its a lot better than just handing things over to Verisign. If I had the flexibility to delegate some level of notarized trust to an organization that I trust to certify certain things, then I'd be in a much more comfortable position than is offered by STEED's proposal. micah From bernhard at intevation.de Mon Oct 31 09:36:13 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 31 Oct 2011 09:36:13 +0100 Subject: STEED - Usable end-to-end encryption In-Reply-To: <87hb2slwbx.fsf@algae.riseup.net> References: <87ty774hf2.fsf@vigenere.g10code.de> <4E9F8461.5030706@ruhr-uni-bochum.de> <87hb2slwbx.fsf@algae.riseup.net> Message-ID: <201110310936.17440.bernhard@intevation.de> Hi Micah, Am Friday, 28. October 2011 22:01:22 schrieb Micah Anderson: > However, if we weren't completely throwing out the decentralized, > strong cryptographic models that OpenPGP's PKI has (which guards us > against centralized failure modes) to adopt a completely centralized > model that DNSSEC brings us, then we could consider a hybrid model of > trust where individual users have control over who to trust to verify > authenticity, but also have the flexibility to delegate trust where they > desire. STEED is introducing an additional method how certificates reach users and how to gain some trust. Any user or organisation can opt to use other methods like a web-of-trust or centralised X509 PKI structures and everything in between. The progress STEED promisses is that in the easy setting, there is no user interaction, but still the security of the email messages is significantly higher. If the other communication partner choses to use stricter settings, it can do so deliberately. The good part is: There are more communication partners. Best, Bernhard -- Managing Director + Owner: www.Intevation.net <- A Free Software Company Kolabsys.com: Board Member FSFE.org: Founding GA Member 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 bernhard at intevation.de Mon Oct 31 09:37:20 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 31 Oct 2011 09:37:20 +0100 Subject: web for: STEED - Usable end-to-end encryption In-Reply-To: <201110211413.50637.bernhard@intevation.de> References: <87ty774hf2.fsf@vigenere.g10code.de> <4E9EE9B9.40202@ruhr-uni-bochum.de> <201110211413.50637.bernhard@intevation.de> Message-ID: <201110310937.20767.bernhard@intevation.de> Am Friday, 21. October 2011 14:13:46 schrieb Bernhard Reiter: > > But the site and/or the paper could > > really do with some diagrams and other technical illustrations. > > True, but it also needs a better explanation to complement the whitepaper. > My suggestion is that we set up a wiki and start getting this crafted. So who does someone get access to the webpages? Would it be okay to set up a MoinMoin wiki somewhere? -- Managing Director + Owner: www.Intevation.net <- A Free Software Company Kolabsys.com: Board Member FSFE.org: Founding GA Member 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: