[Cryptography] Follow up on my password replacement idea

[Phillip Hallam-Baker]

On Tue, Sep 22, 2015 at 8:40 PM, Bill Cox <waywardgeek at gmail.com> wrote:

> On Tue, Sep 22, 2015 at 1:35 PM, Phillip Hallam-Baker <
> phill at hallambaker.com> wrote:
>
>>
>>
> This effort sounds like a ton of work requiring a lot of good
> engineering.  If it did work out, it could be pretty huge.  Is it possible
> to sign up for an account, yet?  I would be interested in kicking some
> tires.
>

Still a ways off, getting close though. About a month of coding and a
couple of weeks documenting.


> Protecting those private keys is difficult.  Malware might sniff them when
> the user unlocks them.  A co-worker and I would like to build an
> open-source a hardware-backed signing library with a common API on the
> major platforms.  For example, the new SGX Intel extensions can enable more
> secure rapid key signing.  Some operations have to be super-fast, like
> Token Binding signature operations, while others, such as unlocking a key
> when a user enters a password, can be slower, and may rely on signing in
> secure hardware, such as a TPM.
>

Protecting the keys is easier if every machine has different keys and keys
are never ever removed from devices, only deleted.

I am particularly interested in Matt Blaze's proxy re-encryption work that
was mentioned here. That can be added in as an extra layer of security.



One criticism I'm sure you hear is that the Mesh publishes private keys to
> the world that can be used to "track" users.
>

I am applying some things I learned working for Tim Berners-Lee on the Web.
(Meta Mathematical Mesh is MMM which is a reflection of WWW). One of the
most important being get the user interface right as your first priority.
Don't be afraid to do less than 100% of the problem in the first iteration.

The web succeeded in part because it just threw out search and referential
transparency as problems to be solved by other means. Google and web
authoring tools with checking for dead links filled those gaps.


Once we get something working, we can work on reducing the scope for
traffic analysis. Once very simple control is to pad profiles to prevent
attacks based on guessing the number of characters used. Another is to use
the hash of key values for indexes rather than the values themselves.

Yet another scheme to consider is that there is a division between the
portals (DNS registrar equivalent) and the mesh providers (a sort of
confederated registry). At present updates are reflected in real time. But
I am thinking that should change and instead a given portal should limit
mesh updates to one per profile every 24 hours. That limits the amount of
churn in the mesh without significantly exposing users to a portal capture
attack (user switching costs must always be negligible). It also limits
privacy leakage to a minimum.


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.


Yep, these are tough problems.  To take this to the next level, the Mesh
> may want to consider more than just signatures.  For example, if suddenly a
> device is correctly authenticating to the Mess from Russia when all the
> other user's devices remain in Idaho, that's a signal that maybe more
> authentication factors are needed.  This can be more devices, answering
> security questions, or sending an email to the user's default account
> asking for confirmation.
>

An authentication profile could specify geolocation data and that could be
used to limit access. But then you leak more information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150922/70d9f0f1/attachment.html>