Re: [cryptography] urandom vs random
On 2013-08-18 4:11 PM, Ben Laurie wrote: If I chose to run Linux, I could fix the version I ran. In fact, I choose not to run it, so I don't need to. But if you write software, you don't write it just for your own computer, so if you write software for linux, you have to write it for the linux that everyone else runs. Which you cannot fix. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 18/08/13 09:11 AM, Ben Laurie wrote: If I chose to run Linux, I could fix the version I ran. In fact, I choose not to run it, so I don't need to. Indeed, or: That's terrible advice. Implement your own crypto of any sort widely leads to complete fail, as we see repeatedly. ;) gentle nudge... iang ps; for some reason, I am reminded of Blue Peter -- don't try this at home! for the anglo-challenged, Blue Peter was a children's show that filled a spot like Sesame Street. The phrase entered the language... ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] enabling blind signatures in GPG
Hello everybody, I am trying to form an anonymous opining sytem based on a single Registrar, whose signatures deify users' public keys with the mark of a Participant. But to protect the users from an evil registrar, blinding must be used. I have been told that blinding is already implemented internally to deter timing-based attacks, so this would be a matter of implementing a command-line option to blind a blob and save the blinding salts. I am not a cryptographer so I can only repeat what i've heard on this. http://en.wikipedia.org/wiki/Blind_signature#Blind_RSA_signatures.5B2.5D:235 Basically, a Participant generates a key pair (only for use in opining, not with their real identity) and wants to be able to prove, in public signed cleartext postings, that their public key has been signed by the Registar as an endorsement of Participation. But they don't want the Registrar to see their public key and correlate it with their real identity (their proof of eligibility for participation) because that would compromise their anonymity. So the Participant blinds their public key, presents that blob to the Registrar (along with their real identity) and receives the Registrar's signature of the blob. Then they take the blob home, and unblind it, revealing a perfect Registrar's signature of their public key. Please write if you can help me make this happen. I believe that the system i'm trying to create could have a very positive effect on democracy in the world, and hopefully make politicians into simple clerks whose job is simply to count the opinions and follow the will of the people. take care, -jake ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 18 August 2013 02:55, James A. Donald jam...@echeque.com wrote: On 2013-08-18 4:11 PM, Ben Laurie wrote: If I chose to run Linux, I could fix the version I ran. In fact, I choose not to run it, so I don't need to. But if you write software, you don't write it just for your own computer, so if you write software for linux, you have to write it for the linux that everyone else runs. Which you cannot fix. I do not have an obligation to work around all your broken decisions. Currently, my advice is that you probably should not run Linux if you need strong randomness. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] enabling blind signatures in GPG
Hi Jake. This is not GPG-related, but I worked on an OpenID-based private federated login system called PseudoID that used blind signatures. Basically, an identity provider will check your real identity, then issue you a blindly-signed token which you can then later use to log in pseudo-anonymously to an OpenID consumer. The consumer and provider can't latter correlate your real identity with that login. This was a summer project from an intern at the time and should be considered a proof-of-concept. It does the unblinding crypto in server-delivered Javascript so is not secure as-is. Do not use for anything in practice. Here's the paper: http://saweis.net/pdfs/pseudoid-pets2010.pdf Here's the source: https://code.google.com/p/pseudoid/ Here's a demo video: https://www.youtube.com/watch?feature=player_embeddedv=fCBPuGsO_I4 Here's a site that was the private ID provider demo: http://private-idp.appspot.com/ Here was the blind-signer demo, which is broken since we accidentally let the pseudoid.net domain lapse: http://blind-signer.appspot.com/ On Sun, Aug 18, 2013 at 1:08 AM, Jake j...@spaz.org wrote: Hello everybody, I am trying to form an anonymous opining sytem based on a single Registrar, whose signatures deify users' public keys with the mark of a Participant. But to protect the users from an evil registrar, blinding must be used. I have been told that blinding is already implemented internally to deter timing-based attacks, so this would be a matter of implementing a command-line option to blind a blob and save the blinding salts. I am not a cryptographer so I can only repeat what i've heard on this. http://en.wikipedia.org/wiki/**Blind_signature#Blind_RSA_** signatures.5B2.5D:235http://en.wikipedia.org/wiki/Blind_signature#Blind_RSA_signatures.5B2.5D:235 Basically, a Participant generates a key pair (only for use in opining, not with their real identity) and wants to be able to prove, in public signed cleartext postings, that their public key has been signed by the Registar as an endorsement of Participation. But they don't want the Registrar to see their public key and correlate it with their real identity (their proof of eligibility for participation) because that would compromise their anonymity. So the Participant blinds their public key, presents that blob to the Registrar (along with their real identity) and receives the Registrar's signature of the blob. Then they take the blob home, and unblind it, revealing a perfect Registrar's signature of their public key. Please write if you can help me make this happen. I believe that the system i'm trying to create could have a very positive effect on democracy in the world, and hopefully make politicians into simple clerks whose job is simply to count the opinions and follow the will of the people. take care, -jake __**_ 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
Re: [cryptography] urandom vs random
On Sat, Aug 17, 2013 at 12:48:12PM -0400, Sandy Harris wrote: On Fri, Aug 16, 2013 at 11:07 AM, Aaron Toponce aaron.topo...@gmail.com wrote: The /dev/urandom device in the Linux kernel uses the Yarrow pseudo random number generator when the entropy pool has been exhausted. No, it doesn't, or at least did not last time I looked at the code, a few months ago. There are similaities, but also large differences. Ah, my apologies. The FreeBSD implementation of a PRNG uses Yarrow. It appears that http://lxr.linux.no/linux+v3.10.7/drivers/char/random.c is using SHA to hash the contents of the entropy pool. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o pgpfY0tSRHe_o.pgp Description: PGP signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Sat, Aug 17, 2013 at 12:24:45AM -, D. J. Bernstein wrote: I'm not saying that /dev/urandom has a perfect API. It's disappointingly common for vendors to deploy devices where the randomness pool has never been initialized; BSD /dev/urandom catches this configuration bug by blocking, but Linux /dev/urandom (unlike Linux /dev/random) spews predictable data, causing (e.g.) the widespread RSA security failures documented on http://factorable.net. But fixing this configuration bug has nothing to do with the /dev/random superstitions. That paper is actually a real good read, especially those for Fedora, CentOS, RHEL, and other RPM-based systems, where SSH is installed by default, and the boot-time entropy hole is a real concern. But, as the paper mentions, keys generated late after boot weren't affected, and there were vulnerable keys on BSD systems generated with arc4random(3). -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o pgpuY7CHHxrRQ.pgp Description: PGP signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Sun, Aug 18, 2013 at 10:14 AM, Ben Laurie b...@links.org wrote: ... my advice is that you probably should not run Linux if you need strong randomness. i am surprised this has not surfaced more often in this thread: if you need good entropy: use a hardware entropy generator! also use a userspace entropy collector like dakarand or haveged, use a userspace entropy daemon for seeding system entropy pool (/dev/random) from hardware sources (like /dev/hw[_-]?random, unless you trust RDRAND ;) this is true no matter what operating system you use, where on a clean boot in a headless system you must choose between denial of service or silent insecurity. not to mention being under served in unexpected high usage situations, like initializing full disk crypto volumes with /dev/random or extremely high volume web server endpoints with high entropy utilization requirements. if you are running virtual machines this implies virtio random devices or VM safe instructions (if you trust RDRAND ;) to provide strong entropy within the guest systems as well. not to mention proper administration to ensure you're saving seeds and not sharing pool state between instances, etc. over ten years ago i wrote a threaded entropy daemon for the C5XL XSTORE instruction that provided megabits of entropy from /dev/random after configuring the MSR for XSTORE, sanity checks in the mtrngd, and writing to /dev/random when poll indicated users had consumed entropy from the system, thus ensuring /dev/random never went dry. ten years later and still the state of the consumer, embedded, and enterprise markets is totally inadequate, with the one recent ray of hope (RDRAND) intentionally obfuscated in a way that threatens trust. WTF in short, if you are not doing one or more of the following: - hardware rng with userspace daemon for hw rng - userspace entropy collector (haveged, dakarand, others) - securely seeded and re-seeded CSRNG (for VMs with boot and runtime entropy passing) you are doing it wrong. it is just a matter of risk/cost to exploit your use of randomness! (and the above does not mitigate your risk, it merely makes other risks your new weakest link, of course ;) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
