Vectored Signatures, or the Elements of a Possible V-Algebra.

Once upon a time (in August of '15, to be exact) I wrote a very simple versionatron called 'V'.

Edit: See also Ben Vulpes's excellent introduction to V.

V is a carefully-designed poison against the scurrying little vermin who feed on the proverbial 'fear, uncertainty, and doubt.'

For readers who are not in the little circle of folks who regularly use the thing, I will outline the - very simple - idea: you diff two texts (source code trees, generic human-readables, or whatever cocktail of the two you happen to have) using a mildly-enhanced GNU Diff, sign the output with your PGP key, and publish it. After this is done, people in your WoT will be able to correctly (in logical order!) apply the patch(-es) - and perform a handful of other useful operations - at their leisure. 1

In exchange for a certain amount of headache - and a willingness to endure a bit of Spartan cruelty - V buys you version control with absolute cryptographic provenance of every delta, fully stateless operation (nothing you do will affect the output of a future operation unless you explicitly move files), a total extermination of the familiar "hidden file" shit-soup placed in directories by, e.g., GIT and SVN, and - most importantly - simplicity, via an absolute minimum of moving parts. V fits-in-head.2

Now this kind of thing is certainly not for everyone. But some thinking folks found it to have interesting implications; others - created some very spiffy applications; yet others - expertly re-implemented 'V', to the point where it is almost fit to be thought of as an actual tool.

Half a year later, the thing is in active use by perhaps a dozen people. The one worrisome thing is that most extant V-patches still carry only one known (or, at best, two/three) signatures - seals. Partly this is because people are lazyoverworked. But this is not the whole of it. There is also the fact that the act of producing a V-seal seems to have the connotation of wholesale acceptance, or endorsement, of the payload, and this is quite often The Wrong Thing. Not only are there times when one would like to seal a payload with a caveat of one kind or another, but presently we have no means of conveying disapproval - other than by refraining from sealing. The latter act conveys very little useful information, and no permanent sealed record remains of the effort taken to actually understand the patch. This is a Bad Thing.

One solution that has been floated is the inclusion of human-readable annotations with every seal. And this is well and good, and probably ought to happen, but perhaps it is possible to go a step further!

I would like to seal objects in a way which machine-readably conveys disapproval, doubtful provenance, doubtful veracity, and related attributes. And, naturally this has nowhere to go in classical PGP, and so what I propose here is, for the moment, a mere gedankenexperiment.

The root of the original problem is that a PGP signature per se conveys a scalar - precisely one bit of information: the existence of that signature. But what if it likewise carried a vector ? Can we meaningfully decompose it into orthogonal dimensions ? Let's say, of four 2-bit components, vaguely inspired by the familiar Unix file access permission scheme:

Dimension 7 6 5 4 3 2 1 0 Meaning
'Hands' 0 0 X X X X X X I did not create/modify any part. 3
0 1 X X X X X X I created/modified some part. 4
1 0 X X X X X X I created most, or modified the original beyond recognition. 5
1 1 X X X X X X I claim sole authorship.6
'Eyes' X X 0 0 X X X X I read none. Made no attempt to.7
X X 0 1 X X X X I read some part; and/or skimmed some or all.
X X 1 0 X X X X I read most of it.
X X 1 1 X X X X I read all.
'Brain' X X X X 0 0 X X I do not understand any.8
X X X X 0 1 X X I understand some, and/or poorly.
X X X X 1 0 X X I understand.
X X X X 1 1 X X I understand absolutely.9
'Heart'10 X X X X X X 0 0 I distrust absolutely.11
X X X X X X 0 1 I distrust.
X X X X X X 1 0 I trust.12
X X X X X X 1 1 I trust absolutely.13

... adding up to precisely one byte of information conveying belief regarding the payload. This might seem like claptrap until you realize that this seal vector is able to usefully describe a wide variety of objects, of the kind one might seal:

0xCA A sample of output from a particular hardware RNG.
0x78 My dialogue with an NSA agent-provocateur.14
0x01 A One Time Pad found in the pocket of a dead enemy spy.
0x2A A copy of Macbeth.
0x38 A copy of the Donation of Constantine.
0x03 An encrypted message passing through my hands from one close friend to another.
0xDB Your own PGP key.
0x14 A copy of the MS Windows kernel.
0xFF An order to launch the nukes.
0x00 A copy of a suspected memetic bomb.

Listed in no particular order, and not necessarily of the V-tronic variety. Decoding is left as an exercise for the alert reader! To possibly be continued...


  1. Any instance of a V 'repository' (there is no distinction between a V 'repository' and a working set) consists solely of human-readable texts - in their preferred form for modification: the patches, the keys, and the seals, all of which together can be pressed (the V term for the instantiation operation) into a working copy of the tree, consisting solely of what has been certified by the people whose keys were invoked in the pressing. The dependency order of the patches is automatically respected.
  2. And not merely the source code of V itself - which, in the bulkiest of the extant implementations, weighs in somewhere south of a few hundred lines. The concept fits in one's head, and can be readily explained in a restaurant over a napkin drawing within one cup of coffee.
  3. Or: "I had no part to play in the item's having seen the light of day."
  4. Or: "I had a part in causing the item to exist."
  5. Or: "The item very certainly would not exist in anything like its present form without my doing."
  6. Or: "No human hand but mine flipped, to my knowledge, so much as one bit therein."
  7. Why would anybody sign something they haven't read? There are many good reasons! E.g., to ascertain that the item existed in its present form when you first came across it, for instance.
  8. This is context-sensitive. The meaning of "understand" is beyond the scope of this article.
  9. Generally this category is to be reserved for items like simple arithmetical facts, or your own name, or any other object about the nature and mechanics of which you have no doubt whatsoever.
  10. This category contains no null. Which should surprise no one, considering that the very intent of a seal is to convey some aspect of trust (in the original, unvectorized pgp, this is a vague and extremely context-sensitive thing, here - a more explicit relationship.)
  11. "I am confident that the object, or the objects referred to therein, contain deliberate misrepresentations of reality, and may be dangerous to your health if perceived as fact, and to your honour - if relayed as factual."
  12. "I have no cause to believe that a lie is told in the object or objects referred to therein."
  13. "I trust the factual accuracy of the statement with my life and my honour."
  14. This leads us into meta/reference problems - does the distrust concern the object itself (the veracity of my copy of the dialogue) or of the statements appearing therein? This is to be resolved by the reader. But would it perhaps make sense to specify this as a whole vector dimension of its own?
This entry was written by Stanislav , posted on Friday March 18 2016 , filed under Cold Air, Computation, Cryptography, Friends, Idea, Mathematics, ModestProposal, NonLoper, Philosophy, VTronics . Bookmark the permalink . Post a comment below or leave a trackback: Trackback URL.

6 Responses to “Vectored Signatures, or the Elements of a Possible V-Algebra.”

  • What about having multiple keys, each for a different purpose? One for signing "I read and trust" ; one for "this is how I found the code, recording for history" ; and so on..

    It's probably a pain in the ass, but I think it would fit into existing systems with the least friction. People trying to press a binary can control the output like they already do, by controlling their .wot directory.

  • David Yon says:

    It should be obvious that in general one ought to sign statements about things, rather than directly signing the things.

    Such statements can say whatever you want, and of course they refer to their objects by cryptographic hashes. Example statements might be "package file X is an accurate build of source tarball Y in a clean, sandboxed build environment" (saying nothing about the quality of the source), or "the contact details in key A are accurate at time T" (saying nothing of the keyholder's trustworthiness), or also any of the 16 statements you list in the article, or absolutely anything at all.

    For these statements to be machine-readable, you need agreement on their form and some semantics (oh no! - standard formats!). Your proposal is extremely compact, producing a one-byte statement about the object, with the semantics you describe. Another approach might be to have various possible named attributes, with various possible values, and a defined text format for making the statement.

    Designing the format(s) / languages in which statements can be written is an interesting exercise. I suspect I'd find the one-byte proposal above rather limiting. But I'd need to think longer about what useful, common, things people might want to say in signed statements about other things.

  • St Gregory of Nyssa says:

    You still need a language in which such statements can be written? Can I convince you to give Law French a try? Law French, in a word, is the Perl 6 of langauges, a nat-lang natural beyond belief.

    http://reddit.com/r/lawfrench

  • YOU! Yes, you there! You look like the sort of person who would love to get some spoilers into that there cogitator of yours! Yes, I'm talking about removing all the foggin' from your noggin. Turning these here shiny little seal vector bytes into a human readable representation is a thing that your computamator should be doing. You heard me right, son—your computamator!

    So sit back, relax, and watch the bytes flow as you feed all of these vector-ma-watsits into a device of significant spoilers:

    https://gist.github.com/anonymous/6dd89ebbab2e6dd0f894220922341046

    What that you say there, sonny? Your ma don't let y'all execute strange code from the internet, and pa went to the store three months ago and never returned no mo'? Well boy howdy son, y'all shoulda thought about tellin' me that now, shouldn't ya?

    I'll tell ye what, since it's just this little old thang here betwixt you and I on this here little comment section on Mr Stan's website, I'll even feed you the spoilers without you having to execute on consarn thing. But we don't want any old varmint to be gettin' these here purdy little spoilers now, do we? So I figure y'all can rot13 this spoiler the way our Caesars used to shift before us:

    uggcf://tvfg.tvguho.pbz/nabalzbhf/2onp769p99qo76p5sn7o4131o23rq28r

    Darn tootin'!

  • mod6 says:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA512
    
    Since this original Loper-OS posting on Friday, March 18th 2016, my version of
    `V' has been updated to the following version number: 99994.
    
    You can find the new version here:
    http://thebitcoin.foundation/v/V-20170317.tar.gz
    
    Along with the corresponding signature for the artifact here:
    http://thebitcoin.foundation/v/V-20170317.tar.gz.mod6.sig
    
    
    To read more about this version, see The Bitcoin Foundation's ``BTC-Dev''
    mailing list post here:
    
    http://thebitcoin.foundation/ml/btc-dev/2017-March/000260.html
    
    Best regards,
    mod6
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.10 (FreeBSD)
    
    iQIcBAEBCgAGBQJZEljFAAoJEHIXBai3Hq2vSSQP/398FvxiqyLRE6CswVG3U/A2
    w8qgzfUcIyCW3f2GO0V4kXz59kTZXZ9w/lxDzOkJsEFzuKftpEXPb0yjttp2KViA
    PO1cONAPzFHf+jjPyD0IsztWvkMi4aqrP+gOGY6vDg+PKOoi4k/A4zCxUKzF5raQ
    yv6vQJCU3HgpzgfCUilksY/77xcDHkj9XZBFlBvN4lxPPtiVAhcBE1qh4ClnQm85
    EXmFpneOAb0e/ina1kR1UyHPyKk6dwsDiNrEaN+/z2/GEPOOYGVy1Tgl/6muGbg6
    qR11fZmIWW95y1/RdahUmXWjqfLSrT0UkJRwoJfbnTTCec5t9hjhVEga/97jx+Fq
    Jq2fCevRxrGily2HdGSZ5GkrsTa1xfe05O4iSolOlvG3pIiR9/aydIyazvMBpnBZ
    JQvYCZunInUeJCEWECFH1uyizsxbN3Q8Tlf7TAFYBk3dWEBMyM9+MOlpR7sm+sUx
    CnKj0N84gcz5W+QFPP8pzKj2dPo0rzF2cv8/EzYdlXld90rg5lrt4wZgnVJadBpX
    dSpjdDDfOsD0viunYsu+f5AeerPnCRZ0sAYXeYATQm2BS8oeC6ym3smJwQlDeUAJ
    KqsOiQmE0VpIGX7xYzuw1ucNH2BKyqIXvP6WF3L7BoCkz9brhs05/IfiG/C5pZBp
    Mvo0lVhmDRdj1vt2vXV6
    =1X7b
    -----END PGP SIGNATURE-----
    

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" highlight="">


MANDATORY: Please prove that you are human:

65 xor 32 = ?

What is the serial baud rate of the FG device ?


Answer the riddle correctly before clicking "Submit", or comment will NOT appear! Not in moderation queue, NOWHERE!