[Cryptography] Questions of taste on UDF presentation

[Phillip Hallam-Baker]

I have made significant changes and extensions to the UDF specification.
The old draft is in the links below but I am about to replace it with a
very much more powerful scheme. UDF began as an attempt to bring PGP
fingerprints into the 21st century. I have since extended the scheme to
cover nonces, encryption keys, key shares and commitments.

The question I need to answer right now is whether to group UDF values in
groups of 4, 5 or 5+3 alternating.

The following fingerprints all represent the text/plain string "UDF Data
Value":

MDDK7-N6A72-7AJZN-OSTRX-XKS7D (5)

MDDK-7N6A-727A-JZNO-STRX-XKS7 (4)


MDDK7-N6A-727AJ-ZNO-STRXX-KS7 (5/3)


The comparison is not quite fair in that the 5 group version provides
125 bits of precision while the other two provide only 120. But 120
bits is much easier to code because it is a multiple of 8 bits.


Adding another 20 bits to the 4 and 5/3 character version gives us a
work factor of 132 bits, thus meeting the 128 bit work factor we like
to work to:

MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF

MDDK7-N6A-727AJ-ZNO-STRXX-KS7-DJAF


This is one of those choices that you only really get one go at. The
minute I acquire a user is the minute I can't change the architecture.


The 8 bit clean groupings are going to be easier to code. The 5 bit
groupings are likely to be more robust in use.



One of the new UDF types is the Encrypted Authenticated Resource
Locator. I am looking for backers to see if we could use this to fix
filing of expenses, invoices, etc. This is an idea that I proposed
over 20 years ago and was told it was stupid because there is no
business model. Well I have yet to see a better way put into practice.
I have full prior art disclosures on this going back a decade so
nobody even dream of perjuring yourselves to the USPTO like so many
other bastards have in the past.


So lets imagine we are on a business trip. We stay at a Hilton, we get
a drink at Starbucks, etc. and when we get home we have a pile of
receipts that we have to remember to turn in.


What if each of those receipts had a QR code that linked to an
encrypted version of the receipt? What if we didn't need any PKI or
even public key to decrypt it? What if this could be the first step on
the road to finally getting rid of emailed invoices, tax forms, etc.
etc.?


[Yes, can also do it over near field communication and we could
integrate the payment mechanism. Got the specs for that as well.]


So I am going to need some people/governments to invest in this to
realize the full potential. I know that. I also know that this is one
of those schemes that only works as public goods if everyone plays the
same game. So if people want this to happen, it needs a band leader.
Which is where my business model comes in.



Lets start off with a random value

ECDV6-7AY27-MCZZG-L2ZMG-3QD3R

Now lets turn that into a URL:


UDF://example.com/ECDV6-7AY27-MCZZG-L2ZMG-3QD3R


Now we take the electronic versions of the receipts. We can have the
OMG XML invoice, a PDF, etc. as many as are useful. These are
distinguished by content type so we can sort them out using standard
HTTP content negotiation.


We encrypt each of out documents using DARE Message format using
ECDV6-- as the master key. Each document has a separate nonce value in
the KDF function used to obtain encryption keys and IVs


We calculate the UDF fingerprint (SHA2-512) of the random value and
express it with twice the precision.

SCFIN-CQGDR-KG47R-7OVPT-TCHZ7-XKS7D-JAFXI-6OZSL-U2VOA-TZQ6J

We post the docs to the web site example.com as


https://example.com/.well-known/earl/SCFIN-CQGDR-KG47R-7OVPT-TCHZ7-XKS7D-JAFXI-6OZSL-U2VOA-TZQ6J


[If we have multiple content types, configure Web service appropriately]



So when I scan the QR code, the app can perform the same conversion
and retrieve the encrypted, authenticated document and then decrypt it
with the secret key.


[I have elided many of the technical details here that avoid crypto failures]



So to make this happen in real life, what I plan to do is:


1) Finish the revisions to the spec

2) Release the reference code (C#) enabling the non QR code version

3) Make a You Tube video describing the scheme


6) Profit?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20190216/97f40eea/attachment.html>