[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