Re: [cryptography] Reply to Zooko (in Markdown)
On 17 August 2013 13:50, Jon Callas j...@callas.org wrote: ... I *cannot* provide an argument of security that can be verified on its own. This is Godel's second incompleteness theorem. A set of statements S cannot be proved consistent on its own. (Yes, that's a minor handwave.) . . On Thu, Aug 22, 2013 at 1:32 AM, Ben Laurie b...@links.org wrote: That is totally not Godel's second incompleteness theorem. It is certainly possible to prove things in formal systems. This is not a minor handwave, it is pure bullshit. the software systems for which you can write a formal proof of correctness (or have a trusted prover write one for you) are very different from the software systems widely used today, especially those published in app stores and running on common desktops. possible != practical, which is really the boundary where interesting security decisions are made... this is a very different subject, which always brings me back to design flaws. an entire processor, operating system, and application system written in a security friendly automated prover verified manner may and likely will suffer design flaws and misuse. which is not to say these efforts are pointless, but rather that if your threat model includes state level actors with significant budget, access, skill, and motive then a perfect software system is but one of your many opsec concerns. i could go on, but why retread Reflections on Trusting Trust further when it has been conveyed so well already ;) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
Just appeared on the GnuPG list: NeuG 0.11 was released. NeuG is an implementation of True Random Number Generator based on quantization error of ADC of STM32F103. It is basically intended to be used as a part of Gnuk, but we also have standalone USB CDC-ACM version (you can get random stream from /dev/ttyACM0). Standalone version is useful to feed entropy to /dev/random on GNU/Linux. Its generation speed is = 50kB/sec, and it's more when connected to USB 2.0 Hub. The output is tested NIST STS 2.1.1 and Dieharder 3.31.1. Highlights are: * Replacement of kernel (thread library) Instead of ChibiOS/RT, we now use Chopstx. * Improved performance The output of random numbers got faster than the previous implementation by 30% or so. * Unsupported targets CQ_STARM, STBEE, STBEE Mini, and STM32_PRIMER2 are not supported in this release, but porting should be easy. Here are some links for NeuG, Gnuk and FST-01 (the hardware). NeuG (under Gnuk Repository): http://gitorious.org/gnuk/neug Gnuk News: http://www.fsij.org/gnuk/ FST-01 introduction: http://www.seeedstudio.com/wiki/index.php?title=FST-01 FST-01 QA site: http://no-passwd.net/askbot/questions/ Japanese Documentation for FST-01 and Gnuk Token: http://no-passwd.net/fst-01-gnuk-handbook/index.html Enjoy, ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
In terms of usability engineering, /dev/random is fairly cumbersome and in dire need of reform and expansion. A user, might want more control of /dev/random - which sources of entropy, when, and which applications. e.g. I want my Geiger counter to feed communications and radio noise to feed data. I want 3000 from 9am-5pm and 200 otherwise. I want all this'd in a GUI or config file. A developer, might want to tell /dev/random don't give me keyboard and mouse crap, instead give me 80% rdrand and 20% audio source. Naturally, the better alternative is a widely implemented open sources TRNG, but good luck convincing manufacturers. So why concentrate on what you can't fix. Reform /dev/random and empower user and developer with choice over quality and amount of randomness! Randomness is hard to prove but you can test quality with dierharder. Open eSignForms yoz...@gmail.com wrote: We all know that randomness is required for good crypto, but what is the a measurable difference in the quality of the crypto if using a Linux PRNG (or in our case the Java SecureRandom PRNG)? How much easier is it to crack an encrypted file done with such weaker PRNGs compared to the hardware RNGs, especially if it's so hard to determine the quality of the randomness. On Tue, Aug 20, 2013 at 4:10 PM, James A. Donald jam...@echeque.com wrote: On 2013-08-21 7:33 AM, grarpamp wrote: The subject thread is covering a lot about OS implementations and RNG various sources. But what are the short list of open source tools we should be using to actually test and evaluate the resulting number streams? __**_ You cannot test and evaluate a supposedly random number stream. True randomness and cryptographically strong pseudo randomness are not directly observable qualities. You have to look at the underlying generation mechanism and deduce randomness, or the lack thereof. If you apply a whitening expander to the source stream 000 the output stream will look convincingly random, but will be completely non random to anyone who knows the whitening expander and knows or suspects that the source stream is completely non random __**_ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography -- Yazid Boukerroui ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] enabling blind signatures in GPG
Hi Jim and Alex, Thanks for your help. I am pretty overwhelmed by this stuff because I am not a cryptographer (although i am a coder) but I am very determined to do this. So I am in over my head, but I have to keep going. My main focus is to be able to implement blinding for signatures using an openPGP implementation (something open-source, which means GnuPG) But when I say signature I DON'T mean the type of signature you do when you sign someone's public key. I mean like when you sign a textfile or a binary blob. As for revokation, I plan to have the CR (central registrar) sign peoples pubkeys using a key set to expire 12 months hence. So there will be twelve pubkeys in use by the CR at any given time. If someone loses their private key and is concerned that someone is using it to vote in their name, they can simply post a revokation signed with their pubkey (and accompanied by their endorsement) saying revoked and anyone doing a tally of signed screeds will blacklist their pubkey. But they won't be able to participate in the system until 12 months after their last signing by the CR, because their realname is crossed off the list for that time. The CR only tracks realnames, not pubkeys. But to enforce anonymity from an evil CR, the voter will blind their pubkey into an unreadable blob before having the CR put a signature around it. The CR will do this with RSA with no padding, so that the voter can take the result and unblind it into what looks like a signature of their pubkey (even though the CR never saw their pubkey). Apologies if this is already obvious to you. My highest priority is making this system understandable by as many people as possible, which will be a huge challenge. Eventually there will be an iphone app and a javascript page (i know) and people will be able to use it no matter how simple they are. So i definitely need to start with something I personally can understand. Another very important feature of this system is that there is only one point of centralization: the central registrar (CR). Their job is to see the person's credentials (an ID or proof of residence or whatever proves they are a member of the set in question), sign (with unpadded RSA) whatever the person presents, and record the date and fact of this signing in a publicly accessible record. And publish their pubkeys (one for each month, each expiring 12 months hence). All other aspects of the system are decentralized. Each enrolled person can post their opinions signed with their (signed) pubkey anywhere on the net they want. Anyone can crawl and tally these opinions, and verify all signatures independantly, traceable to the CR's pubkeys. The point of this is to make it so that a population (whether defined by a geographical area, or a voting district, or a cultural enclave, neighborhood, bolo, or entire nation) can choose a central registrar (trusted with a simple and mostly verifiable task) to enable an unmediated discussion between members. If members stick to a machine-parseable format (copy tweet-length statements that they agree with, and are or will be trending), it will be possible for anyone to take a snapshot of opinion, guaranteeing accuracy of sentiment and one-person one-vote. I have everything figured out except the blinding. I am glad to give more detail to anyone interested but I can't do anything until I get blinding working because it's essential to the anonymity of participants. Thank you for any help you can give, -jake ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] enabling blind signatures in GPG
The one caveat I'd offer is that there have been many similar voting or e-cash proposals based on blind signatures going back to David Chaum in 1982. I'm not aware of any that have gotten traction. The blinding part is easy. The hard part is getting any adoption. Regardless, there are some anonymous credential projects with large backers which may be of interest: - Intel is baking Enhanced Privacy ID support into upcoming processors. CPU packages will have unique key material that will be used to anonymously or pseudonymously authenticate a hardware device: http://csrc.nist.gov/groups/ST/PEC2011/presentations2011/brickell.pdf - Microsoft's U-Prove, which is based on Stefan Brands' Credentica work, published a lot of material in April 2013: http://research.microsoft.com/en-us/projects/u-prove/ There is a related book by Brands available for download here: http://www.credentica.com/the_mit_pressbook.html - IBM's Idemix looked promising a few years ago, but seems to have stagnated: http://www.zurich.ibm.com/security/idemix/ Source code here: https://prime.inf.tu-dresden.de/idemix/ On Thu, Aug 22, 2013 at 3:37 PM, Jake j...@spaz.org wrote: Hi Jim and Alex, Thanks for your help. I am pretty overwhelmed by this stuff because I am not a cryptographer (although i am a coder) but I am very determined to do this. So I am in over my head, but I have to keep going. My main focus is to be able to implement blinding for signatures using an openPGP implementation (something open-source, which means GnuPG) But when I say signature I DON'T mean the type of signature you do when you sign someone's public key. I mean like when you sign a textfile or a binary blob. As for revokation, I plan to have the CR (central registrar) sign peoples pubkeys using a key set to expire 12 months hence. So there will be twelve pubkeys in use by the CR at any given time. If someone loses their private key and is concerned that someone is using it to vote in their name, they can simply post a revokation signed with their pubkey (and accompanied by their endorsement) saying revoked and anyone doing a tally of signed screeds will blacklist their pubkey. But they won't be able to participate in the system until 12 months after their last signing by the CR, because their realname is crossed off the list for that time. The CR only tracks realnames, not pubkeys. But to enforce anonymity from an evil CR, the voter will blind their pubkey into an unreadable blob before having the CR put a signature around it. The CR will do this with RSA with no padding, so that the voter can take the result and unblind it into what looks like a signature of their pubkey (even though the CR never saw their pubkey). Apologies if this is already obvious to you. My highest priority is making this system understandable by as many people as possible, which will be a huge challenge. Eventually there will be an iphone app and a javascript page (i know) and people will be able to use it no matter how simple they are. So i definitely need to start with something I personally can understand. Another very important feature of this system is that there is only one point of centralization: the central registrar (CR). Their job is to see the person's credentials (an ID or proof of residence or whatever proves they are a member of the set in question), sign (with unpadded RSA) whatever the person presents, and record the date and fact of this signing in a publicly accessible record. And publish their pubkeys (one for each month, each expiring 12 months hence). All other aspects of the system are decentralized. Each enrolled person can post their opinions signed with their (signed) pubkey anywhere on the net they want. Anyone can crawl and tally these opinions, and verify all signatures independantly, traceable to the CR's pubkeys. The point of this is to make it so that a population (whether defined by a geographical area, or a voting district, or a cultural enclave, neighborhood, bolo, or entire nation) can choose a central registrar (trusted with a simple and mostly verifiable task) to enable an unmediated discussion between members. If members stick to a machine-parseable format (copy tweet-length statements that they agree with, and are or will be trending), it will be possible for anyone to take a snapshot of opinion, guaranteeing accuracy of sentiment and one-person one-vote. I have everything figured out except the blinding. I am glad to give more detail to anyone interested but I can't do anything until I get blinding working because it's essential to the anonymity of participants. Thank you for any help you can give, -jake __**_ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] blinding is in libgcrypt but NOT in gnupg?
as you all know, I have been trying to find blinding for GnuPG, and
someone to help implement it as a seperate (external) operation.
I was told that blinding was used in RSA decryption to repel timing
attacks. But I couldn't find it anywhere in the GnuPG source code.
/* We use blinding by default to mitigate timing attacks which can
be practically mounted over the network as shown by Brumley and
Boney in 2003. */
I found it in libgcrypt. I don't understand why it's not in gnupg.
It looks to my untrained eye that gnupg and libgcrypt had a common
ancestor, but i'm not sure when that was. Anyway, here is what I found.
Does anyone have any idea why it's not in gnupg, and is that a problem?
Does anyone want to help me merge it in and get it reviewed and pulled?
from libgcrypt-1.5.0/cipher/rsa.c (NOT present in gnupg/cipher/rsa.c)
/* Perform RSA blinding. */
static gcry_mpi_t
rsa_blind (gcry_mpi_t x, gcry_mpi_t r, gcry_mpi_t e, gcry_mpi_t n)
{
/* A helper. */
gcry_mpi_t a;
/* Result. */
gcry_mpi_t y;
a = gcry_mpi_snew (gcry_mpi_get_nbits (n));
y = gcry_mpi_snew (gcry_mpi_get_nbits (n));
/* Now we calculate: y = (x * r^e) mod n, where r is the random
number, e is the public exponent, x is the non-blinded data and n
is the RSA modulus. */
gcry_mpi_powm (a, r, e, n);
gcry_mpi_mulm (y, a, x, n);
gcry_mpi_release (a);
return y;
}
/* Undo RSA blinding. */
static gcry_mpi_t
rsa_unblind (gcry_mpi_t x, gcry_mpi_t ri, gcry_mpi_t n)
{
gcry_mpi_t y;
y = gcry_mpi_snew (gcry_mpi_get_nbits (n));
/* Here we calculate: y = (x * r^-1) mod n, where x is the blinded
decrypted data, ri is the modular multiplicative inverse of r and
n is the RSA modulus. */
gcry_mpi_mulm (y, ri, x, n);
return y;
}
static gcry_err_code_t
rsa_decrypt (int algo, gcry_mpi_t *result, gcry_mpi_t *data,
gcry_mpi_t *skey, int flags)
{
RSA_secret_key sk;
gcry_mpi_t r = MPI_NULL; /* Random number needed for blinding. */
gcry_mpi_t ri = MPI_NULL; /* Modular multiplicative inverse of
r. */
gcry_mpi_t x = MPI_NULL; /* Data to decrypt. */
gcry_mpi_t y; /* Result. */
(void)algo;
/* Extract private key. */
sk.n = skey[0];
sk.e = skey[1];
sk.d = skey[2];
sk.p = skey[3]; /* Optional. */
sk.q = skey[4]; /* Optional. */
sk.u = skey[5]; /* Optional. */
y = gcry_mpi_snew (gcry_mpi_get_nbits (sk.n));
/* We use blinding by default to mitigate timing attacks which can
be practically mounted over the network as shown by Brumley and
Boney in 2003. */
if (! (flags PUBKEY_FLAG_NO_BLINDING))
{
/* Initialize blinding. */
/* First, we need a random number r between 0 and n - 1, which
is relatively prime to n (i.e. it is neither p nor q). The
random number needs to be only unpredictable, thus we employ
the gcry_create_nonce function by using GCRY_WEAK_RANDOM with
gcry_mpi_randomize. */
r = gcry_mpi_snew (gcry_mpi_get_nbits (sk.n));
ri = gcry_mpi_snew (gcry_mpi_get_nbits (sk.n));
gcry_mpi_randomize (r, gcry_mpi_get_nbits (sk.n), GCRY_WEAK_RANDOM);
gcry_mpi_mod (r, r, sk.n);
/* Calculate inverse of r. It practically impossible that the
following test fails, thus we do not add code to release
allocated resources. */
if (!gcry_mpi_invm (ri, r, sk.n))
return GPG_ERR_INTERNAL;
}
if (! (flags PUBKEY_FLAG_NO_BLINDING))
x = rsa_blind (data[0], r, sk.e, sk.n);
else
x = data[0];
/* Do the encryption. */
secret (y, x, sk);
if (! (flags PUBKEY_FLAG_NO_BLINDING))
{
/* Undo blinding. */
gcry_mpi_t a = gcry_mpi_copy (y);
gcry_mpi_release (y);
y = rsa_unblind (a, ri, sk.n);
gcry_mpi_release (a);
}
if (! (flags PUBKEY_FLAG_NO_BLINDING))
{
/* Deallocate resources needed for blinding. */
gcry_mpi_release (x);
gcry_mpi_release (r);
gcry_mpi_release (ri);
}
/* Copy out result. */
*result = y;
return GPG_ERR_NO_ERROR;
}
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 8/22/13 9:40 AM, Nico Williams wrote: My suggestion is /dev/urandomN where N is one of 128, 192, or 256, and represents the minimum entropy estimate of HW RNG inputs to date to /dev/urandomN's pool. If the pool hasn't received that much entropy at read(2) time, then block, else never block and just keep stretching that entropy and accepting new entropy as necessary. That sounds like the perfect interface! The existing dichotomy between random and urandom (on Linux) is horrible, and it's nice to be able to specify how much entropy you are in need of. --Patrick ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 23, 2013 at 12:54 AM, Patrick Pelletier c...@funwithsoftware.org wrote: On 8/22/13 9:40 AM, Nico Williams wrote: My suggestion is /dev/urandomN where N is one of 128, 192, or 256, and represents the minimum entropy estimate of HW RNG inputs to date to /dev/urandomN's pool. If the pool hasn't received that much entropy at read(2) time, then block, else never block and just keep stretching that entropy and accepting new entropy as necessary. That sounds like the perfect interface! The existing dichotomy between random and urandom (on Linux) is horrible, and it's nice to be able to specify how much entropy you are in need of. Instead of a bunch of additional devices in /dev, the could add support to use fcntl(2) and ioctl(2) system calls to control it. That would allow for more granular control (although not be as convenient from languages where fcntl and ioctl are not supported such as the shell or Java. On second thought, scrap that idea. Of course, as far as blocking / non-blocking I/O, one should be able to change that behavior by a flag to the open(2) system call; e.g., int fd = open(/dev/random, O_RDONLY | O_NONBLOCK); or for /dev/urandom, int fd = open(/dev/urandom, O_RDONLY | ~O_NONBLOCK); At least that much could be supported from Java if not from the shell. Then if it is opened not to block, any read(2) request should either return whatever is available or -1 with errno set to EWOULDBLOCK when the normal result would be to block because there is not sufficient entropy. It would be up to the application to repeat the read() attempt (hopefully sleeping awhile in between) if they haven't read enough bytes. -kevin -- Blog: http://off-the-wall-security.blogspot.com/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents.-- Nathaniel Borenstein ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
