[Cialug] Complete C source online

[Morris Dovey]

On 7/24/13 3:23 PM, Zachary Kotlarek wrote:
>
> On Jul 24, 2013, at 12:58 PM, Morris Dovey <mrdovey at iedu.com> wrote:
>
>> It’s always possible to put Humpty-Dumpty together again, but it
>> does make a practical difference whether he simply fell off the
>> wall or was reduced to molecule-sized pieces with a hammer.
>
> What I'm suggesting that you needn't start with Humpty-Dumpty in the
> first place, so there's nothing to reassemble.

Actually there is - the original data. :-)

>> I don’t have any interest in protecting state secrets - my intent
>> is to make it unreasonable to snoop billions social network
>> exchanges, e-mails, phone text messages, and SIM cards every day.
>
> Then you care about how your keys are generated. At the very least
> you need to come up with some estimate of their entropy so you know
> how long to make them to actually protect you against snooping.
> Running 8192-bit encryption against a key with 9 bits of entropy is
> not going to provide you protection against anything.

Given that I’m (at least momentarily) satisfied with the entropy, I care 
even more about being able to send data without a requirement to ever 
publicly transmit/expose a key - and these days all paths should 
probably be considered “public”.

>> To that end, I’ll be happy to buy the next round of coffee (beer?)
>> for anyone in the LUG who improves significantly on my Q&D code,
>> and offers it up freely. :-)
>
> On anything that supports the RdRand instruction it's as simple as
> including this library and asking the CPU for a random number:
> http://software.intel.com/en-us/articles/user-manual-for-the-rdrand-library-linux-version
>
>  uint64_t key; if (rdrand_64(&key, 1) != RDRAND_SUCCESS) { // Not
> enough entropy or RdRand not available on this CPU exit(-1); }
>
> Beyond that there are a number of random number generation techniques
> available, but even data from /dev/random would typically be a better
> source than scrambling low-entropy data (like an image file). On many
> systems /dev/random is a pretty decent source of randomness, and you
> can ask it how random it thinks by reading
> /proc/sys/kernel/random/entropy_avail.

I hear you, but the little 32KB Arduino on my desk is shaking his head - 
and at this point /all/ kernels (and all closely kernel-connected 
facilities) are suspect. I have more confidence in Linux than Windows, 
but that’s not saying much.

The only time I would want true random would be if I were producing keys 
to hand out - which is one of the things I really don’t want. I’m 
perfectly happy with a low-to-medium quality PRNG that’s generally 
available.

I think we’re working at cross-purposes. I understand that you want to 
make data bulletproof - while I want to so overload the snooping 
mechanism that the snoopers are forced to limit their activities to 
those who really are dangerous.