From superpacko at gmail.com Mon May 2 14:50:13 2011 From: superpacko at gmail.com (Sebastian) Date: Mon, 2 May 2011 09:50:13 -0300 Subject: GPG status msgs for Passphrase Message-ID: Im trying to decrypt using --batch --status-fd=1 and reading from the output, waiting for the NEED_PASSPHRASE msg. The problem is that this msg never appears until the pipe is closed or the passphrase is provided. In fact not even a single msgs is displayed until the passphrase is good or fails. It looks like the output hangs until the passphrase is provided, and so the output is flushed. This is really unconvenient since the goal of this status msgs is to be able to interact with GPG by reading its output msgs. any ideas on this? someone else having the same issue? im running GPG's portable version 1.4 on windows. thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Wed May 4 09:48:59 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 4 May 2011 09:48:59 +0200 Subject: Verify problem with gpgme In-Reply-To: References: Message-ID: <201105040949.00084.bernhard@intevation.de> Am Donnerstag, 28. April 2011 22:56:44 schrieb dabicho: > I am trying to write a small application whose task is to execute a > script only if it is signed by a specific key. > I thought I could use gpgme to verify it and check if the signature's > key has the right name, comment and mail address, I'd also start with gpgme. > but I have not found > a way to read the key data. Here is an older example in pyme that shows how you get the key data of the signatures via gpgme in principle: http://pyme.cvs.sourceforge.net/viewvc/pyme/pyme/examples/verifydetails.py?revision=1.2&view=markup c.op_verify(sig2, file2, plain2) result = c.op_verify_result() index = 0 for sign in result.signatures: index += 1 print "signature", index, ":" print " summary: %#0x" % (sign.summary) print " status: %#0x" % (sign.status) print " timestamp: ", sign.timestamp print " fingerprint:", sign.fpr print " uid: ", c.get_key(sign.fpr, 0).uids[0].uid There are other examples that show how to get details about an certificate. The gpgme documentation is your friend. The certificates should be in your gnupg store already. Hope this helps, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed May 4 09:39:06 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 4 May 2011 09:39:06 +0200 Subject: GPG status msgs for Passphrase In-Reply-To: References: Message-ID: <201105040939.06906.bernhard@intevation.de> Am Montag, 2. Mai 2011 14:50:13 schrieb Sebastian: > Im trying to decrypt using --batch --status-fd=1 and reading from the > output, waiting for the NEED_PASSPHRASE msg. The problem is that this msg > never appears until the pipe is closed or the passphrase is provided. In > fact not even a single msgs is displayed until the passphrase is good or > fails. > It looks like the output hangs until the passphrase is provided, and so the > output is flushed. This is really unconvenient since the goal of this > status msgs is to be able to interact with GPG by reading its output msgs. > > any ideas on this? someone else having the same issue? im running GPG's > portable version 1.4 on windows. An alternative is to use gpgme and a more modern GnuPG in Windows, e.g. the version provided by Gpg4win 2.1.0. Gpgme is designed to take care of the process handling of running gpg even on Windows. -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Wed May 4 13:20:15 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 May 2011 13:20:15 +0200 Subject: [admin] No HTML mails please Message-ID: <878vumk900.fsf@vigenere.g10code.de> Hi! I noticed that more and more HTMLs are sent to this list. Most of them are text/html alternative so most users won't even notice. However at least me considers such mails as spam and thus I won't see them (only the replies). Please check the settings of your mail program; it is always possible to switch to "text only". If you want to emphasize something, there are easy ways to do this in plain text: _underline_ or /italics/ or *bold* are written by enclosing the words in underscore, slashes or asterisk. HTML mails are a possible security problem and text+html bloats the message by duplicating the information. It also wastes server resources. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon May 9 20:58:29 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 May 2011 20:58:29 +0200 Subject: Bug in mimemaker.c found. Message-ID: <871v07r99m.fsf@vigenere.g10code.de> [Here is a message which didn't made it to the lists.] -----Original Message----- From: Paul Carmon [mailto:pdcarmon at msn.com] Sent: Saturday, April 23, 2011 12:14 PM To: 'gnupg-devel at gnupg.org' Subject: [gpgol] Bug in mimemaker.c found. Dear Sirs: I believe that I have found a bug in mimemaker.c. This error appears to be in both gpgol-1.0.1 and gpgol-1.1.2(the latest available). Inside the function write_b64, you should remove the two lines that follow (lines 370 and 371): if ((rc = write_buffer (sink, outbuf, 4))) return rc; These lines cause corruption for most if not all datalen's that are not a multiple of 3 bytes. For me, this resulted in corrupted attachments to signed messages. With these two lines removed, the data of interest should automatically be written later by the lines that follow (lines 383 and 384): if ((rc = write_buffer (sink, outbuf, outlen))) return rc; This appears to be a bug that was introduced with revision 281 of mimemaker.c. It appears that these lines were overlooked in the transition to code that attempts to reduce the number of calls to write_buffer. Thank you, Paul Carmon From alex at gpgtools.org Thu May 12 00:11:02 2011 From: alex at gpgtools.org (Alexander Willner) Date: Thu, 12 May 2011 00:11:02 +0200 Subject: GnuPG and OS X Message-ID: Hi there, I just had a very nice talk this evening with Werner Koch and I think there some points we should discuss between the GPGTools (OpenPGP for OS X, http://gpgtools.org) and the GnuPG Team. Please reply to all since not everyone is part of this mailing list. 1. GnuPG 1: If I understood correctly you want to get rid of version 1. From my point of view there are several steps: 1.1. Remove the binaries from http://gnupg.org/download/index.en.html and the prominent links from http://gnupg.org etc. 1.2. We can clearly state at http://www.gpgtools.org/macgpg1/index.html that using GnuPG 1 is not a good idea and the user should tell us why he wants to use version 1 instead of version 2. 1.3. We should work together (@Benjamin) on https://github.com/GPGTools/MacGPG2/blob/master/build-script.sh to provide a simple build script to provide a universal binary (PPC, 32bit, 64bit) for OS X. 1.4. If there is anything where GnuPG2 can't replace GnuPG1: this issue should be solved. 2. MacGPGME: We (@Roman) are working on libmacgpg to replace MacGPGME on OS X. There might be valid reasons for that but since MacGPGME is still under development and should be used on all available platforms, we should talk about on how to join the efforts. 3. GnuPG for iOS: There might be some more options for us to bring GnuPG to the iPhone (if we find a developer). Maybe Werner wants to elaborate a bit on this. 4. PKA and GPGMail/ABKey: There is the desire to simplify GnuPG mail encryption by integrating the PKA feature into GPGMail and/or GnuPGME. The idea is to download and use DNS provided keys automatically. I think we're quite close to this with our implementation. Just to give you (gnupg-devel) an overview of what we have: 1. A sophisticated key management application: http://www.gpgtools.org/keychain/index.html 2. A plugin for the integrated mail application: http://www.gpgtools.org/gpgmail/index.html 3. A port of GnuPG1: http://www.gpgtools.org/macgpg1/index.html (because some users requested it) 4. A port of GnuPG2: http://www.gpgtools.org/macgpg2/index.html (also there is no PPC version) 5. A plugin for the global context menu: http://www.gpgtools.org/gpgservices/index.html 6. A simple javascript implementation of OpenPGP for mobile phones: http://www.gpgtools.org/mobile/index.html 7. A big installer that includes 1, 2, 4, and 5. It also fixes many possible issue automatically that a user might have. 8. An implementation of MacGPGME (https://github.com/GPGMail/macgpgme) and Libmacgpg (https://github.com/GPGTools/Libmacgpg) which is used by all above mentioned tools. @Werner: I hope I've not forgotten anything. Best regards and to a successful cooperation, Alex From aoz.syn at gmail.com Thu May 12 01:41:12 2011 From: aoz.syn at gmail.com (RB) Date: Wed, 11 May 2011 17:41:12 -0600 Subject: GnuPG and OS X In-Reply-To: References: Message-ID: On Wed, May 11, 2011 at 16:11, Alexander Willner wrote: > 1. GnuPG 1: If I understood correctly you want to get rid of version My understanding from prior discussions on this list was that GnuPG 1.x wasn't going anywhere any time soon. Specifically, the use-case of embedded environments (initrd decrypting FDE keys was my example) makes 1.x far more desirable and manageable. Beyond that, the formulation of standardized and well-working tools for the OS X environment is laudable. As a current GPGMail user and veteran of its first abandonment, I look forward to greater integration into the core GnuPG communities. From nd at syndicat.com Thu May 12 09:05:46 2011 From: nd at syndicat.com (Niels Dettenbach) Date: Thu, 12 May 2011 09:05:46 +0200 Subject: GnuPG and OS X In-Reply-To: References: Message-ID: <201105120905.50726.nd@syndicat.com> Am Donnerstag 12 Mai 2011, 00:11:02 schrieb Alexander Willner: > 3. GnuPG for iOS: There might be some more options for us to bring > GnuPG to the iPhone (if we find a developer). Maybe Werner wants to > elaborate a bit on this. ...if not on the plan yet, i just want to add GnuPG for Android here. cheers, NIels. -- --- Niels Dettenbach --- Syndicat IT&Internet http://www.syndicat.com T.-Muentzer.-Str. 2, 37308 Heilbad Heiligenstadt - DE --- Kryptoinfo: PGP public key ID 651CA20D Fingerprint: 55E0 4DCD B04C 4A49 1586 88AE 54DC 4465 651C A20D https://syndicat.com/pub_key.asc --- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From gniibe at fsij.org Fri May 13 05:15:51 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 13 May 2011 12:15:51 +0900 Subject: Gnuk version 0.12 Message-ID: <1305256551.3581.14.camel@latx1.gniibe.org> Hi, Gnuk version 0.12 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. Highlights are (in gnuk-0.12/NEWS): * Admin-less mode is supported The OpenPGP card specification assumes existence of a security officer (admin), who has privilege to manage the card. On the other hand, many use cases of Gnuk are admin == user. Thus, Gnuk now supports "admin-less" mode. In this mode, user can get privilege with the password of PW1. At the initialization of the card, Gnuk becomes compatible mode by setting PW3. Without setting PW3, it becomes "admin-less" mode by setting PW1. * tool/gnuk_put_binary.py now uses pyscard Instead of PyUSB, it uses Python binding of PC/SC. PyUSB version is still available as tool/gnuk_put_binary_libusb.py. * Logo for Gnuk is updated * Gnuk Sticker SVG is available And we have FAQ now (in gnuk-0.12/README): Q0: How Gnuk USB Token is superior than other solutions (OpenPGP card 2.0, GPF Crypto Stick, etc) ? http://www.g10code.de/p-card.html http://www.privacyfoundation.de/crypto_stick/ A0: IMRHO, not quite. There is no ready-to-use out-of-box product. (It is welcome for me that some vendor will manufacture Gnuk USB Token. Even I can help design of hardware, if needed.) Good points are: * If you have skill of electronics and like DIY, you can build Gnuk Token cheaper (see Q8-A8). * You can study Gnuk to modify and to enhance. For example, you can implement your own authentication method with some sensor such as acceleration sensor. * It is "of Free Software"; Gnuk is distributed under GPLv3+, "by Free Software"; Gnuk development requires only Free Software (GNU Toolchain, Python, etc.), "for Free Software"; Gnuk supports GnuPG. Q1: What's kind of key algorithm is supported? A1: Gnuk only supports 2048-bit RSA. Q2: How long does it take for digital signing? A2: It takes two seconds or so. Q3: What's your recommendation for target board? A3: Orthodox choice is Olimex STM32-H103. If you have skill of electronics and like DIY, STM32 part of STM8S Discovery Kit might be the best choice. Q4: What's version of GnuPG are you using? A4: In Debian GNU/Linux system, I use gnupg 1.4.11-3 and gnupg-agent 2.0.14-2 (in sid). With older versions, you can only sign with SHA1. See: http://www.fsij.org/gnuk/gnupg2-fixes-needed Q5: What's version of pcscd and libccid are you using? A5: In Debian GNU/Linux system, I use pcscd 1.5.5-4 and libccid 1.3.11-2, which is in squeeze. Note that you need to edit /etc/libccid_Info.plist when using libccid (< 1.4.1). Q6: What kinds of hardware is required for development? A6: You need a target board plus a JTAG debugger. If you just want to test Gnuk for target boards with DfuSe, JTAG debugger is not the requirement. Note that for real use, you need JTAG debugger to enable flash ROM protection. Q7: How much does it cost? A7: Olimex STM32-H103 plus ARM-USB-TINY-H cost 70 Euro or so. Q8: How much does it cost for DIY version? A8: STM8S Discovery Kit costs 750 JPY (< $10 USD) only. You can build your own JTAG debugger using FTDI2232 module (1450 JPY), see: http://www.fsij.org/gnuk/jtag_dongle_ftdi2232 Q9: I got an error like "gpg: selecting openpgp failed: ec=6.108", what's up? A9: GnuPG's SCDaemon has problems for handling insertion/removal of card/reader (problems are fixed in trunk). When your newly inserted token is not found by GnuPG, try killing scdaemon and let it to be invoked again. I do: $ killall -9 scdaemon and confirm scdaemon doesn't exist, then, $ gpg-connect-agent learn /bye -- -------------- 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 gniibe at fsij.org Fri May 13 08:47:23 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 13 May 2011 15:47:23 +0900 Subject: OpenPGP card specification 2.0 improvement? Message-ID: <1305269243.3581.61.camel@latx1.gniibe.org> Hi, While using Gnuk USB Token, I found an issue of changing password. I changed PW1, but I mistakenly put original PW1 as "12345678" while correct one was "123456". Since the prefix is same, password change succeeded, adding "78" at the beginning for new PW1. I noticed this after I failed to be authenticated by new PW1, and saw debug log. In the specification, section 7.2.3 CHANGE REFERENCE DATA says: The length of the existing password is known in the card, so that neither a delimiter nor padding for filling up fixed formats is necessary. This is problem. I think delimiter is needed so that it can detect wrong input for the existing password. -- From squalyl at gmail.com Fri May 13 09:52:30 2011 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Fri, 13 May 2011 09:52:30 +0200 Subject: OpenPGP card specification 2.0 improvement? In-Reply-To: <1305269243.3581.61.camel@latx1.gniibe.org> References: <1305269243.3581.61.camel@latx1.gniibe.org> Message-ID: Hi, This is true. Additionnaly, the C4 tag only gives the *maximum* length for each pin, not the exact length. the data in CHANGE REF DATA should be LV coded, with one byte giving the pin length : 00 24 00 8X XX as an alternative, we could have a GET DATA tag with the actual pin lengths. Sebastien On Fri, May 13, 2011 at 8:47 AM, NIIBE Yutaka wrote: > Hi, > > While using Gnuk USB Token, I found an issue of changing password. > > I changed PW1, but I mistakenly put original PW1 as "12345678" while > correct one was "123456". Since the prefix is same, password change > succeeded, adding "78" at the beginning for new PW1. I noticed this > after I failed to be authenticated by new PW1, and saw debug log. > > In the specification, section 7.2.3 CHANGE REFERENCE DATA says: > > The length of the existing password is known in the card, so that > neither a delimiter nor padding for filling up fixed formats is > necessary. > > This is problem. I think delimiter is needed so that it can detect > wrong input for the existing password. > -- > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flameeyes at gmail.com Sun May 15 19:09:00 2011 From: flameeyes at gmail.com (=?UTF-8?q?Diego=20Elio=20Petten=C3=B2?=) Date: Sun, 15 May 2011 19:09:00 +0200 Subject: [gpgme PATCH] build-sys: link libassuan and libgpg-error in gpgme-tool as well. Message-ID: <1305479340-24411-1-git-send-email-flameeyes@gmail.com> Without this change, the binary would result "underlinked", and GNU gold would fail to link it. --- src/Makefile.am | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 18c8b3b..0b240ee 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -240,7 +240,7 @@ libgpgme_qt_la_LIBADD = $(gpgme_res) @LIBASSUAN_LIBS@ @LTLIBOBJS@ \ endif noinst_PROGRAMS = gpgme-tool -gpgme_tool_LDADD = libgpgme.la +gpgme_tool_LDADD = libgpgme.la @LIBASSUAN_LIBS@ @GPG_ERROR_LIBS@ status-table.h : gpgme.h extra-stati.h cat $(builddir)/gpgme.h $(srcdir)extra-stati.h \ -- 1.7.5.rc3 From wk at gnupg.org Mon May 16 14:54:17 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 May 2011 14:54:17 +0200 Subject: GnuPG and OS X In-Reply-To: (Alexander Willner's message of "Thu, 12 May 2011 00:11:02 +0200") References: Message-ID: <874o4ux0ue.fsf@vigenere.g10code.de> On Thu, 12 May 2011 00:11, alex at gpgtools.org said: > 1. GnuPG 1: If I understood correctly you want to get rid of version > 1. From my point of view there are several steps: > 1.1. Remove the binaries from http://gnupg.org/download/index.en.html I just did that. > and the prominent links from http://gnupg.org etc. It currently reads: GnuPG comes in two flavours: 1.4.11 is the well known and portable standalone version, whereas 2.0.17 is the enhanced and somewhat harder to build version. any suggestions on how to reformulate this text? 1.4.11 shall be mentioned but not as prominent as today. > 3. GnuPG for iOS: There might be some more options for us to bring > GnuPG to the iPhone (if we find a developer). Maybe Werner wants to > elaborate a bit on this. I have no intention to voluntary work on this given that this platform pretty much locks out all kind of free software. For example see the recent problems with vlc. > 4. PKA and GPGMail/ABKey: There is the desire to simplify GnuPG mail I'll comment o this later. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon May 16 14:58:42 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 May 2011 14:58:42 +0200 Subject: OpenPGP card specification 2.0 improvement? In-Reply-To: <1305269243.3581.61.camel@latx1.gniibe.org> (NIIBE Yutaka's message of "Fri, 13 May 2011 15:47:23 +0900") References: <1305269243.3581.61.camel@latx1.gniibe.org> Message-ID: <87zkmmvm2l.fsf@vigenere.g10code.de> On Fri, 13 May 2011 08:47, gniibe at fsij.org said: > This is problem. I think delimiter is needed so that it can detect > wrong input for the existing password. However, this is standard ISO 7816 behaviour. I know several cards which do it this way. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue May 17 02:31:33 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 17 May 2011 09:31:33 +0900 Subject: OpenPGP card specification 2.0 improvement? In-Reply-To: <87zkmmvm2l.fsf@vigenere.g10code.de> References: <1305269243.3581.61.camel@latx1.gniibe.org> <87zkmmvm2l.fsf@vigenere.g10code.de> Message-ID: <1305592293.2407.0.camel@latx1.gniibe.org> 2011-05-16 Werner Koch wrote: > However, this is standard ISO 7816 behaviour. I know several cards > which do it this way. Thanks, I see. When a card only supports fixed length of PIN input, host program can check if the length of PIN input is correct. In this case, there is no problem. I think that fixed length PIN input is virtually standard for most of usages. If a card supports variable length of PIN, it would be better to have format to specify length of input on host side. -- From john.wyzer at gmx.de Tue May 17 22:54:43 2011 From: john.wyzer at gmx.de (John Wyzer) Date: Tue, 17 May 2011 22:54:43 +0200 Subject: pinentry suggestion Message-ID: <1305665355-sup-2647@localhost> I often have the problem that pinentry-gtk-2 pops up and asks for a passphrase for some key. Now I may have several processes running that should be fine asking for a key - but the pinentry popup does not tell me for which purpose the key is being requested. It could be any program and I always have an awkward feeling while entering the passphrase whithout knowing where it goes. It would be very helpful to include a very dumbed down call trace listing the programs that lead to the passphrase being required. Does that sound sensible? Best regards, John. From mailinglisten at hauke-laging.de Wed May 18 00:08:01 2011 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 18 May 2011 00:08:01 +0200 Subject: pinentry suggestion In-Reply-To: <1305665355-sup-2647@localhost> References: <1305665355-sup-2647@localhost> Message-ID: <201105180008.02507.mailinglisten@hauke-laging.de> Am Dienstag, 17. Mai 2011, 22:54:43 schrieb John Wyzer: > It would be very helpful to include a very dumbed down call trace listing > the programs that lead to the passphrase being required. > > Does that sound sensible? We had a discussion some time ago after I had asked for something similar: I wanted to be noticed when a cached passphrase is used. That was denied with the argument that there was no security gain in it (but rather an illusion of additional security) because desktop environments and even OSes have so many security problems that it would be easy for a malicious process to fake such a notice. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Wed May 18 14:54:00 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 May 2011 14:54:00 +0200 Subject: OpenPGP card specification 2.0 improvement? In-Reply-To: <1305592293.2407.0.camel@latx1.gniibe.org> (NIIBE Yutaka's message of "Tue, 17 May 2011 09:31:33 +0900") References: <1305269243.3581.61.camel@latx1.gniibe.org> <87zkmmvm2l.fsf@vigenere.g10code.de> <1305592293.2407.0.camel@latx1.gniibe.org> Message-ID: <877h9ob253.fsf@vigenere.g10code.de> On Tue, 17 May 2011 02:31, gniibe at fsij.org said: > If a card supports variable length of PIN, it would be better to have > format to specify length of input on host side. The standard does not allow for this. Hwoever there is a simple workaround: Do a VERIFY for the old PIN first to see whether it is correct and only then assemble the CHANGEREFERENCEDATA. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From squalyl at gmail.com Wed May 18 15:04:58 2011 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Wed, 18 May 2011 15:04:58 +0200 Subject: OpenPGP card specification 2.0 improvement? In-Reply-To: <877h9ob253.fsf@vigenere.g10code.de> References: <1305269243.3581.61.camel@latx1.gniibe.org> <87zkmmvm2l.fsf@vigenere.g10code.de> <1305592293.2407.0.camel@latx1.gniibe.org> <877h9ob253.fsf@vigenere.g10code.de> Message-ID: ISO7816-4-2005 allows a CHANGE REFERENCE DATA without the old data, by setting P1=01h The spec could use this version, and require the previous verification of the pin by VERIFY PIN. With the current spec, the actual length of the PIN shall be available somewhere. The current data only indicates the maximum length, thus implying the PIN length is variable, but CHANGE REFERENCE DATA does not allow this. Speaking of spec updates, I have more ideas, mainly the AID shall not contain the serial number and the card shall use files instead of data objects. Is a v3 spec planned for some day? Regards Sebastien Lorquet On Wed, May 18, 2011 at 2:54 PM, Werner Koch wrote: > On Tue, 17 May 2011 02:31, gniibe at fsij.org said: > > > If a card supports variable length of PIN, it would be better to have > > format to specify length of input on host side. > > The standard does not allow for this. Hwoever there is a simple > workaround: Do a VERIFY for the old PIN first to see whether it is > correct and only then assemble the CHANGEREFERENCEDATA. > > > Shalom-Salam, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed May 18 15:47:42 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 May 2011 15:47:42 +0200 Subject: OpenPGP card specification 2.0 improvement? In-Reply-To: (=?utf-8?Q?=22S=C3=A9bastien?= Lorquet"'s message of "Wed, 18 May 2011 15:04:58 +0200") References: <1305269243.3581.61.camel@latx1.gniibe.org> <87zkmmvm2l.fsf@vigenere.g10code.de> <1305592293.2407.0.camel@latx1.gniibe.org> <877h9ob253.fsf@vigenere.g10code.de> Message-ID: <87y6249l35.fsf@vigenere.g10code.de> On Wed, 18 May 2011 15:04, squalyl at gmail.com said: > The spec could use this version, and require the previous verification of > the pin by VERIFY PIN. That would be an incompatible change and doesn't have any benefit. > With the current spec, the actual length of the PIN shall be available > somewhere. The current data only indicates the maximum length, thus implying > the PIN length is variable, but CHANGE REFERENCE DATA does not allow this. The length of the PIN is indeed variable. Sure it allows that. > Speaking of spec updates, I have more ideas, mainly the AID shall not > contain the serial number and the card shall use files instead of data > objects. Is a v3 spec planned for some day? Nope. The new ISO drafts even introduces extended object functions and that is what we might use in the next revision. There won't be a stupid old file system interface. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From squalyl at gmail.com Wed May 18 15:53:20 2011 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Wed, 18 May 2011 15:53:20 +0200 Subject: OpenPGP card specification 2.0 improvement? In-Reply-To: <87y6249l35.fsf@vigenere.g10code.de> References: <1305269243.3581.61.camel@latx1.gniibe.org> <87zkmmvm2l.fsf@vigenere.g10code.de> <1305592293.2407.0.camel@latx1.gniibe.org> <877h9ob253.fsf@vigenere.g10code.de> <87y6249l35.fsf@vigenere.g10code.de> Message-ID: Okay, that was just my 2 cents =) Sebastien On Wed, May 18, 2011 at 3:47 PM, Werner Koch wrote: > On Wed, 18 May 2011 15:04, squalyl at gmail.com said: > > > The spec could use this version, and require the previous verification of > > the pin by VERIFY PIN. > > That would be an incompatible change and doesn't have any benefit. > > > With the current spec, the actual length of the PIN shall be available > > somewhere. The current data only indicates the maximum length, thus > implying > > the PIN length is variable, but CHANGE REFERENCE DATA does not allow > this. > > The length of the PIN is indeed variable. Sure it allows that. > > > Speaking of spec updates, I have more ideas, mainly the AID shall not > > contain the serial number and the card shall use files instead of data > > objects. Is a v3 spec planned for some day? > > Nope. The new ISO drafts even introduces extended object functions and > that is what we might use in the next revision. There won't be a stupid > old file system interface. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed May 18 18:19:43 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 May 2011 18:19:43 +0200 Subject: pinentry suggestion In-Reply-To: <1305665355-sup-2647@localhost> (John Wyzer's message of "Tue, 17 May 2011 22:54:43 +0200") References: <1305665355-sup-2647@localhost> Message-ID: <8762p89e1s.fsf@vigenere.g10code.de> On Tue, 17 May 2011 22:54, john.wyzer at gmx.de said: > It would be very helpful to include a very dumbed down call trace listing the > programs that lead to the passphrase being required. > > Does that sound sensible? Kind of. I run a uucp job over ssh and thus a pinentry pops up every now and then. On rare occasions I was testing some stuff and not sure whether the popped up pinentry was due to the cron job or due to my testing. A call trace is not what I ciew as usefull. However a title bar with the name of the program responsible for popping up the pinentry may be useful and won't harm. It is merely a convenience thing and in no way a security featre. I'd like to have something like this. We could implement that by overloading our PINENTRY_LAUNCHED notification which goes back all the way to gpgme. But that is not a clea solution. What I have in mind is a feature I would call session-title: It will be implemented as an optional Assuan command to finally set a session title for an gpg-agent connection. If gpg-agent knows a session-title it can inform pinentry about it and pinentry may use it. Implementing this is pretty easy; however we need to add a new function to gpgme. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Thu May 19 01:57:34 2011 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 19 May 2011 01:57:34 +0200 Subject: pinentry suggestion In-Reply-To: <8762p89e1s.fsf@vigenere.g10code.de> References: <1305665355-sup-2647@localhost> <8762p89e1s.fsf@vigenere.g10code.de> Message-ID: <4DD45CEE.6090109@ruhr-uni-bochum.de> On 05/18/2011 06:19 PM, Werner Koch wrote: > On Tue, 17 May 2011 22:54, john.wyzer at gmx.de said: > A call trace is not what I ciew as usefull. However a title bar with > the name of the program responsible for popping up the pinentry may be > useful and won't harm. It is merely a convenience thing and in no way a > security featre. I'd like to have something like this. The problem is that you can not declare it not to be a security feature by fiat. Users will perceive it as a security feature or not depending on the whole context and their expectations. If they do rely on a bit, we are in a bit of a mess here, quite frankly. Of course, this problem is not specific to gnupg/pinentry. It is a security and usability issue that permeates the whole user session. Because these problems are so severe and known for a long time, we have to be pessimistic about the ability to find simple solutions on the desktop (the story is different on recent mobile devices). I think the best that can be achieved in a simple manner is to make sure that a cached passphrase is not used in quick succession many times without the user being able to notice this activity. If there is a malicious program, it may be able to trick the user into signing a message or two under false pretenses, but it should not be able to sign hundreds or thousands without raising suspicion. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Thu May 19 02:05:11 2011 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 19 May 2011 02:05:11 +0200 Subject: pinentry suggestion In-Reply-To: <4DD45CEE.6090109@ruhr-uni-bochum.de> References: <1305665355-sup-2647@localhost> <8762p89e1s.fsf@vigenere.g10code.de> <4DD45CEE.6090109@ruhr-uni-bochum.de> Message-ID: <4DD45EB7.3050804@ruhr-uni-bochum.de> On 05/19/2011 01:57 AM, Marcus Brinkmann wrote: > On 05/18/2011 06:19 PM, Werner Koch wrote: >> On Tue, 17 May 2011 22:54, john.wyzer at gmx.de said: >> A call trace is not what I ciew as usefull. However a title bar with >> the name of the program responsible for popping up the pinentry may be >> useful and won't harm. It is merely a convenience thing and in no way a >> security featre. I'd like to have something like this. > > The problem is that you can not declare it not to be a security feature by > fiat. Users will perceive it as a security feature or not depending on the > whole context and their expectations. If they do rely on a bit, we are in a > bit of a mess here, quite frankly. > > Of course, this problem is not specific to gnupg/pinentry. It is a security > and usability issue that permeates the whole user session. The consequence I forgot to add is that you can add such a string or not, it doesnt matter. Whatever mechanism would be chosen could be subverted by a malicious user due to the lack of security boundaries in the users session. The below is meant to address the more general security problem that an identifier could be perceived to solve (even if not intended to). > Because these problems are so severe and known for a long time, we have to be > pessimistic about the ability to find simple solutions on the desktop (the > story is different on recent mobile devices). I think the best that can be > achieved in a simple manner is to make sure that a cached passphrase is not > used in quick succession many times without the user being able to notice this > activity. If there is a malicious program, it may be able to trick the user > into signing a message or two under false pretenses, but it should not be able > to sign hundreds or thousands without raising suspicion. > > Thanks, > Marcus > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From mailinglisten at hauke-laging.de Thu May 19 02:25:42 2011 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 19 May 2011 02:25:42 +0200 Subject: pinentry suggestion In-Reply-To: <4DD45CEE.6090109@ruhr-uni-bochum.de> References: <1305665355-sup-2647@localhost> <8762p89e1s.fsf@vigenere.g10code.de> <4DD45CEE.6090109@ruhr-uni-bochum.de> Message-ID: <201105190225.47441.mailinglisten@hauke-laging.de> Am Donnerstag, 19. Mai 2011, 01:57:34 schrieb Marcus Brinkmann: > The problem is that you can not declare it not to be a security feature by > fiat. Users will perceive it as a security feature or not depending on the > whole context and their expectations. If they do rely on a bit, we are in a > bit of a mess here, quite frankly. A good solution might be not to make this the default behaviour but to add an option: --pinentry-show-proc The pinentry message could be extended by a hint like "(see --pinentry-show- proc for the demanding process)" if this option is not given. "--pinentry-show-proc yes" adds the info to the pinentry message, "--pinentry- show-proc no" suppresses the hint. The documentation states clearly the problem you described and also says that making "--pinentry-show-proc yes" the default configuration would be regarded as a security risk. That should prevent the distros from doing that. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu May 19 09:55:58 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 May 2011 09:55:58 +0200 Subject: pinentry suggestion In-Reply-To: <4DD45CEE.6090109@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "19 May 2011 01:57:34 +0200") References: <1305665355-sup-2647@localhost> <8762p89e1s.fsf@vigenere.g10code.de> <4DD45CEE.6090109@ruhr-uni-bochum.de> Message-ID: <8739kb86pd.fsf@vigenere.g10code.de> On Thu, 19 May 2011 01:57, marcus.brinkmann at ruhr-uni-bochum.de said: > The problem is that you can not declare it not to be a security feature by > fiat. Users will perceive it as a security feature or not depending on the Right. However, I neither view the security features of a desktop (ACL, root permissions, kernel permissions) as a strong measure against attacks. In my threat model you own the box as soon as you get the permission to execute any program of your choice on the box. This is due to the fact that it is virtually impossible to avoid local exploits. In this regard desktop boxes are not different than smartphones. The architecture of GnuPG may only help against such attacks if we move gpg-agent to a small dedicated box. Of course we can't use a simple title string then to show which process requests a private key operation. You have a similar problem with PINpad equipped card readers - you'll never know which process triggered the PIN query and thus the signature creation or decrypt operation. With a little bit of social engineering it is easy to trick a user to sign a different document or to decrypt a mail. > story is different on recent mobile devices). I think the best that can be > achieved in a simple manner is to make sure that a cached passphrase is not > used in quick succession many times without the user being able to notice this That would fail on my box. I have scripts which open ssh connections to several other boxes quite often - they rely on passphrase caching. Further malware may well be aware of the fact that your proposed countermeasure is in place and delay all actions. I bet spam bots do that already to foil similar countermeasures at ISP's mail smarthosts Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Thu May 19 11:05:49 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 19 May 2011 11:05:49 +0200 Subject: GnuPG and OS X In-Reply-To: References: Message-ID: <201105191105.52817.bernhard@intevation.de> Alex, thanks for the overview and for coordination the effort, I believe this is really important to promote end-to-end email encryption. Am Donnerstag, 12. Mai 2011 00:11:02 schrieb Alexander Willner: > 1.2. We can clearly state at > http://www.gpgtools.org/macgpg1/index.html that using GnuPG 1 is not a > good idea and the user should tell us why he wants to use version 1 > instead of version 2. GnuPG 1 is for very special usecases only, in my view it should be phased out whereever possible. Even for small and tiny cases. I believe this is important as is promoting the use of gpgme everywhere. It is the only way we can iron out the problems over time. Am Montag, 16. Mai 2011 14:54:17 schrieb Werner Koch: > > and the prominent links from http://gnupg.org etc. > > It currently reads: > > GnuPG comes in two flavours: 1.4.11 is the well known and portable > standalone version, whereas 2.0.17 is the enhanced and somewhat harder > to build version. > > any suggestions on how to reformulate this text? 1.4.11 shall be > mentioned but not as prominent as today. My shot at it: Version 2.0.17 the current, stable and recommended version of GnuPG. For developers: If your system is far-off from current standards or very reduced maybe, GnuPG might be hard to build and run. This case you can try the maintained, old branch: Version 1.4.11 Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu May 19 15:49:10 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 19 May 2011 15:49:10 +0200 Subject: gnupg git build requirements: libgpg-error and transfig Message-ID: <201105191549.15399.bernhard@intevation.de> It seem the checked libgpg-error >= 1.8 is not enough for gnupg git de7cfc0c9b452d5e42346b2e598d44626b166865 Date: Thu May 12 01:34:04 2011 +0200 call-dirmngr.c: In function ?gpg_dirmngr_ks_get?: call-dirmngr.c:424: error: ?GPG_ERR_TOO_MANY? undeclared (first use in this function) Also fig2dev from transfig seems to be required now. -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu May 19 17:50:07 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 May 2011 17:50:07 +0200 Subject: gnupg git build requirements: libgpg-error and transfig In-Reply-To: <201105191549.15399.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 19 May 2011 15:49:10 +0200") References: <201105191549.15399.bernhard@intevation.de> Message-ID: <87liy27kr4.fsf@vigenere.g10code.de> On Thu, 19 May 2011 15:49, bernhard at intevation.de said: > It seem the checked libgpg-error >= 1.8 is not enough Quite possible; it is the devlopment branch. We can't update all the requirements all the time. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Fri May 20 09:27:57 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 20 May 2011 09:27:57 +0200 Subject: gnupg git build requirements: libgpg-error and transfig In-Reply-To: <87liy27kr4.fsf@vigenere.g10code.de> References: <201105191549.15399.bernhard@intevation.de> <87liy27kr4.fsf@vigenere.g10code.de> Message-ID: <201105200928.00455.bernhard@intevation.de> Am Donnerstag, 19. Mai 2011 17:50:07 schrieb Werner Koch: > On Thu, 19 May 2011 15:49, bernhard at intevation.de said: > > It seem the checked libgpg-error >= 1.8 is not enough > > Quite possible; it is the devlopment branch. ?We can't update all the > requirements all the time. I know, it is just a hassle for someone like me, who likes to do a short build to check some things. So I thought, you would be interested in these dependency issues when we stumble upon them. ;) -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Fri May 20 10:00:42 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 May 2011 10:00:42 +0200 Subject: gnupg git build requirements: libgpg-error and transfig In-Reply-To: <201105200928.00455.bernhard@intevation.de> (Bernhard Reiter's message of "Fri, 20 May 2011 09:27:57 +0200") References: <201105191549.15399.bernhard@intevation.de> <87liy27kr4.fsf@vigenere.g10code.de> <201105200928.00455.bernhard@intevation.de> Message-ID: <874o4p7qdx.fsf@vigenere.g10code.de> On Fri, 20 May 2011 09:27, bernhard at intevation.de said: > to check some things. So I thought, you would be interested in these > dependency issues when we stumble upon them. ;) Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jeanjacquesbrucker at gmail.com Wed May 25 19:21:03 2011 From: jeanjacquesbrucker at gmail.com (Jean-Jacques Brucker) Date: Wed, 25 May 2011 19:21:03 +0200 Subject: needs in OpenPGP to use it for a bitcoin replacement. Message-ID: <201105251921.16544.jeanjacquesbrucker@gmail.com> Hi, i am working on a replacement for bitcoin using OpenPGP. But to do so properly I would like to add some things in the RFC 4880. The minimum needed is to add a flag in the section 5.2.3.1. : > 5.2.3.1. Signature Subpacket Specification > (...) > The value of the subpacket type octet may be: > (...) > 33 = Recipient And so : > 5.2.3.27. Recipient > > (8-octet Key ID) > > The OpenPGP Key ID of the recipient of the signature. > > This subpacket may be used for signing chain, and so in the hashed > subpacket data set. This subpacket may be used many times if there > are different recipients. I have compiled the git master branch of GnuPG and began studying the source. But I sorely lacking time to produce a patch for making a version (a git branch ?) of gpg with this feature. So if I want somebody else to do it, I should explain what is the project, its aim and its principles. Its aim is to do better than bitcoin. How to ? On a moral plan by applying a social credit (http://en.wikipedia.org/wiki/Social_Credit) instead of a system were "the first are the best served" Rules of money creation are not so complicated but implies some economical reflexions which does need not our computing skills. On a technical plan (that is the point were I require you attention, and I'd like some guru to get involved), the principles are : - Each human is certified by the OpenPGP web of trust of the previous humans (on the OpenPGP uid with the udid1 field, unique and minimum required to make the link with a Civil Status). - A transaction is to sign the signature chain associated to units of currency (udc-bills). - All currency units are stored on the network. The principles are simple but imply some questions/problem wich i like to discuss (And it's hard to find skilled fellow for that). Our website is a wiki : http://www.open-udc.org Our mailing list : open-udc at googlegroups.com (our git is almost empty). -- Jean-Jacques B. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part. URL: From jeanjacquesbrucker at gmail.com Wed May 25 20:52:53 2011 From: jeanjacquesbrucker at gmail.com (Jbar) Date: Wed, 25 May 2011 20:52:53 +0200 Subject: needs in OpenPGP to use it for a bitcoin replacement. In-Reply-To: References: <201105251921.16544.jeanjacquesbrucker@gmail.com> Message-ID: <201105252053.01339.jeanjacquesbrucker@gmail.com> Le mercredi 25 mai 2011 19:30:15, Jerome Baum a ?crit : > On Wed, May 25, 2011 at 19:21, Jean-Jacques Brucker < > > jeanjacquesbrucker at gmail.com> wrote: > > Hi, i am working on a replacement for bitcoin using OpenPGP. > > Why? Even if bitcoin is an improvement comparing to the previous monetary systems, it still has, economically and socially speaking, many defects. There are enough rooms to speak about them in an other place (forums, blogs ...). But bitcoin has also technicals defects, the two most important are : - a amount of bitcoin is only stored by only one peer at a time t, which mean that bitcoins may easily disapper and that is what already occurs (I did personally lost a few amount of btc, and i had see in the forum that I am not alone). - Transaction are very very slow (I don't have try to pay taxes to the people "with the biggest" CPU power), and this is not a surprise why so : first the proof of work, second there is in fact a third-party for bitcoins : it is the entire network. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From jerome at jeromebaum.com Wed May 25 21:06:54 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Wed, 25 May 2011 21:06:54 +0200 Subject: needs in OpenPGP to use it for a bitcoin replacement. In-Reply-To: <201105252053.01339.jeanjacquesbrucker@gmail.com> References: <201105251921.16544.jeanjacquesbrucker@gmail.com> <201105252053.01339.jeanjacquesbrucker@gmail.com> Message-ID: On Wed, May 25, 2011 at 20:52, Jbar wrote: > Le mercredi 25 mai 2011 19:30:15, Jerome Baum a ?crit : > > On Wed, May 25, 2011 at 19:21, Jean-Jacques Brucker < > > > > jeanjacquesbrucker at gmail.com> wrote: > > > Hi, i am working on a replacement for bitcoin using OpenPGP. > > > > Why? > > But bitcoin has also technicals defects, the two most important are : > > - a amount of bitcoin is only stored by only one peer at a time t, which > mean that bitcoins may easily disapper and that is what already occurs (I > did personally lost a few amount of btc, and i had see in the forum that I > am not alone). > Not sure I see this point. If you loose access to your private key, you always loose your digital money. That's a fact of life, and the reason we do backups. > - Transaction are very very slow (I don't have try to pay taxes to the > people "with the biggest" CPU power), and this is not a surprise why so : > first > the proof of work, second there is in fact a third-party for bitcoins : > it is the entire network. > The proof of work is an essential economic measure in the bitcoin network. How would your proposed system work without a proof of work? Why would anyone join in? On the third-party, there needs to be a third-party for a digital currency to operate. Otherwise I can use one coin multiple times. If that third-party is the whole network (i.e. "the public"), then that's as good as it gets -- no single point of failure or entity w/ too much power. I think the whole bitcoin story is questionable enough. I'm not saying bitcoin can't be successful, but you should be wary and make a careful decision. Everyone has different opinions about it. Adding "yet another system" on top of that won't help. -- Jerome Baum tel +49-1578-8434336 email jerome at jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerome at jeromebaum.com Wed May 25 19:30:15 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Wed, 25 May 2011 19:30:15 +0200 Subject: needs in OpenPGP to use it for a bitcoin replacement. In-Reply-To: <201105251921.16544.jeanjacquesbrucker@gmail.com> References: <201105251921.16544.jeanjacquesbrucker@gmail.com> Message-ID: On Wed, May 25, 2011 at 19:21, Jean-Jacques Brucker < jeanjacquesbrucker at gmail.com> wrote: > > Hi, i am working on a replacement for bitcoin using OpenPGP. > Why? -- Jerome Baum tel +49-1578-8434336 email jerome at jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanjacquesbrucker at gmail.com Thu May 26 00:00:33 2011 From: jeanjacquesbrucker at gmail.com (Jbar) Date: Thu, 26 May 2011 00:00:33 +0200 Subject: needs in OpenPGP to use it for a bitcoin replacement. In-Reply-To: References: <201105251921.16544.jeanjacquesbrucker@gmail.com> <201105252053.01339.jeanjacquesbrucker@gmail.com> Message-ID: <201105260000.39773.jeanjacquesbrucker@gmail.com> > > But bitcoin has also technicals defects, the two most important are : > > - a amount of bitcoin is only stored by only one peer at a time t, which > > > > mean that bitcoins may easily disapper and that is what already occurs > > (I did personally lost a few amount of btc, and i had see in the forum > > that I am not alone). > > Not sure I see this point. If you loose access to your private key, you > always loose your digital money. That's a fact of life, and the reason we > do backups. I have make backups of the private part of my OpenPGP certificate once. With bitcoin u should make backups after each transaction... > > - Transaction are very very slow (I don't have try to pay taxes to the > > > > people "with the biggest" CPU power), and this is not a surprise why so : > > first > > the proof of work, second there is in fact a third-party for bitcoins : > > it is the entire network. > > The proof of work is an essential economic measure in the bitcoin network. > How would your proposed system work without a proof of work? Why would > anyone join in? We will use OpenPGP web of trust and it will be human-based instead of CPU-based. People who think than society in based on humans more than on institutions or CPU should join in. > On the third-party, there needs to be a third-party for a digital currency > to operate. Otherwise I can use one coin multiple times. If that > third-party is the whole network (i.e. "the public"), then that's as good > as it gets -- no single point of failure or entity w/ too much power. Of course we need no single point of failure or entity with too much power, but there is a more efficient alternative than a big single network : A network of networks (of networks of networks...) which mean a tree of network, to be compared with the DNS system tree (and as fast as n^n grow , we don't need a deep tree). > I think the whole bitcoin story is questionable enough. I'm not saying > bitcoin can't be successful, but you should be wary and make a careful > decision. Everyone has different opinions about it. Adding "yet another > system" on top of that won't help. I just want that gnupg manage a new subpacket type octet (cf the section 5.2.3.1. of the RFC 4880) needed for the signing chain feature : "The value of the subpacket type octet may be: (...) 33 = Recipient (...) 5.2.3.27. Recipient (8-octet Key ID) The OpenPGP Key ID of the recipient of the signature. This subpacket may be used for signing chain, and so in the hashed subpacket data set. This subpacket may be used many times if there are different recipients. " -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From dshaw at jabberwocky.com Thu May 26 00:17:58 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 25 May 2011 18:17:58 -0400 Subject: needs in OpenPGP to use it for a bitcoin replacement. In-Reply-To: <201105260000.39773.jeanjacquesbrucker@gmail.com> References: <201105251921.16544.jeanjacquesbrucker@gmail.com> <201105252053.01339.jeanjacquesbrucker@gmail.com> <201105260000.39773.jeanjacquesbrucker@gmail.com> Message-ID: <9E96AFB0-F08A-4192-89DB-7150D02D233C@jabberwocky.com> On May 25, 2011, at 6:00 PM, Jbar wrote: >> I think the whole bitcoin story is questionable enough. I'm not saying >> bitcoin can't be successful, but you should be wary and make a careful >> decision. Everyone has different opinions about it. Adding "yet another >> system" on top of that won't help. > > I just want that gnupg manage a new subpacket type octet (cf the section 5.2.3.1. of the RFC 4880) needed for the signing chain feature : > > "The value of the subpacket type octet may be: > (...) > 33 = Recipient Without going into the details of bitcoin or whether it is a good system or not, and speaking strictly from the OpenPGP protocol perspective, you don't need a new subpacket to get what you want. OpenPGP has a generic key=value notation subpacket (number 20), already supported by GnuPG, which is ideal for what you are trying to do. Just use a notation of something like bitcoin at your-domain.example.com=XXX. David From stefanxe at gmx.net Thu May 26 02:21:15 2011 From: stefanxe at gmx.net (Stefan Xenon) Date: Thu, 26 May 2011 08:21:15 +0800 Subject: OpenPGP card specification 2.0 improvement? In-Reply-To: <87y6249l35.fsf@vigenere.g10code.de> References: <1305269243.3581.61.camel@latx1.gniibe.org> <87zkmmvm2l.fsf@vigenere.g10code.de> <1305592293.2407.0.camel@latx1.gniibe.org> <877h9ob253.fsf@vigenere.g10code.de> <87y6249l35.fsf@vigenere.g10code.de> Message-ID: <4DDD9CFB.5000302@gmx.net> >> Speaking of spec updates, I have more ideas, mainly the AID shall not >> contain the serial number and the card shall use files instead of data >> objects. Is a v3 spec planned for some day? > > Nope. The new ISO drafts even introduces extended object functions and > that is what we might use in the next revision. There won't be a stupid > old file system interface. Any idea when your next revision of OpenPGP Card could be expected? Regards From jerome at jeromebaum.com Thu May 26 13:52:33 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 26 May 2011 13:52:33 +0200 Subject: needs in OpenPGP to use it for a bitcoin replacement. In-Reply-To: <201105260000.39773.jeanjacquesbrucker@gmail.com> References: <201105251921.16544.jeanjacquesbrucker@gmail.com> <201105252053.01339.jeanjacquesbrucker@gmail.com> <201105260000.39773.jeanjacquesbrucker@gmail.com> Message-ID: On Thu, May 26, 2011 at 00:00, Jbar wrote: > > > > But bitcoin has also technicals defects, the two most important are : > > > - a amount of bitcoin is only stored by only one peer at a time t, > which > > > > > > mean that bitcoins may easily disapper and that is what already occurs > > > (I did personally lost a few amount of btc, and i had see in the forum > > > that I am not alone). > > > > Not sure I see this point. If you loose access to your private key, you > > always loose your digital money. That's a fact of life, and the reason we > > do backups. > > I have make backups of the private part of my OpenPGP certificate once. > With bitcoin u should make backups after each transaction... > Isn't this simply because the bitcoin client creates multiple keys and will create new ones for a transaction? Two options: 1. Give up your anonymity and use the same key everywhere. Requires a small change to bitcoin client. 2. Keep your anonymity. Use lots of OpenPGP keys that you need to backup regularly. i.e. If you want the anonymity, you still need to make the backups. If you don't want the anonymity, you're not really creating a bitcoin alternative. > > - Transaction are very very slow (I don't have try to pay taxes to the > > > > > > people "with the biggest" CPU power), and this is not a surprise why so > : > > > first > > > the proof of work, second there is in fact a third-party for bitcoins > : > > > it is the entire network. > > > > The proof of work is an essential economic measure in the bitcoin > network. > > How would your proposed system work without a proof of work? Why would > > anyone join in? > > We will use OpenPGP web of trust and it will be human-based instead of > CPU-based. > People who think than society in based on humans more than on institutions > or CPU should join in. > "How would your proposed system work without a proof of work?" You haven't explained how the currency works. Where do the initial "coins" come from? How are they generated? > On the third-party, there needs to be a third-party for a digital currency > > to operate. Otherwise I can use one coin multiple times. If that > > third-party is the whole network (i.e. "the public"), then that's as good > > as it gets -- no single point of failure or entity w/ too much power. > > Of course we need no single point of failure or entity with too much power, > but there is a more efficient alternative than a big single network : > A network of networks (of networks of networks...) which mean a tree of > network, to be compared with the DNS system tree (and as fast as n^n grow , > we > don't need a deep tree). > If we have a network of networks, I can use the same coin twice -- once in network A, once in network B. Or, I cannot use the coin from one network in another. Or, I need a third-party. A more in-depth description of your proposed system would help, before making requests to change OpenPGP. (As David points out, this isn't even necessary -- nonetheless, you'll probably save yourself lots of time if you just write up a document about this and have others review it, as opposed to "just going ahead".) > I think the whole bitcoin story is questionable enough. I'm not saying > > bitcoin can't be successful, but you should be wary and make a careful > > decision. Everyone has different opinions about it. Adding "yet another > > system" on top of that won't help. > > I just want that gnupg manage a new subpacket type octet ... This isn't what I meant with "yet another system". "Yet another system [like bitcoin]" is "yet another digital currency system", i.e. "yet another choice the user has to make", analogous to "yet another operation system" or "yet another Linux distribution". Not that the ability to choose isn't a good thing. But the shear amount of distributions has been a problem for Linux's market adoption in the past. This has improved as a number of distros have emerged as "significant", but the point remains valid -- don't add a system if you're only making one small change. Document how your system will work, which security features it addresses and how, and share this document with others to get some review. Especially share it with the bitcoin authors! -- Jerome Baum tel +49-1578-8434336 email jerome at jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanjacquesbrucker at gmail.com Thu May 26 17:41:56 2011 From: jeanjacquesbrucker at gmail.com (Jean-Jacques Brucker) Date: Thu, 26 May 2011 17:41:56 +0200 Subject: needs in OpenPGP to use it for a bitcoin replacement. In-Reply-To: References: <201105251921.16544.jeanjacquesbrucker@gmail.com> <201105260000.39773.jeanjacquesbrucker@gmail.com> Message-ID: <201105261741.56889.jeanjacquesbrucker@gmail.com> -- Jean-Jacques B. > Isn't this simply because the bitcoin client creates multiple keys and will > create new ones for a transaction? Two options: > > 1. Give up your anonymity and use the same key everywhere. Requires a small > change to bitcoin client. > > 2. Keep your anonymity. Use lots of OpenPGP keys that you need to backup > regularly. > > i.e. If you want the anonymity, you still need to make the backups. If you > don't want the anonymity, you're not really creating a bitcoin alternative. I don't want anonymity but i want to use (and so to promote) OpenPGP. > > "How would your proposed system work without a proof of work?" > > You haven't explained how the currency works. Where do the initial "coins" > come from? How are they generated? That the main point were we need a bitcoin alternative. Bitcoin don't care about humans, and lacks fairness. Imagine a world with gold mines (I know bitcoin fan like gold) were the mining plan is well know and were the extraction cost nothing and is distributed to each living human (regardless its age, sex, etc...) of this world. That looks like how the money can be generated : Each humans validated by a given OpenPGP web of trust may generate periodically its part of a new monetary mass which is created by the rule defined by the Relative Theory of Money (may be adjusted by the vote of the human in the given OpenPGP web of trust) http://www.creationmonetaire.info/2010/11/theorie-relative-de-la-monnaie-10.html, cf 5th rule of http://www.open-udc.org/en/money_rules (I don't necessary agree with other rules in this page, but a community have to accept common rules, they may be as minimal and democratic as possible, but still remain). The list of humans (OpenPGP KeyID) why satisfy a given web of trust (which web of trust ? of course there is here a problem of entity with too much power to resolve) is publish before a set of money is created. And so is the amount of money that each human may create in this set. example : for the set number nt, there is nh humans in the list, each human can create 2 bills of value 50 and 4 bills of value 10. The first person in the list may use new bills of value 50 numbered 0 to 1 in this set, and new bills of value 10 numbered 0 to 3 in this set, etc ... If a human in the list don't create its part of money, he is supposed to be dead and is (until he comes back to life) removed from the given web of trust. > If we have a network of networks, I can use the same coin twice -- once in > network A, once in network B. Or, I cannot use the coin from one network in > another. Or, I need a third-party. Not if networks are prioritized in a tree structure : /B1 / A --B2 \ \B3 Every B networks watch its root network A, use it to make transaction between them. But network B2 and network A don't care about the money exchanged in network B3. > A more in-depth description of your proposed system would help, before > making requests to change OpenPGP. (As David points out, this isn't even > necessary -- nonetheless, you'll probably save yourself lots of time if you > just write up a document about this and have others review it, as opposed to > "just going ahead".) Indeed David solution is sufficient for the needs. I did think of using the Notation data too, but I did forgot since, (Thanks David to remind me it :-) ) the reason is that it seems dirty to me : I hope I am not alone which want to use OpenPGP for signing chain. > This isn't what I meant with "yet another system". "Yet another system [like > bitcoin]" is "yet another digital currency system", i.e. "yet another choice > the user has to make", analogous to "yet another operation system" or "yet > another Linux distribution". Not that the ability to choose isn't a good > thing. But the shear amount of distributions has been a problem for Linux's > market adoption in the past. This has improved as a number of distros have > emerged as "significant", but the point remains valid -- don't add a system > if you're only making one small change. Document how your system will work, > which security features it addresses and how, and share this document with > others to get some review. Especially share it with the bitcoin authors! > As a bitcoin is now exchanged for 8 $ (https://mtgox.com/trade/history), and the bitcoin authors are the best served in bitcoin ( http://en.wikipedia.org/wiki/File:Total_bitcoins_over_time.png), I am not sure they would like to work for a human-based alternative before selling their bitcoins at a highest price. From jerome at jeromebaum.com Thu May 26 18:46:25 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 26 May 2011 18:46:25 +0200 Subject: needs in OpenPGP to use it for a bitcoin replacement. In-Reply-To: <201105261741.56889.jeanjacquesbrucker@gmail.com> References: <201105251921.16544.jeanjacquesbrucker@gmail.com> <201105260000.39773.jeanjacquesbrucker@gmail.com> <201105261741.56889.jeanjacquesbrucker@gmail.com> Message-ID: On Thu, May 26, 2011 at 17:41, Jean-Jacques Brucker < jeanjacquesbrucker at gmail.com> wrote: > > > "How would your proposed system work without a proof of work?" > > > > You haven't explained how the currency works. Where do the initial > "coins" > > come from? How are they generated? > > That the main point were we need a bitcoin alternative. Bitcoin don't care > about humans, and lacks fairness. > > Imagine a world with gold mines (I know bitcoin fan like gold) Not really a bitcoin fan here, and I think gold is a pretty bad analogy that breaks down very soon. How about coins instead? The idea here is that coins can be generated without limits (i.e. don't need to be mined -- assuming no lack of resources that the coins are made of). > Each humans validated by a given OpenPGP web of trust may generate > periodically its part of a new monetary mass which is created by the rule > defined by the Relative Theory of Money (may be adjusted by the vote of the > human in the given OpenPGP web of trust) > http://www.creationmonetaire.info/2010/11/theorie-relative-de-la-monnaie-10.html, > cf 5th rule of http://www.open-udc.org/en/money_rules (I don't necessary > agree with other rules in this page, but a community have to accept common > rules, they may be as minimal and democratic as possible, but still remain). > > The list of humans (OpenPGP KeyID) why satisfy a given web of trust (which > web of trust ? of course there is here a problem of entity with too much > power to resolve) is publish before a set of money is created. And so is the > amount of money that each human may create in this set. > This is particularly difficult to resolve. A digital currency should allow any two people to trade without having met each other before. Bitcoin allows this, while a WoT-based model requires at the very least a chain between those people and cooperation along the chain. > example : for the set number nt, there is nh humans in the list, each human > can create 2 bills of value 50 and 4 bills of value 10. > The first person in the list may use new bills of value 50 numbered 0 to 1 > in this set, and new bills of value 10 numbered 0 to 3 in this set, etc ... > So, the system doesn't allow new people to come into play after it has been started? > If a human in the list don't create its part of money, he is supposed to > be dead and is (until he comes back to life) removed from the given web of > trust. > Don't get this part. > > If we have a network of networks, I can use the same coin twice -- once > in > > network A, once in network B. Or, I cannot use the coin from one network > in > > another. Or, I need a third-party. > > Not if networks are prioritized in a tree structure : > /B1 > / > A --B2 > \ > \B3 > > Every B networks watch its root network A, use it to make transaction > between them. But network B2 and network A don't care about the money > exchanged in network B3. > So say I am in network B3 and you are in B1, how do I send you money? > > A more in-depth description of your proposed system would help, before > > making requests to change OpenPGP. (As David points out, this isn't even > > necessary -- nonetheless, you'll probably save yourself lots of time if > you > > just write up a document about this and have others review it, as opposed > to > > "just going ahead".) > > Indeed David solution is sufficient for the needs. I did think of using the > Notation data too, but I did forgot since, (Thanks David to remind me it :-) > ) the reason is that it seems dirty to me : > > I hope I am not alone which want to use OpenPGP for signing chain. > For a first implementation you'll have to go with notations if you want to use OpenPGP. Otherwise you get compatibility issues etc. > > This isn't what I meant with "yet another system". "Yet another system > [like > > bitcoin]" is "yet another digital currency system", i.e. "yet another > choice > > the user has to make", analogous to "yet another operation system" or > "yet > > another Linux distribution". Not that the ability to choose isn't a good > > thing. But the shear amount of distributions has been a problem for > Linux's > > market adoption in the past. This has improved as a number of distros > have > > emerged as "significant", but the point remains valid -- don't add a > system > > if you're only making one small change. Document how your system will > work, > > which security features it addresses and how, and share this document > with > > others to get some review. Especially share it with the bitcoin authors! > > > > As a bitcoin is now exchanged for 8 $ (https://mtgox.com/trade/history), > and the bitcoin authors are the best served in bitcoin ( > http://en.wikipedia.org/wiki/File:Total_bitcoins_over_time.png), I am not > sure they would like to work for a human-based alternative before selling > their bitcoins at a highest price. > Not sure I get your point here. Are you implying the bitcoin authors are scamming people? How about you draw up a list of requirements that your system is meant to solve? Right now I see a complicated model but you haven't established the ground rules yet. E.g.: ? 1. Any entity may enter and leave the network at any time, and not loose or gain money by doing so. ? 2. Any two entities may exchange money with little to no cooperation from the network; and there is an appropriate incentive to cooperate as far as cooperation is needed. ? 3. The time required to exchange money must be small; and the fees required to exchange money must be minimal. ? 4. No entity may gain wealth without cooperation from those who in turn loose wealth. ? 5. Transactions should be anonymous with the exception of traffic analysis. (Input welcome!) This is just an example and you'd adjust it to suit your needs, but I think it's a good start. You mentioned that you're not interested in ? 5, so you'd obviously leave that out. Once you've defined a specific goal, it will be much easier to verify that you're reaching this goal. Otherwise everyone else has to make assumptions about what you're trying to achieve. It also hinders promotion: If I can't see what features your currency has to offer, I'm not going to pick it over bitcoin. -- Jerome Baum tel +49-1578-8434336 email jerome at jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanjacquesbrucker at gmail.com Sat May 28 13:04:56 2011 From: jeanjacquesbrucker at gmail.com (Jbar) Date: Sat, 28 May 2011 13:04:56 +0200 Subject: needs in OpenPGP to use it for a bitcoin replacement. In-Reply-To: References: <201105251921.16544.jeanjacquesbrucker@gmail.com> <201105261741.56889.jeanjacquesbrucker@gmail.com> Message-ID: <201105281305.01583.jeanjacquesbrucker@gmail.com> Le jeudi 26 mai 2011 18:46:25, Jerome Baum a ?crit : First, I am sorry to not answer before, as I said, I sorely lacking time. But I am glad to find at least a skilled fellow to discuss about the idea and especially its technicals issues/solutions. In fact a fairest alternative to bitcoin is expected by more and more french bloggers. ( I just give a link in english but i may give you a lot of links to french bloggers and articles: http://owni.fr/2011/03/14/how-french-site-owni-profits-by-giving-away-its-content/). > > Not really a bitcoin fan here, and I think gold is a pretty bad analogy > that breaks down very soon. How about coins instead? The idea here is that > coins can be generated without limits (i.e. don't need to be mined -- > assuming no lack of resources that the coins are made of). True. > This is particularly difficult to resolve. A digital currency should allow > any two people to trade without having met each other before. Bitcoin > allows this, while a WoT-based model requires at the very least a chain > between those people and cooperation along the chain. True. (and wotsap is our friend http://www.lysator.liu.se/~jc/wotsap/index.html). > So, the system doesn't allow new people to come into play after it has been > started? False, People may always get it or get out. The amount of money created periodically depend on it : Universal Dividend (or Monetary Dividend) creation: * UD(n+1) = MAX { UD(n) ; Pud*M(n)/N(n) } //Where n is the past month. UD(n) is the UD of past month. Pud is the minimal % UD growth as defined in the 4th rule. M(n) is the existing monetary mass, and N(n) is the total amount of members. All are values just before calculation of new monthly UD(n+1).// > > If a human in the list don't create its part of money, he is supposed to > > > > be dead and is (until he comes back to life) removed from the given web > > of trust. > > Don't get this part. It is just a simple way to manage people getting out of the List. > > /B1 > > > > / > > > > A --B2 > > > > \ > > > > \B3 > > > > Every B networks watch its root network A, use it to make transaction > > > > between them. But network B2 and network A don't care about the money > > exchanged in network B3. > > So say I am in network B3 and you are in B1, how do I send you money? Trough network A. I see 2 ways to do it : 1- You entrust your money to a confidence entity is also in network A and propagate transaction to network B1. (first idea, worst one). 2- Every body (you and I) is also in all parents networks (A) and make transaction in their common parent network. As every body watch what happen in their parents networks (until the root), they know that some bills have go out, or go in, their smaller networks. (easiest to implement). (About networks, i did think of using xmpp chatrooms, for the beginning, this idea comes from the irc channel which bitcoin software connects). > > For a first implementation you'll have to go with notations if you want to > use OpenPGP. Otherwise you get compatibility issues etc. True. > Not sure I get your point here. Are you implying the bitcoin authors are > scamming people? I don't think so, (or not more than other traders in the world). I just say they have no interests, economically speaking , to work on a fairest alternative. > How about you draw up a list of requirements that your system is meant to > solve? Right now I see a complicated model but you haven't established the > ground rules yet. E.g.: > > ? 1. Any entity may enter and leave the network at any time, and not loose > or gain money by doing so. > > ? 2. Any two entities may exchange money with little to no cooperation from > the network; and there is an appropriate incentive to cooperate as far as > cooperation is needed. > > ? 3. The time required to exchange money must be small; and the fees > required to exchange money must be minimal. > > ? 4. No entity may gain wealth without cooperation from those who in turn > loose wealth. > > ? 5. Transactions should be anonymous with the exception of traffic > analysis. > > (Input welcome!) > > This is just an example and you'd adjust it to suit your needs, but I think > it's a good start. You mentioned that you're not interested in ? 5, so > you'd obviously leave that out. > > Once you've defined a specific goal, it will be much easier to verify that > you're reaching this goal. Otherwise everyone else has to make assumptions > about what you're trying to achieve. It also hinders promotion: If I can't > see what features your currency has to offer, I'm not going to pick it over > bitcoin. To help us clarifying the ground rule, you may discuss on our mailing list (http://groups.google.com/group/open-udc) or our xmpp chatroom (open- udc at muc.jappix.com) and write directly in our wiki (http://www.open-udc.org/en/contributing). The ground rule you write (except ? 5) are already what I have in mind, I'd like to add : ? 5 an entity is an human or a group of defined humans (no legal entity). But the skills needed to write this rules are less rare than our technical skills. :-) looking forward to read you, Jean-Jacques. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 316 bytes Desc: This is a digitally signed message part. URL: From jerome at jeromebaum.com Mon May 30 10:54:19 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Mon, 30 May 2011 10:54:19 +0200 Subject: needs in OpenPGP to use it for a bitcoin replacement. In-Reply-To: <201105281305.01583.jeanjacquesbrucker@gmail.com> References: <201105251921.16544.jeanjacquesbrucker@gmail.com> <201105261741.56889.jeanjacquesbrucker@gmail.com> <201105281305.01583.jeanjacquesbrucker@gmail.com> Message-ID: On Sat, May 28, 2011 at 13:04, Jbar wrote: > Le jeudi 26 mai 2011 18:46:25, Jerome Baum a ?crit : >> This is particularly difficult to resolve. A digital currency should allow >> any two people to trade without having met each other before. Bitcoin >> allows this, while a WoT-based model requires at the very least a chain >> between those people and cooperation along the chain. > > True. > (and wotsap is our friend http://www.lysator.liu.se/~jc/wotsap/index.html). So what happens if I don't have an established WoT? Does this currency just not work for me? If you want to promote OpenPGP, then it's probably best to promote it to people who aren't using it yet -- as opposed to people who are already using it and have an established WoT. >> So say I am in network B3 and you are in B1, how do I send you money? > > Trough network A. > I see 2 ways to do it : > ?1- You entrust your money to a confidence entity is also in network A and propagate transaction to network B1. (first idea, worst one). Yeah, don't really like this either. > ?2- Every body (you and I) is also in all parents networks (A) and make transaction in their common parent network. As every body watch what happen in > their parents networks (until the root), they know that some bills have go out, or go in, their smaller networks. (easiest ?to implement). Then why have segments in the first place? >> Not sure I get your point here. Are you implying the bitcoin authors are >> scamming people? > > I don't think so, (or not more than other traders in the world). I just say they have no interests, economically speaking , to work on a fairest > alternative. I have no interests, economically speaking, of writing this email. It's not like I'm going to make money from this, not even indirectly. People have other interests than economic ones -- say you want to promote digital currencies, or you are genuinely interested in the challenge. >> How about you draw up a list of requirements that your system is meant to >> solve? Right now I see a complicated model but you haven't established the >> ground rules yet. E.g.: >> >> ? 1. Any entity may enter and leave the network at any time, and not loose >> or gain money by doing so. >> >> ? 2. Any two entities may exchange money with little to no cooperation from >> the network; and there is an appropriate incentive to cooperate as far as >> cooperation is needed. >> >> ? 3. The time required to exchange money must be small; and the fees >> required to exchange money must be minimal. >> >> ? 4. No entity may gain wealth without cooperation from those who in turn >> loose wealth. >> >> ? 5. Transactions should be anonymous with the exception of traffic >> analysis. >> >> (Input welcome!) >> >> This is just an example and you'd adjust it to suit your needs, but I think >> it's a good start. You mentioned that you're not interested in ? 5, so >> you'd obviously leave that out. > To help us clarifying the ground rule, you may discuss on our mailing list (http://groups.google.com/group/open-udc) or our xmpp chatroom (open- > udc at muc.jappix.com) and write directly in our wiki (http://www.open-udc.org/en/contributing). Feel free to cross-post, but keep me in CC as I am not subscribed. > The ground rule you write (except ?? 5) are already what I have in mind, I'd like to add : > > ? 5 an entity is an human or a group of defined humans (no legal entity). Why? > But the skills needed to write this rules are less rare than our technical skills. :-) Not too sure about this one. Yes, anyone can come up with some "rules", but good ground rules are a different thing entirely. Every rule will have an impact on the success of the currency -- such as your ? 6 above. (sorry for the rename) I've also taken a look at http://www.open-udc.org/en/money_rules and frankly it feels like I was hit by a bus: "A new Open-UDC member must be approuved by 2/3 or more of all members" is quite a condition. Does this mean I cannot trade the currency if I don't have prior approval of a 2/3 majority of the existing traders? Two options: 1. Yes it does. Thank you, but I'm looking elsewhere. 2. No it doesn't. Then your rules aren't easy enough to understand. I'm looking elsewhere. -- Jerome Baum tel +49-1578-8434336 email?jerome at jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA From jeanjacquesbrucker at gmail.com Tue May 31 12:44:38 2011 From: jeanjacquesbrucker at gmail.com (Jean-Jacques Brucker) Date: Tue, 31 May 2011 12:44:38 +0200 Subject: needs in OpenPGP to use it for a bitcoin replacement. In-Reply-To: References: <201105251921.16544.jeanjacquesbrucker@gmail.com> <201105281305.01583.jeanjacquesbrucker@gmail.com> Message-ID: <201105311244.43616.jeanjacquesbrucker@gmail.com> > > So what happens if I don't have an established WoT? Does this currency > just not work for me? If you want to promote OpenPGP, then it's > probably best to promote it to people who aren't using it yet -- as > opposed to people who are already using it and have an established > WoT. As it is WoT-based, a given currency can only be exchanged in only one WoT. Building a WoT is so the mandatory first step. The aim of the project is to define a standard, then you can build your own currency in your own WoT. Finally i would prefer to be in the same WoT as you to use also the same currency. About WoT, I will know make key-signing parties to EnlArge my WoT. (There will be one in Strasbourg at the beginning of July : http://2011.rmll.info). But actually OpenPGP WoT doesn't grant individual uniqueness, and that is something mandatory to apply a fairest monetary dividend. That is why I think everybody which want to use such WoT-based currency, should rebuild a WoT in accordance to this requirement. https://github.com/jbar/open-udc/blob/master/docs/Authentication_Mechanisms.draft.txt > > 2- Every body (you and I) is also in all parents networks (A) and make transaction in their common parent network. As every body watch what happen in > > their parents networks (until the root), they know that some bills have go out, or go in, their smaller networks. (easiest to implement). > > Then why have segments in the first place? For the performances : to not overload the first place with local trades. > I have no interests, economically speaking, of writing this email. > It's not like I'm going to make money from this, not even indirectly. > People have other interests than economic ones -- say you want to > promote digital currencies, or you are genuinely interested in the > challenge. Both of them. If u want a short retrospection about my motivation : when i was young and discovered GNU/Linux I wanted to live from free software activities in a nice place not too crowded. At that time, some people around the free software movement (a bit sociologists or anthropologists), watching us "working" and building amazing things without expecting directly money, did ask the question "how to make the baker get in ?" (In France bakers are very important). Since I left the nice place for a big city, and began working for big companies which prefers to retain "property" of their work. But this question and the will to go back living in a place where there are mainly farmers and bakers still haunted me. "Today, with all the technical progress made, why don't we still live in an age of plenty ?" ("why do I work for things that I dislike, and lack of time for things I like and that may be, I think, much more useful for the society ?") Then I studied the creation of money, the universal dividend, and the money-as-a-debt... and "I saw a light" ;-) I want to promote a universal monetary dividend currency ; and digital for best efficiency. There is then a genuine challenge to resolve. > > > ? 5 an entity is an human or a group of defined humans (no legal entity). > > Why? To keep things simple. > > But the skills needed to write this rules are less rare than our technical skills. :-) > > Not too sure about this one. Yes, anyone can come up with some > "rules", but good ground rules are a different thing entirely. Every > rule will have an impact on the success of the currency -- such as > your ? 6 above. (sorry for the rename) > > I've also taken a look at http://www.open-udc.org/en/money_rules and > frankly it feels like I was hit by a bus: "A new Open-UDC member must > be approuved by 2/3 or more of all members" is quite a condition. Does > this mean I cannot trade the currency if I don't have prior approval > of a 2/3 majority of the existing traders? Two options: > > 1. Yes it does. Thank you, but I'm looking elsewhere. > > 2. No it doesn't. Then your rules aren't easy enough to understand. > I'm looking elsewhere. > I am not agree with that rule too, but you can discuss it with the one who wrote it (and I will be glad if you convince him to erase it). By the way, such kind of rules is not in the technical heart of a WoT-based solution which I try to define (and need help for that). -- Jean-Jacques B. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part. URL: From jerome at jeromebaum.com Tue May 31 19:32:04 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Tue, 31 May 2011 19:32:04 +0200 Subject: needs in OpenPGP to use it for a bitcoin replacement. In-Reply-To: <201105311244.43616.jeanjacquesbrucker@gmail.com> References: <201105251921.16544.jeanjacquesbrucker@gmail.com> <201105281305.01583.jeanjacquesbrucker@gmail.com> <201105311244.43616.jeanjacquesbrucker@gmail.com> Message-ID: On Tue, May 31, 2011 at 12:44, Jean-Jacques Brucker wrote: > >> >> So what happens if I don't have an established WoT? Does this currency >> just not work for me? If you want to promote OpenPGP, then it's >> probably best to promote it to people who aren't using it yet -- as >> opposed to people who are already using it and have an established >> WoT. > > As it is WoT-based, a given currency can only be exchanged in only one WoT. > > Building a WoT is so the mandatory first step. Point still applies. >> I have no interests, economically speaking, of writing this email. >> It's not like I'm going to make money from this, not even indirectly. >> People have other interests than economic ones -- say you want to >> promote digital currencies, or you are genuinely interested in the >> challenge. > > Both of them. > > If u want a short retrospection about my motivation Sorry for the subtlety, I was pointing out the fact that the Bitcoin creators needn't have economic interests in helping you, and still may be happy to do so. You should still definitely get in touch with them if you want to create an improvement over Bitcoin. >> > ? 5 an entity is an human or a group of defined humans (no legal entity). >> >> Why? > > To keep things simple. Why is this simpler? How is any market going to spawn with your new digital currency if businesses are prohibited from trading there? Why make a restriction that isn't strictly related to the technical and economical model you are designing? >> I've also taken a look at http://www.open-udc.org/en/money_rules and >> frankly it feels like I was hit by a bus: "A new Open-UDC member must >> be approuved by 2/3 or more of all members" is quite a condition. Does >> this mean I cannot trade the currency if I don't have prior approval >> of a 2/3 majority of the existing traders? Two options: > By the way, such kind of rules is not in the technical heart of a WoT-based > solution which I try to define (and need help for that). Exactly my point when it comes to ? 6. -- Jerome Baum tel +49-1578-8434336 email?jerome at jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA