[Cialug] Complete C source online

[Zachary Kotlarek]

On Jul 24, 2013, at 11:13 PM, Morris Dovey <mrdovey at iedu.com> wrote:

> The goal is to make the content “indistinguishable from pure noise” that Kristau suggested earlier. My hypothesis is that it’s an achievable goal.
> 

> Then some better waster computer time will be needed. I don’t have a problem with that. :-)


I am confused on this point. As I see it, we already *have* better time wasters that produce more-random-looking output -- AES, or any of the other existing encryption algorithms. Why are those not what you want?

--

Unrelated to the actual encryption algorithm, if you want to select public data as a key to simplify the key exchange I can see that; key exchange is hard for all sorts of reasons and making it easier can certainly encourage people to use more encryption. It doesn't provide significant privacy but it does increase the cost of analysis a bit.

But you still want high-entropy keys, even if you don't care about protecting against actual key discovery (i.e. the analysis following whatever dereferencing algorithm you expect users to follow to find the key). Low-entropy keys are the same cost to your users (both in CPU and manual effort), but are lower-cost to your attacker, and all you have to do to increase the cost to the attacker is choose better keys.

In the broader sense, this is exactly the problem that pubkey protocols were designed to solve. For example, S/MIME allows automatic encryption among any users who have previously exchanged messages. The first exchange is unprotected, but after that encryption "just happens" when you send messages. The CA-based model of key authentication most mail clients use, and in particular the warnings about unsigned/untrusted keys are not particularly friendly, but that's a limitation of the UI not the protocol. In the scope you propose, where we aren't trying to protect against interactive attacks or provide authentication, clients could generate new key pairs automatically as needed and could simply accept any public keys they've ever seen without user intervention. About the only place that sort of system doesn't work is when the send does not know the recipients (e.g. mailing lists) but there are ways to manage that as well (e.g. upon subscription the mailing list sends you a copy of both the public and private keys, so messages can by encrypted to "the list" rather than to recipients, and all recipients can decrypt it).

--

On a non-encryption note: you often cannot depend on the images from public websites being identical over time or among users. Web acceleration techniques commonly include image re-processing and may be done on-the-fly, so different requests may see different data. The same is true for HTML/CSS/JS/etc. -- anything that improves site performance while preserving the functionality is fair game for optimization.

	Zach

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2746 bytes
Desc: not available
URL: <http://cialug.org/pipermail/cialug/attachments/20130725/2ecca20e/attachment.bin>