[Cryptography] End to end

[Phillip Hallam-Baker]

On Mon, Sep 16, 2013 at 3:14 PM, Ben Laurie <ben at links.org> wrote:

>
> On 16 September 2013 18:49, Phillip Hallam-Baker <hallam at gmail.com> wrote:
>
>> To me the important thing about transparency is that it is possible for
>> anyone to audit the key signing process from publicly available
>> information. Doing the audit at the relying party end prior to every
>> reliance seems a lower priority.
>>
>
> This is a fair point, and we could certainly add on to CT a capability to
> post-check the presence of a pre-CT certificate in a log.
>

Yeah, not trying to attack you or anything. Just trying to work out exactly
what the security guarantees provided are.



> In particular, there are some type of audit that I don't think it is
>> feasible to do in the endpoint. The validity of a CT audit is only as good
>> as your newest notary timestamp value. It is really hard to guarantee that
>> the endpoint is not being spoofed by a PRISM capable adversary without
>> going to techniques like quorate checking which I think are completely
>> practical in a specialized tracker but impractical to do in an iPhone or
>> any other device likely to spend much time turned off or otherwise
>> disconnected from the network.
>>
>
> I think the important point is that even infrequently connected devices
> can _eventually_ reveal the subterfuge.
>

I doubt it is necessary to go very far to deter PRISM type surveillance. If
that continues very long at all. The knives are out for Alexander, hence
the story about his Enterprise bridge operations room.

Now the Russians...


Do we need to be able to detect PRISM type surveillance in the infrequently
connected device or is is sufficient to be able to detect it somewhere?

One way to get as good timestamp into a phone might be to use a QR code:
This is I think as large as would be needed:

[image: Inline image 1]



-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20130916/5dc3b1b3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qr-256.png
Type: image/png
Size: 2465 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20130916/5dc3b1b3/attachment.png>