[Cryptography] Follow up on my password replacement idea

Ray Dillinger bear at sonic.net
Wed Sep 23 16:04:05 EDT 2015



On 09/23/2015 06:29 AM, Bill Cox wrote:

>> But using the Mesh is going to expose people to a degree of traffic
>> analysis, no question of that. Just like the PGP key servers do. I am ok
>> with that if the amount of leakage isn't significant compared to what we
>> leak by using IP in the first place.

It is difficult to imagine an IP replacement that doesn't leak a
huge amount of traffic analysis fodder.  Difficult, but fun.  On
a small scale you can use something like the DC-net software.
On a larger scale there are things like Tor.  So, at least in
theory, you could have a Tor-like system with gateways into
smaller DC-nets rather than IP exit nodes, and then use
something like namecoin for DNS and key infrastructure. It
would be chaotic, hard to route anything, high overhead,
and considerably higher latency than we're used to .... but
it could work if enough people really wanted it to.

Unfortunately a lot of the biggest stakeholders have a vested
interest in tracking that traffic information.  The people who
actually make a living from advertising and ad brokering are the
same people who invest in development and work on standards, and
they absolutely do not want a world in which they cannot get at
the traffic information.

Oh, any of them would be happy with protecting you from everybody
ELSE's access to your traffic information.  But not from their own.
It reminds me of when the guys from Google tout the privacy and
security of their gmail system, while simultaneously selling targeted
ads based on its content.  Yep, they protect your privacy from
everybody except Google.  and Google's customers, partners,
brokers, clients, contractors, licensees, pets, employee's
ex-spouses, three-letter agencies, etc.

> Actually, I meant privacy issues similar to what we see today with
> third-party cookies that enable advertisers to track your web browsing
> behavior.  The initial "killer app" for the Mesh seems to be a password
> manager, which should do a reasonable job of privacy protection, but as you
> said above, eventually the goal would be stronger authentication using
> PKI.  

I don't see how a password manager would help with the problem of
third-party cookies that enable advertisers to track web browsing
behavior.  I mean, seriously - I hate to be picking on Google so
much, but they're the best example. Go to almost any site and you'll
get cookies from fonts.googleapis.com, from googletagmanager.com,
from googlesyndication.com, etc....

How does it matter that you have a different password for each of
those sites?  The servers in Redwood City know exactly where each
of those cookies gets set and retrieved.  To stop that you'd have
to ban cross domain  requests entirely, and the entire web
infrastructure would then grind to a halt amid much screaming
and gnashing of teeth.  For about three days, until they work out
forwarding on the server side with all information going back to
wherever content is getting forwarded from.  And then you're in
exactly the same position except you wouldn't even be able to see
the domain names anymore.

> So, how can we authenticate users in the presence of malware?  It's
> complicated, ugly, dirty, and painful.  You can't simply "solve" it with
> PKI.  We have to take every advantage we can get, and even then expect to
> lose way too often.  Some steps we can take in no particular order are:

I think far too many people place far too much faith in the idea of a
PKI.  The reality has never yet measured up to the faith.  CAs get
compromised, certificates get stolen or forged, people assuming
trust is transitive in a "web of trust" find out it isn't, people
sign certs on the basis of bogus paper ID, and people blindly accept
ALL attestations from ANY CA - even a completely bogus one on the
other side of the planet - if it means they can watch cat videos.

As far as I can see trust relationships are binary.  That is, every
pair of parties has a separate trust relationship, and attempts to
mediate it all through a universal trust brokerage such as a PKI are
at best difficult and at worst counterproductive.  If trust is
binary, we might as well be using symmetric-Key crypto and all of
our key managers darn well ought to support symmetric key crypto.

> Solid authentication is the one place where we really need to leak a ton of
> information, preferably only to a semi-trusted third-party.  

I -- _really_ hate that.  I keep hoping that there's a way for
some protocol to take information like that into account without
trusting it to someone who has the capability of disclosing
it without my knowledge or permission.  But I haven't come up
with such a protocol yet.

Objectively, you're probably right.  If I bought gasoline and a
burrito in Pratt Kansas an hour ago, I'm not likely to be buying
lobster thermidor in Monaco right now.  For one thing I wouldn't
be hungry again yet.  And I'd be happier if the bogus attempt to
use my account failed.

But, darnit, I don't want someone looking to be able to tell
that I bought a burrito and gasoline - OR lobster thermidor, if
it turns out that it was the previous rather than subsequent
purchase that was bogus.  I also really hate the idea that
someone can look at something and see that I was in Monaco -
or Pratt Kansas, whichever - at a particular date and time.

And yet I can't deny that if I ever used my phone to access my
bank account (which I don't, but which most people do) then the
operator of a wi-fi hotspot with a DNS proxy and a "clever"
bit of malware performing a downgrade attack and an MITM, could
sell my bank info to somebody who went on a holiday in Monaco,
or somebody on a road trip across Kansas, and I don't want to
get stuck paying for purchases I didn't make.  It would only
require that I did something ordinarily stupid.  Something
ordinary people do every day.

> This is where a semi-trusted third party can be valuable.  The entire
> history of a user's MAC addresses, IP addresses, geolocations, operating
> system, web browser, and every other aspect of the user's behavior can all
> be taken into account along with passwords and device-based PKI assertions
> in making an authentication decision.  

Right, but I absolutely hate it when "trusted," as in this case,
means only "capable of doing harm by betraying others." Is there
*ANY* way we could use an untrusted party instead?  Computation
on undisclosed information?

				Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150923/e06e8acd/attachment.sig>


More information about the cryptography mailing list