Jump to: navigation, search


The purpose of puf/ is to store signatures for Physically Unclonable Objects. To get an idea of what can be done with PUFs, read this proposal for a PUF physical Bitcoin currency made using Namecoin.


  • Any application can retrieve data associated with a PUF fingerprint.
  • These contain non-updateable, non-expiring values with one exception: a single revocation value in case the hash has been compromised somehow.
  • Any PUF record can be composed of multiple PUF hashes and meta-data.

As the lookup process consists of non-human readable names we are essentially dealing with a hash table. This address space probably needs to be reworked to better fit the backend mechanisms for collision handling and any front-end implementations should probably maintain multiple indexes.

It might make more sense to specify types and subtypes in the address itself, such as currency/btc/name etc. This should probably be accompanied by required meta-data to discourage Usenet-style snow-flaking of every category.

Furthermore, someone more familiar with the foibles of previous encryption standardization schemes (like how one defines parameters for each algorithm, feature bloat, etc) should rewrite this standard.


  • namespace : puf/
  • name :

- Fingerprint(s) prefixed by non-exclusive, predetermined sub-categories (/currency/btc, /id, etc). The category is followed by the = sign which begins the exclusive address space which consists of fingerprints. After the = sign, each name is entirely unique and exclusive, slashes do not further demarcate the namespace. Thus if one wanted to include increasing fingerprint sizes such as 32/64/128 (or even novel "naming" schemes) to ease human legibility while maintaining security: puf/currency/btc=horsebatterystaple/0x70096AD1/0x3A9FE2D6DA1B00EC

- max post = name size of 256 characters (512 might be more appropriate given various fingerprint sizes of 32+64+128, etc).

- a-z|A-Z (may be included but does not count as a separate address), 0-9, '/', ':', '.', '-', ' ', (maybe just go with URL encode rules?)

- Slashes used to signify increasing fingerprint sizes: 0x70096AD1/0x3A9FE2D6DA1B00EC

- Separating characters ':', '.', '-', ' ' are all interchangeable and should be stored as a '-' internally. If an address needs to specify which to display it must place a bracketed [] encoding character at the end signifying which representation should be displayed: [-], [:], [.], [ ]. Any address not containing a bracketed encoding character should have a [-] added by the miner. Any addresses without a bracketed encoding should be rejected.

Regexp (maybe) :

  • value : max 1023 characters, json encoded

Registered Fields

The following fields may be part of the JSON value of PUF to specify different individual PUF signatures as well as the contents:

Application Description Rules Examples
Hashes for the PUF and their parameters. Either single hash field or a hash object with a mandatory value field and optional meta-data defining encoding parameters.
 "hash": "22596363b3de40b06f981fb85d82312e8c0ed511"
     "value": "22596363b3de40b06f981fb85d82312e8c0ed511",
     "algo": "sha1"
     "value": "37deae0226c30da2ab424a7b8ee14e83",
     "algo": "blake2",
     "size" : 16
Mechanism and parameters used to read the PUF. Single value (nfc, magnetic stripe, conductance, spectral, etc) or object with mandatory type value and arbitrary parameters.
  "reader": "nfc"
      "type" : "conductance"
      "version": "1.2",
      "mA": [1,3,5,10]
Meta-data not captured in the URN nor the type field. Object with arbitrary key/value pairs.
      "manufacturer": "casascius",
      "batch": "300"
      "date": "2014-1-1"
      "color": "green glitter on black"
      "address" : "31uEbMgunupShBVTewXjtqbBv5MndwfXhb"
Revocation field which is the only update-able field. Not sure if this should just be present if value is false or not as it does count to the overall size of the entry. Mandatory true or false value.
  "revoked": false