GNU Privacy Guard and Flotorizer: A Match Made in Cryptography
By JRichard, Davi Ortega, and Martin Adams
You want to share intellectual property with someone, but also need to reduce the risk that they will use it in the future without your authorization. You would like to enter into a Non-Disclosure Agreement (NDA) with that person, immutably record the event, but keep the proprietary nature and contents of the agreement private. And you want indelible proof that the parties reached an agreement.
What can you do? Two applications — GPG and Flotorizer — have the answer.
What is GPG?
Pretty Good Privacy (PGP) is a tool for secure communication. In its simplest form, it is a program that can encrypt, decrypt, and sign messages. It is the de facto security standard for email. GNU Privacy Guard (GPG) is an independent implementation of the PGP standard.
GPG is based on asymmetric cryptography where each user holds a pair of digital keys: a private key and a public key. The private key is obviously kept a secret, while the public key is, well, public. [Note: this article provides a simplified explanation of how users can digitally sign a file using GPG, and why that signature can be trusted. It does not delve into all the intricacies of asymmetric cryptography or GPG’s robust set of capabilities. More information about these topics can be obtained through the various links contained in this article].
GPG allows the holder of a private key to generate a unique signature that can be verified later by anyone who has access to the public key. Why? Because the public and private keys are linked. Only a private key can sign a message, and only a public key can verify the message was signed by the paired private key. But there is more: A signature can also be used to verify the message / file contents haven’t changed since the message was signed.
Let’s assume that Alice wants to send a message to Bob [Hello Bob!]. She creates the message, digitally signs it with her private key, and transmits it to Bob. Alice’s digital signature is essentially a snapshot of the message — a unique number that represents the message contents — which Alice encrypts and attaches to the message using her private key. Significantly, by signing the message with her private key — instead of her public key — Alice can prove that she sent the original message. She can also prove that the message is authentic. How? If the message is forged or otherwise altered, the new message must be signed with Alice’s private key. Assuming Alice has kept her private key secure, Bob can be quite confident that Alice created the message and it has not been maliciously altered in transit.
GPG, using this digital signature process, can secure messages, documents, and other files. The signatures are the forge-proof and tamper-proof equivalent of traditional handwritten signatures, and in some regards, a notary stamp. And other applications, like Flotorizer, can build upon their integrity to further enhance security, trust, and data integrity.
What is Flotorizer?
Flotorizer is a Proof of Existence application that utilizes another set of cryptographic tools known as Secure Hash Algorithm 512 (SHA-512) and the FLO Blockchain.[Note: in the past, other Proof of Existence applications have utilized Bitcoin’s OP_Return function. You can find out why the FLO Blockchain is superior at https://flo.cash/docs/building-dapps/flotorizer.net/.]
A cryptographic hash (or digest) is another form of a digital signature. SHA-512 generates an almost-unique 512-bit signature for the specified text. For example, if abc is the input, the algorithm generates the following hash:
ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f
Significantly, the hash output cannot be used to determine the input. It is a one-way cryptographic function. In addition, if the input is subsequently altered in any way it will generate a completely different hash (sound familiar?).
So why is this important? To start, the input is not limited to letters, words, or numbers. Rather, any digital file can be hashed (documents, photographs, videos files, audio files, databases, etc.). In addition, the one-way nature of the function means that confidentiality is preserved. No one can ever determine what was used to generate the hash, although the exact same file will always recalculate the same hash. Last, but not least, this tool — when coupled with the FLO Blockchain — can be used to verify, timestamp, and prove ownership of a file. Flotorizer uses SHA-512 to create a file hash and hands the output to the FLO Blockchain.
The FLO Blockchain features a unique metadata layer called floData. With floData, users can attach up to 1040 bytes to any transaction and store it permanently and immutably on an open public ledger. By now, you may see where this is going: Flotorizer puts the SHA-512 hash into floData and stores an immutable and decentralized record of it on the FLO Blockchain via a traditional cryptocurrency transaction.
Here’s how Flotorizer works in practice:
Alice creates a fantastic new meme about the FLO Blockchain. She is worried that no one will give her credit for her brilliance, and she will not be able to prove that she created the meme. Being a fan of FLO, she knows that FLO can efficiently store metadata on the blockchain. She also knows that any file can be converted into a cryptographic hash. So, to create some proof that she created the meme, she uses the SHA-512 algorithm to generate a hash for it. She then creates a FLO transaction and appends the meme’s hash to the FLO Blockchain via its floData feature. As a result, she receives the FLO transaction ID, and that timestamped and permanently recorded transaction contains the meme’s SHA-512 hash. She now has indelible proof that her meme existed in a particular format on a particular date.
If you are not as tech savvy as Alice, you can use Flotorizer at http://flotorizer.net/. Flotorizer performs exactly the same steps above, and it does so without accessing the content of the meme. It is a zero knowledge application where the entire process occurs on your computer rather than on Flotorizer’s servers. And if you use Flotorizer, you receive a Certificate that looks like this:
Confidentiality is preserved while an immutable distributed public record is created that proves the file existed in a particular state on a particular date.
I don’t get it — What’s the significance?
GPG and Flotorizer can be combined to help verify a file’s origin, ownership, authenticity, integrity, and existence via asymmetric cryptography and a distributed immutable public ledger. A unique digital signature can be associated with any file and used to prove that the file originated from the holder of the associated private key. For example, the digital signatures from parties to written agreement can be bundled together with the underlying contract and submitted to Flotorizer, creating proof that the agreement and its corresponding digital signatures existed and were joined at the time the combined file was Flotorized. That proof — the blockchain transaction — is indelible, accessible, and easy to use.
PGP and Flotorizer can also be used to protect intellectual property. An inventor, artist, or entrepreneur can use these cryptography tools to prove a particular creation or idea existed on particular date. Two individuals could also use the applications to prove that they collaborated creatively.
PGP and Flotorizer can also be used to confidentially ensure data integrity and eliminate any potential for subsequent malicious changes to a file. A snapshot of the file at a particular moment in time is permanently recorded on the blockchain without the file contents themselves being revealed. Thus, a custodian of records could implement a Flotorizer protocol that would provide confidential, yet immutable, proof of existence.
So, what’s one practical application?
If you haven’t begun to imagine the ways these applications can work to solve real life problems, perhaps the following example will help:
Two developers from the FLO Blockchain community needed to safely exchange intellectual property, so they decided to sign a Non-Disclosure Agreement (NDA). They live in different parts of the world, so meeting in person to sign the NDA was impractical. Having the document and signatures authenticated by a traditional Notary Public was also impractical given the geographic constraints and jurisdictional differences. Even securely recording the NDA became a problem because of its confidential contents. And having never met, the parties needed assurances that one party would not renounce the agreement and claim it never existed. Faced with these challenges, they decided GPG and FLO provided a rather simple solution.
The combination of GPG and Flotorizer has limitless potential in many different settings, including the legal field.
Have any other ideas on how GPG and Flotorizer can solve real life problems? Leave a comment.
Need more information? Check out these links:
How did they do it? — The Dev Notes
The following is the developers’ more technical notes and description of how the GPG and Flotorizer were used to complete the transaction:
First, we added the following clause to the agreement “This agreement is only valid together with detached files of both (2) valid GPG signatures.” To sign the document, each party generated a digital signature with a GPG command:
gpg — output NameOfTheDev.sig — detached-sig — armor NonDisclosureAgreement.pdf.
The signature that resulted looked like this:
The signature, which is produced by the party’s private key, could then be used to verify the party signed the NDA.
To verify the signatures, we downloaded the parties’ public keys and imported them into GPG:
gpg — import key.asc
We then verified the signatures were valid:
gpg — verify DaviOrtega.sig NonDisclosureAgreement.pdf
The verification command generated the following output for one of the parties:
And confirmed the validity of the signature:
Once both signatures were confirmed, the two signature files were combined with the pdf of the NDA in a zip file. The zip file was then Flotorized. The SHA-512 hash generated — 7101D5D66D26C01377F0B37CCF8923F210F31BF344A73A2A2195969ADC372F10E79A45E1DD98FAEB0238AAE3145A8D14726D48256438E7AA55A5E69F82A9297F — was then appended to the FLO blockchain via the following transaction:
6a8c9f4c3a8a4d62d2a8b255b1dadab0cb8ee0184caa370608ee1aeaf2e83dd3
Using the SHA-512 hash and the FLO Blockchain transaction ID, anyone in possession of the zip file and the public keys can easily prove that the zip file — containing the NDA and two signatures — existed on October 14, 2019 and has not been altered since. It also proves that both devs agreed on it.
Now one last block. What about this:
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
GPG software does not know that Davi has been signing most of his code commits to github and gitlab using his GPG key. This directly links his keys to his code. Furthermore, his public key is in his website daviortega.com. Should Davi deny that he owns his key, he must then deny that he wrote all the code signed by the key. Linking his keys in this fashion has a compounding effect on trust.
Sign and Flotorize:
1) Create the .pdf saying it is only valid with valid signatures of all parties;
2) Each party creates a detached signature in plain text with this: gpg -o NameOfTheParty.sig — detach-sig — armor NameOfThePdfFile.pdf
3) Someone collects all the signatures and pack a .zip file with all the sig files and the original text;
4) Send the .zip file to all parties;
5) Flotorize the .zip file.
Verify:
1. Calculate the hash of the .zip file and check if matches with any hash in the blockchain
2. Open the .zip file
3. Verify if each signature is valid with gpg — verify
