[Cryptography] DIME // Pending Questions // Seeking Your Input

Peter Fairbrother zenadsl6186 at zen.co.uk
Thu Mar 5 11:16:19 EST 2015

On 05/03/15 09:11, Ladar Levison wrote:
> On 3/2/2015 4:27 PM, Peter Fairbrother wrote:
>> I kinda liked the image field too - treat it a bit like an icon.
>> Optional, of course.
>> Plus whatever the cryptographic protocol needs. That should be
>> enough.
>> And in general, that's all the data which should be in the signet,
>> nothing else belongs there.
> Note the multiple signatures. This will allow implementations to
> "split" the "core" cryptographic portion of a signet from the "full"
> signet, which contains the optional "information" fields, like the
> image, address, phone number, etc. "Splitting" is mentioned in the
> current draft, along with definitions for the different types of
> signet, but it wasn't fully discussed.

I probably didn't read it in enough detail  :(

However, even "splitting" leaks too much potentially-private

It adds a lot of unnecessary and unwanted complexity for
the luser, many of whom who will not understand it, or how to use it 
securely, even if it is simple.

It adds many places where attacks can be launched by malicious actors.

And most important, for a DIME-type signet which will be used for email,
it isn't necessary.

Now if the signet is to be used in a wider context, to encrypt eg voip,
chat, and other end-to-end applications as well as email, perhaps do
your online banking and call taxis, as a single universal user key
signet, then there is a case for optional fields of the type you
mention, with all sorts of personal data in them - but that is _very_
much bigger project than DIME. Then the signet structure should be
designed for that use, rather than for use in DIME, and even designing
that sort of signet would be a big project.

However if you are just encrypting email then there is no need for all
this, and it just adds complexity and places to attack - for instance,
should the fields be searchable?

This is actually quite a big question, suppose I give someone my
DIME-mail address, but I don't want it generally known - if I have my
name in there, and if even the name field is searchable, then ...

So, what do you *need* in an email-replacement signet? Basically, data
which tells the potential sender that the signet is, or purports to be,
the right signet, and that is all. You don't need any more than that.

You are adding all this other stuff - why?  What are the split signets for?

To allow someone to say "I warrant that this is my data, see, it has my
signature on it"? Can't they just do that in a (signed) DIME-mail?

Some other reason?

Making the fields splittable, and having different types of signet, are
just adding modes and options, which we know are not good protocol
design properties.

Who has access to the splits? To a particular split, or to a list of
splits or search of splits on DIMEserver X, or a global search or list?

If you are going to introduce splits then you are going to have to
answer all these questions, and more - and you are going to get some of
the answers wrong for some users, no matter what you choose, because
there are no right answers.

Besides which, you don't and won't have any actual real control of who 
obtains signets, or of the use of search tools on the signets.

Or control of when two split signets are logically linked; avoiding that 
is a nightmare of rat's nest complexity and probably theoretically, and 
certainly practically, impossible.

Just putting that data in there is a *FUKKEN* *GODSEND* for the
NSA/5I's, it will allow then to easily fill in their global
emailaddress-humandetails database.

The best way to avoid this, and actually the only way to avoid this, is
simple and easy - no unnecessary personal data in the signet. Which
means no splits, only one signet, with minimum (and optional) data in
the signet.

If there is no data to collect, no-one can collect it.

But more important, there is no _need_ for split signets; proof: today's
email addresses don't have them, and yet email is widely adopted.

If a user absolutely needs two different signets, just let him have two
signets. If he really wants to put his address, sexual and terrorist 
preferences, and preferred dick size in there, and you want to let him, 
have a "comments" field.

Here is another, linked, question; are you giving up the right to lie 
about who you are, or stay anonymous, in your email? It seems you need a 
CA signet in order to receive DIME mail, but can you get one without 
proving who you really are to the CA?

If not, it seems DIME is pretty bad choice as a ubiquitous replacement 
for email.

> One of the survey questions I submitted to the list asked whether
> org signets should also support "splitting?" Currently, only user
> signets can be split.

I don't understand what the org signets are for. Can't you just use 
normal CA certs? You are using them for FS anyway ..

and it's TOO DAMN COMPLEX as it is.

-- Peter Fairbrother

Something like this, though it is only half-baked:

This is a DIME #1 signet: Actual Field Sizes
Use name @ DIME server
Real Name - optional(?), and users can of course lie
Image - contents optional.
Comments - contents optional
User's Public Key
Dates Valid (CA), CA details, CA Signature of the above
Dates Valid (user), User Signature of all the above
Ephemeral User-Signed Dated DH keypart(s) for FS

Though I'm not sure Image and Comments are necessary, or even wise ..

More information about the cryptography mailing list