[Cialug] Complete C source online

[Dave Hala]

It kind of makes you want get to just "get off the grid" doesn't it?  I see
a lot of this in the firearms community. People pay cash for everything
from firearms to ammunition and then only deal in person. They leave their
phones at home when they go to gun shows, etc.


On Thu, Jul 25, 2013 at 3:33 AM, Morris Dovey <mrdovey at iedu.com> wrote:

> On 7/25/13 2:31 AM, Zachary Kotlarek wrote:
>
>>
>> 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?
>>
>
> AES has the look and feel of a method /designed/ to be cracked with
> appropriate hardware. I think we’ll learn that it’s as open as DES.
>
>
>  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.
>>
>
> Agreed. I’m not yet satisfied with my Q&D conversion of the user-supplied
> key file to key data used within the program. I’m still trying to work my
> way through that - but have cheerful expectations of success.
>
>
>  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).
>>
>
> Right.
>
>
>  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.
>>
>
> This appears to be a sometimes and some places kind of problem. Facebook,
> for example, does a lot of this with profile and newsfeed photos, but seems
> not to do that to images downloaded from an album via their photo viewer
> (they also convert everything to jpg, so the png one uploads will never be
> what they serve up.
>
> There’s a lot still to think through - but I’m determined to find some way
> to put an end to this surveillance BS. I don’t much care who reads what I
> write (although I’d prefer to hide my reactor work from the opportunivores
> and the folks who seem compelled to weaponize everything they can) but I
> find it disturbing that all the candidates for the next election are all
> under total surveillance - that just can’t be healthy.
>
> ______________________________**_________________
> Cialug mailing list
> Cialug at cialug.org
> http://cialug.org/mailman/**listinfo/cialug<http://cialug.org/mailman/listinfo/cialug>
>