[Cryptography] Anonymous messaging [was: Email is securable within a coterie]

Ron Leach ronleach at tesco.net
Sun Dec 8 15:26:02 EST 2013


On 08/12/2013 02:25, StealthMonger wrote:
> [snipped and re-ordered]
>
>> Anonymity of *access* is becoming desirable, I think.  But is it
>> attainable?
>
> That would be nice.  Ideas?
>

Some; I'll get to them in a moment.  The purpose in asking the 
question was not to challenge, though, but only to ask what the list 
themselves thought.  Both about inadvertent leakage through access to 
anonymity services, and whether or how anonymity of 'access' might be 
achievable.

Unlike many of the list contributors, we are not cryptographers or 
programmers; we are users, and practitioners only in the sense of 
trying to ensure that our IT systems are secure for use by our staff. 
  We do not work in politics or internal security or any form of 
public advocacy, but our work does involve safeguarding information 
belonging to our counterparties, as most companies are expected to do, 
actually.  Though we already use TLS for communications when offsite, 
we are looking towards anonymity as one more defence, this time 
against our traffic origination (emails to counterparties, to our HQ, 
or data uploads to our servers) being identified as ours, especially 
when working in countries without statutory privacy protections.

We had wondered about some approaches (not solutions, merely the 
beginnings of lines with potential) to anonymising access to anonymity 
services.  I imagine some can be quickly dismissed as impossible, but 
if only one or two rattle around for a day or so in interested 
peoples' minds, then maybe they'll trigger more practical variants.

(i) Access disguised as something else - access to an anonymity 
network encoded in some other innocuous protocol might be an example.

This could take several forms, one might be (surely often suggested) 
upload of travel snapshots to a photosite.  Upload would have to 
(presumably, but I'm wary about any pre-conditions whatsoever when 
thinking through new approaches, because it is too easy to rule 
something out for reasons that turn out later to be circumventable) be 
either

(a) to a photosite programmed to look for such encoding, or
(b) through some proxy programmed to look for such encoding

Though there is still the honeypot and input/output association 
problem with the example as described, maybe this would work if there 
was *also* some kind of honeypot telltale (or non-honeypot assurer, 
such as code or core checksums, maybe, or something similar to the 
code deployment authentication schemes used in crypto security).

(ii) The obvious example, of indirect access through some proxy to 
disguise the originating IP but, again, this (very simple case) seems 
to immediately reveal the fact of access to such a proxy

(iii) Some kind of IP address change, or MAC address change, so that 
origination address as seen by the anonymity service, and by any 
monitoring equipment, could not be directly related to the originating 
computer.  Such an address switching scheme would perhaps best be 
ephemeral, and any specific scheme might exist for no longer than a 
session, and may exist for as little as a frame, perhaps.  The use of 
this type of scheme may be best when offsite staff are working from 
hotels or offices where their workstations have been NATted; this sort 
of approach may be less useful at HQ locations where the uplink (off 
premises to the internet) will likely be a static IP range already 
identified to the organisation.  Behind this idea is the thought that 
MAC to MAC transmission can co-exist on Ethernet segments without 
specific IP addresses (and need not even conform to IPv4, or IPv6, or 
anything, so could be 'invisible' to some extents).

(iv) Taking further these lower level thoughts of IP address use, we 
wondered whether, while working offsite from a hotel, for example, 
using one of the bottom /48 of an IPv6 address (maybe from a range 
already allocated to us) would be separately routable to our 
workstation while offsite, irrespective of the hotel's IP address 
(perhaps using an encapsulation scheme, this isn't clear to me).  Now 
- obviously - this does not solve the problem of anonymous access to 
anonymity services, but I mention it to illustrate that access to a 
service need not *always* be equated with the IP address associated 
with the physical line.  Another example of this, though with longer 
latency, I think, are the 'Provider Independent' IP address ranges 
which can be used via different providers (and used also via different 
physical lines and countries?).  Behind both these thoughts is the 
notion of dynamic routing when a new endpoint comes online, and 
employing that feature to avoid using the IP address assigned to a line.

(v) Lastly, we wondered whether some kind of tunnelling over another 
protocol might be a way forward, though we think the far-end address 
(of the anonymity server) would need to be absent to meet our goal, so 
we were not sure quite how this should be set up.  We haven't ever 
used any of the tunnelling schemes over UDP and we are not familiar 
with their working, but if there was some way to adapt that mechanism, 
that might also be a line worth thinking about.

As I said, we are not cryptographers, others on this list are very 
much more knowledgeable about those matters.  I don't expect anyone to 
waste their time thinking about anything they believe or know will not 
work, and am not expecting anyone to feel they need to respond to any 
of these ideas.  They are offered only to stimulate some thought about 
whether it might be possible to prevent observation of the fact of 
anonymous access, and the different levels at which doing something 
differently might be fruitful.

> TOR is connection-based and deliberately low-latency, so
> anonymity is not possible anyway [1,2].  (NSA-planted reflexive TOR
> defenders, there's your cue.)
>

Thank you for posting the citations.  Though already familiar with the 
TOR/EFF challenges paper (and is the basis of the difficulty I wanted 
to explore), I hadn't seen RD's posting - his own citations point to 
Free Haven's collection of anonymity papers and I've copied a few to 
read.  Useful resource.

regards, Ron


More information about the cryptography mailing list