GnuPG can now be used to perform notarial acts in the State of Washington
lists.gnupg.org
lists.gnupg.org
It seems to me that my YubiKey setup (done following https://github.com/drduh/YubiKey-Guide) is substantially better in almost every respect than the state-provided smartcard.
I intend to publish a signed PDF document (signed with the state-certified RSA key) that says that my GnuPG keys are really mine.
Would you care to explain the differences in detail?
As far as I know the EU qualified certs are also required to be stored on smartcards so the only difference vs Yubikey would be Yubikey's portable format (it is a smartcard reader and a smartcard in one device).
* I was able to generate my GnuPG keys myself and I know (to the extent that I trust my computing environment) that I am the only one to have access to the secret key(s),
* the state-approved qualified cert is only a single RSA key, for signatures,
* you don't get to make a backup of that key,
* as a result, it can't really be used for anything else than signing documents, so forget about encrypting data or using it for authentication for example (cases where you really do need to have backups),
* the key is stored on a physically inconvenient device (smartcard) and you need to have one and only one of those,
Plus, of course you get the whole beauty of crappy PKI infrastructure (why does every company dealing with certs have to be shady, have a crappy website and in general be a mess?). But that is beside the point, I guess.
* As far as I know upon cert renewal the new cert is generated on your computer, uploaded to the card and then deleted - you could theoretically intercept that but I don't see why you would - the key is more secure on the card
* The state-approved certs one is for e-identification (when PIN is entered also authentication), other for signing (AFAIK not RSA but EC)
* See point one
* Encrypting data can be done but as the software warns, it's to protect the data during transit not when idle and nothing is stopping me from using the card daily to log into my bank and other services I need to use
* The key is stored on the smart card but you can get multiple (AFAIK at least for e-identification).
Don't know much about the Estonian PKI infrastructure though and it seems stable enough for daily use without any noticeable hiccups.
I have to trust the companies that provide the issuing services, which I do not like.
I wrote a summary of this setup [1] a while back, that might be helpful, though yubikey has a good writeup [2] already.
Honestly,I think it's an alright piece of software but the project became the way it is as a result of the massive gnupg adoption in the *nix world and lack of competition.
If it isn't cross-platform and user friendly,it shouldn't be used by the average citizen. As much as the cryptonerd in me likes this news,Gnupg as it is shouldn't be used for official matters. Most lawyers and judges would struggle to use it.
My employer requires that emails with certain types of content be sent with a GPG signature. I spent a few hours today figuring out the best way to do it. First, I used the CLI to < echo "..." | gpg --clear-sign > and paste that into Gmail (web), but the receiver didn't know how to verify the signature (Mac Mail with GPG Tools).
Eventually I settled on Thunderbird with an add-on. It took some googling because the add-on defaulted to "Junior" mode. Eventually, I was able to send emails both signed and encrypted.
So, the issue to me is that there needs to be a standard that can be easily integrated into commonly used communication tools, like Gmail, SMS, etc.
Private key portability is also a problem. I have a USB-C yubikey, and it works on my laptop and my phone. Once USB-C becomes common, maybe carrying your private keys around with you will be much easier.
No affiliation with them. Just have an account and dig their ability to make pgp less intimidating.
I'm looking forward to a chip implant from yubikey on their next gen!
Just make extra, extra sure you click the encrypted file in attach dialog, not original. It can help to put them in different directories.
You will never have cross-platform and user friendly signing software that also has bulletproof security. Let the people who are skilled enough to know what they are doing continue using GnuPG.
Example: Think of the simplicity and security of a cryptocurrency transaction as compared to a traditional bank. The crypto transaction is so much simpler, easier, and much much more secure.
I work in a bank, and there are so so many moving parts all with a myriad security weaknesses all chained together to make a transaction happen. First there's the web portal where the customer initiates the transaction. This is HTTPS which has well known flaws and so many things that could go wrong. Then his transaction goes into a SQL DB in the bank intranet, could be attacked hundreds of ways, then scripts process it into an ACH file, encrypt it with PGP, and SFTP it to the Fed. Those PGP keys were exchanged through unencrypted email, and the SFTP password was exchanged over the phone. Then the Fed uses a similar process to send it on to the destination bank, each step adding additional weak points.
The cryptocurrency transaction, on the other hand, is a well defined mathematical problem with no ambiguity, few variables, and a few easy concepts to understand. Yes, there are a handful of things that could go wrong, but they are well define and well understood. In comparison to the bank transaction, the whole thing is just so simple, beautiful, and easy.
Or was the parity wallet multi-sig attack something that most lay-people knew about as a risk before it happened?
IMO that's more of a problem with smart contracts than with cryptocurrencies as a whole. if you allow anyone to write code that controls millions of dollars, there's going to be ten different implementations and a hack in one of them is virtually guaranteed. on the other hand if the multisig mechanism is part of the network protocol, there's only 1 implementation which will be better scrutinized. even if there was a bug, at least the intention is clearly conveyed and can be fixed with a non-controversial hard fork. see: bitcoin's block reward integer underflow hack vs ethereum's DAO hack.
Or the network could be compromised through any of hundreds of other ways: email, USB stick, insider attack, etc. etc. etc...
And that's just my bank. Any given transaction will go through several all with similar weak points, and some of them with firewall admins even less competent than myself.
To me there's just no comparison. The scale of failure modes or attack points for a bank is way way bigger than any cryptocurrency. The reason it works at all is banks have well-paid guys like myself pouring over every detail and keeping things working.
But if something goes wrong in cryptocurrency, whoops, guess I should have just known better.
A public benefit or nonprofit setup for a bank with strict rules in a country with strict rules is way more trustworthy and efficient than the average cryptocurrency. The tech is also better since an ACID key-value store plus the kinds of credit and smartcards we already have is all you need for majority of activity. Stuff like FoundationDB hits ridiculously-high transactions-per-second with strong consistency. Banks already have lots of methods for catching fraud. A simple, online bank will have less go wrong technologically, legally, and so on since every part is field- and court-proven.
I was comparing the network, protocols, and interfaces that make the transaction happen, not the currency itself. Please don't take this as a endorsement of cryptocurrencies, because they do have problems.
Even with improvements you mentioned, there is just no comparison between the technical and mathematical simplicity of the cryptocurrency transaction as opposed to a bank transaction.
The blockchain was a truly genius innovation. It's that kind of out-of-the-box thinking that I believe we need more of and applied to more varied problems (and obviously not blockchain again, because that would be thinking in the blockchain box).
A bank transaction is this:
MoveMoney(FromThisAccount, ToThisAccount)
One with decentralized checking is this:
MoveMoney(FromThisAccount, ToThisAccount) PostToLedger(CurrentStateorChanges);
On other system, CheckChanges(CurrentStateorChanges).
That's it. All the extra stuff is for extra requirements or overhead from traditional, bank designs. It's not requirements for centralized banking. You can do the basics of banking, with crypto, on 16-bit microcontrollers on smartcards. You can do the ledger in memory with snapshots for persistence. You're talking load and store instructions plus some I/O. Super simple. The stuff proof engineers are mathematically modeling, implementing, and verifying down to the assembly is much more complicated than this.
Now, with cryptocurrency, it starts with some pretty math. That turns into a way more complex implementation than what I just described. Inevitably because their protocols are intrinsically more difficult than centralized protocols that just publish ledger for decentralized checking. Even the tools for verifying them are more in infancy than those for traditional systems. Then, there's the mass of code they use like Linux to operate. Then there's developers that can make changes. There can be lawsuits forcing things to happen. A lot more than math goes on with the cryptocurrencies even though proponents talk like it's just math that you can trust.
Now, someone might say their complexities aren't nearly as bad as traditional banking or weaknesses are worth it. The former might be true, but nobody has proven the latter given a centralized non-profit can do almost everything better. I haven't even seen opponents of traditional banks attempt to do better with centralized design. I have seen for-profit companies like PayPal, Western Union, Venmo, and an online bank in Go language vastly improve on the situation with clean-slate designs getting lots of market share away from bankers. Had idealists done that, they'd have millions to billions to spend on experiments like cryptocurrencies plus made a huge, positive difference in people's lives. That's because they are actually using the centralized alternatives based on traditional currencies. Can you imagine how much better they'd be if they were public benefit or non-profit companies with stuff in their charter and agreements protecting the customers? And that leverages existing laws that lawyers understand well.
Idealists opposed to traditional banking have done that, with significant success. Hence, public benefit banks, public banks, and credit unions.
What would be an example?
From my own experience it seems easy until you actually get into the details.
Pgp is an ingredient, it’s not the recipe. You can build a lot of great things out of it, but I’m not sure why you’re attacking letting notaries use it if they want to. It’s a perfectly adequate system that requires attention to detail, just like any alternative.
Of course you're right, real life gets complicated and messy, and things are never as simple as it seems they should be. Nevertheless, I do believe we, as the technologists designing and building the systems that the world runs on, should put more careful thought into making them fundamentally secure and easy to use.
Nothing wrong with letting notaries use PGP. I think that's great.
People take good security for granted. Look at HTTPS,all you see is the green lock as it's interface telling you the connection is secure.
Thankfully things have been improving on all fronts in recent years, but I'd still say HTTPS is a great example of when something that should be simple to use was totally cocked up.
I'm talking about all aspects of it. But you shouldn't dismiss the server / admin end either because if security is too difficult to set up then you can bet a lot of people will set it up incorrectly thus leaving end users vulnerable.
> For users,a properly configured https site shouldn't cause any trouble.
Most users cannot tell if a HTTPS site is properly configured though. And as I mentioned in my previous post, many users have been trained into complatency with ignoring certificate errors due to the widespread use of self signed certs and how browsers will display the same styled error message for that as it would for arguably more serious SSL errors.
> Even on servers,I'd say it's always been fairly successful if you consider the successful setups.
"Successful" in the sense that we have a secure method of transmitting HTTP traffic. However I question whether it's successful with regards to the "user friendly" point you're trying to make when you consider that great many servers were not and still are not correctly set up (eg running insecure TLS cithers, supporting SSL 3, etc). Given my PCI DSS training as well as working with the gambling commission, I've spent a lot of time analysing network traffic and you'd be surprised just how much out there isn't following best practices. Even more worrying is a great number of devices (eg computers, smart phones, network devices, etc) don't even support what should be the minimum security requirements like TLS 1.2.
The "cross platform" bit is completely irrelevant. The user friendly and strong security (there's no such thing as bullet proof security) points are certainly achievable with a little effort.
User friendly design is about understanding user behaviours, UI/UX, etc. It's about designing sane workflows and user interfaces. Whereas writing cross platform code is a technical complication regarding the internals of a particular application. The crossover is between cross platform development and user friendly design is just which UI toolkit you choose to use (ie Electron, Qt, native platform-specific widgets, etc?) and even that is really just an implementation detail rather than a fundamental roadblock in designing user friendly applications.
Thus the requirement for something being user friendly shouldn't affected by the requirement for something being cross platform.
This is why I say the cross platform point is irrelevant. Not because cross platform solutions aren't important but rather because they're not the reason many solutions aren't user friendly (the reason is much more simple than that: they were designed by technical people to be used by technical people).
Anyway, the puropose of a security solution is to reduce risk to an acceptable degree. There are already plenty of apps and protocols that allow for secure message transmission and storage(signal,wire,tls,ssh,etc...) Why do you think GPGs task is special?
FYI -- gpg is just a pgp client.
We already have many programs that are cross-platform and user-friendly while also addressing way more complicated use cases than cryptographic singing.
Is there, right now, a better (security-wise and usability-wise) way to digitally authenticate a message (document/binary/payload)?
For modern message encryption, PGP is inferior to alternatives and generally should be avoided:
1. It lacks any native notion of forward secrecy or meaningful compromise recovery, which is table stakes for modern protocols.
2. Partly as a result of (1), it leaks meta-information; in particular, it's difficult to send deniable messages with it.
3. The most compatible subset of its protocols are built on 1990s cryptography, including non-AE bulk ciphers and RSA.
4. Its tooling is difficult to use, even more difficult to use with what we'd now consider adequate opsec, and far more difficult still for an ordinary person to use that way.
5. That tooling is of wildly variable quality; PGP sees somewhat routine vulnerabilities in its tools, which invariably get downplayed ("that's not a bug in PGP!").
6. Its most mainstream use is to attempt to layer modern message security on top of email, which is its own can of worms.
Generally, you should use Signal or maybe Wire (if you're a Signalphobe) in preference to PGP.
For an application where it really mattered, you'd want to see a signature system derived from SHA2 and Ed25519, with no backwards-compatibility towards archaic cryptography. There's nothing mainstream that really gives you this right now, but really there isn't much (outside of blockchainia, which is already hipster-deep in modern crypto esoterica) that really demands secure digital signatures.
For me PGP is problematic in that the protocol itself is really confusing with a lot imprecise concepts. Even the definition of a "key": is it the private key part, the public part, the public/private pair, a certificate, or all of the above? For me, this is where a lot of people get in trouble. You need to understand exactly how PGP works in order to use it effectively.
I don't really see either of these problems being fixed any time soon, unfortunately (for me, anyway ;-) ).
What would you use it for?
Imagine I am a remote worker who does contract work. I have never met my employer. We want to agree to a contract and show that the information we're working from hasn't been compromised by someone from the outside. Ideally, I want to authenticate messages from my employer, and they want to authenticate messages from me.
It's important to realise that encryption is not necessary here. We just want to show that nobody is injecting requirements. If it gets down to a he-said, she-said argument, we want to be able to clearly show who said what. Second, identification of the parties is not necessary. I don't care who the employer actually is. I just care that they give me requirements and pay my invoices. Similarly, the employer doesn't need to care who I am. They just care that the banking information I send is really from me, for instance.
Now imagine that the employer doesn't know all the details of the project. They have other engineers who know the details. The employer refers me to that other engineer. Again, I don't care who the engineer is. I just care that they are the person that the employer referred me to. Importantly, I don't care who Google, or any other authentication agency thinks that engineer is, or what organisation Google thinks they work for. I care that the employer is satisfied that the engineer is the correct person to talk to. If there is a dispute, then it would be nice to show that I talked to the person the employer told me to talk to.
That's really all I want. To be honest, it shouldn't be that hard to implement. I think it's just that OpenPGP's implementation of WoT is so screwy that people just abandoned WoT without realising that it has use cases.
The example I gave is pretty ordinary, but you can probably imagine situations where one contact (that you don't know) wants to refer you to another contact (who you also don't know) and it's important that you are 100% sure that you are talking to the right person. In some cases, you want to make sure that nobody else is involved in the transaction, because it leaks information. In those cases a CA is really, really bad.
Edit: grammar
In your example, how did the remote worker discover the employer?
I won't argue the "there isn't much" part. That might be true. I will add trusted timestamps which were using hash chains before blockchains were invented. Surety is my goto example. Even they jumped on blockchain hype to score some money, though. (sighs)
https://en.wikipedia.org/wiki/Trusted_timestamping
Disclaimer: No affiliation with Surety or endorsement of them. They were just best example I know of company doing this for a long time.
Also, logs and accounting records. Some older papers I saw talking signatures were wanting to keep records from being tampered with over time. Those two are examples where strong, signature technology could come in handy. They mostly defaulted on paper and people, though. Probably a better choice given how computer security played out.
That seems hard to believe unless I am misunderstanding you, because my experience is that any private key use requires auth from my Yubikey and yet I can do encryption without my yubikey plugged in at all.
edit: If by deniability you're talking about PFS, then, well, don't sign something you want to be able to deny having signed. I feel your comment might be misinterpreted to be a critique of PGP encryption when really it's a critique of PFS of PGP signatures+encryption.
So GnuPG to a degree makes it difficult to hide metadata about yourself as many tools will send your public key + data to a key server as soon as they create your key-pair. This is so when people verify you, your easier to find.
This creates a chicken-in-the-box metadata problem where for people to very your public GnuPG public-key is really you that info has to be public, but for anonymity it can't be .
> ...in particular, it's difficult to send deniable messages with it.
It's easy (unless tptacek is mentioning an attack I am unaware of) to ensure deniability -- encrypt but don't sign.
That's practically different than a system like OTR that has forward secrecy by default.
Maybe it is obsolete, maybe it isn't, maybe my tin foil hat is firmly in place. But it just seems like a thing people like to say to almost make sure other people don't bother trying it or using it.
Maybe that's because it's difficult to use, maybe it's because it works and does do things securely and some people don't want that.
There's so many sophisticated TLA's out there influencing 'the conversation' that who knows what to think anymore.
And it's increasingly odd to me. It makes sense to an extent, it lines up with a lot of what we already know about aligned interests, what happens when you challenge someone, etc. But at the same time, it's like the possibility of 'false flag'/Sybil/conversational manipulation is letting people double down on prior beliefs (which could in itself be the goal of the same level of "maybe everyone who disagrees with me is being manipulated").
Whether this is one of those means is unclear, but you're still probably better off using some form of free software for your encryption, and any encryption is still better than none.
This is news to me, but I'm not in "the Security Community". I can't find anything that corroborates this. Why do you say that?
I noted that the Snowden leaks said the NSA of all groups hated GPG since it blacked out their collection efforts. They had to send their limited team of hackers to deal with people doing that hitting other parts of their systems. If NSA isn't regularly breaking it, then it should be strong enough to stop all the threats likely to bother me. I push it plus a limited set of commands that make it easy, but annoying, to use. Instead of email, I just tell people to encrypt/sign text and zip files with boring names. That lets us dodge vulnerabilities that come from metadata, email interactions, and so on. Then, send them via whatever mechanism ranging from convenience to full anonymity.
Truth is I rarely use it because other people rarely communicate to me encrypted or request it. They usually send stuff to my Gmail account in plaintext or HTML. It's there if I need something stronger. It's a pain in the butt. I at least know it has a stronger baseline than most tools which are unknowns to me that I assume will get hacked until seeing evidence otherwise.
What makes it ‘obsolete’ is that it lets you do bad things, like encryption without signing, messages can be partially encrypted/signed, etc. There are too many settings/options that amount to “change this to reduce security for no other benefit”.
The current ideal is software that is only capable of being secure no matter how you use it.
This also only applies to the algorithms that are currently considered not weak.
That means it's not fine. Footguns mean it's a non-starter. Also, you don't get to pick the algorithms when you're the recipient of the message.
What is the target audience for GPG?
I uses GPG for encrypting files for the most part. I also use it for some of the situations where you might use ssh -- not because it's a good idea, but rather because I wanted to learn how to do it.
My main use for GPG, though, is for distributed authentication. PGP's web of trust is quite useful if you know how to use it. Very few people use it, because they don't know how -- and also PGP's protocol makes it very difficult to understand how to use it. On top of that, GPG's UI makes it even more difficult to use. But if you can wade through all that, it's fine :-)
The main scenarios where I think WoT is useful is where you have a historical relationship with someone and that relationship is more important that their actual identity. For example, maybe you exchange haikus with some guy that you don't know. They claim to to be Matsuo Basho, which you think is a bit fishy, but you just want to ensure that all of these haikus are from the same person claiming to be Matsuo Basho (and not someone pretending to be the person pretending to be Basho). Now if your Basho pretender wants to introduce you to their painter friend Claude Monet, you don't actually care if it's actually Claude Monet (you'd best be suspicious). However, when someone claiming to be Claude Monet contacts you, you want to be sure it's the same Claude Monet that your friend Basho recommended to you.
These are the kinds of scenarios where PGP implementations (like GPG) are pretty much the only way. You can do it by hand, but using GPG is very slightly easier. A more realistic scenario might be that someone is giving you requirements for some project and they want to delegate some of the specification duties to someone else on their team. You are a remote contractor and have never met any of the people involved. You are satisfied that your original specifier is valid because they keep paying your invoices, but you want to be sure that any other people you interact with are authorised to deal with you.
* Some package managers use it to sign binary packages. (Think apt-get)
* I personally use it in shell scripts to avoid storing some secrets in the clear on disk. (Use case similar to ssh-agent)
My own shell scripts are maybe more iffy, as I am not myself an expert, but my personal use doesn't see wide distribution.
Personally, I'm of the opinion that APIs should be as misuse-resistant as possible, and GPG is notoriously intransigent about actually acting as a well-designed API. Additionally, The Update Framework (TUF, https://theupdateframework.github.io/) prevents these issues by design.
Importantly though, it's a big project which in this specific instance meant that someone on earth did end up scrutinizing and publishing exactly the sort of thing you linked.
Not in banking anyway. It is widely used to protect ACH files and many other exchanges between banks (at least in the US).
For GnuPG there's an effort with NeoPG, although I don't know how it's regarded. Just heard the name and it is said to strive to resolve some GnuPG issues.
For OpenPGP itself, I don't think it's considered obsolete. I think there are fair concerns about OpenPGP-encrypted emails (when an alternative technology is an option), but I don't have the impression PGP itself is considered obsolete.
- It's hard to use for normal people, it's a lot easier to hand someone Signal
- It allows cipher suite changes, some of which may be weak
Basically, for the purposes you're talking about, ease of use isn't a major concern, but the second one is. A dead simple Ed25519-only signing tool would be viewed as better... does such a thing exist? Certainly it's fairly easy to create one using NaCl or even the reference implementation, but nothing has the popularity of GPG.
https://man.openbsd.org/signify.1
There's also a NIH version of this that I and a friend put together: https://github.com/ruuda/tako
Deterministic key generation is one thing crypto has gotten right.
For basic signing and verifying purposes I believe Electrum and a few other clients actually include functionality for this which could be used as an alternative to PGP.
This is overstated, and at the risk of tinfoil-hattery, I suspect that the NSA would very much like you to think that.
> I'm unclear for which of the many possible scenarios it can be used for.
It can be used for symmetric encryption, public-key encryption, and non-repudiable public-key signatures (analogous to signing a letter: you prove you signed it, but the recipient can publish that proof), with dedicated support for signing the identities of other keys ("web of trust").
Issues you may want to be aware of when using GPG in a security-critical context:
Do not use non-repudiable signing protocols for signatures that you want to be repudiable, obviously. For communications where you can rely on both being online (a much narrower niche than it gets presented as, IMO) there are ratchet-based protocols for notionally non-repudiable signatures ("off the record", intended to be analogous to a phone conversation: the other party can verify that it's you at the time, but doesn't get a signature they can publish in the future) which you might prefer, though I struggle to imagine any use case in which they give a real advantage (they mean there is no cryptographic proof that you signed the messages that were seen to come from you, but there will be as much proof as there is with an unencrypted email, which in practice is usually enough for even western courts, and would certainly be enough for despotic regimes rounding up rebels etc.)
Do not use obsolete algorithms (and GPG is rather more flexible about algorithm selection than it should be).
There is no good library for the GPG protocol, and wrapping the binary is error-prone. For e.g. email client plugins, make sure you're using a reputable codebase that has been subject to code review.
GPG's MAC construction is, while notionally sound, not as good as it should be. Where practical, avoid feeding input to GPG in an automated way and don't decrypt suspicious/unexpected messages.
Cryptographic best practice is to rotate in-use keys frequently; GPG offers you the tools to do this (subkeys) but does not automate their use. Ideally you should keep your master key in cold storage and use it only to sign subkeys, which you rotate in the same way you'd rotate e.g. HTTPS certificates.
While GPG has technical support for a "web of trust" it's not clear what signing a key should actually mean to a user. You should implement your own policies for which keys you trust, and be sure that anyone who you trust to attest to the validity of someone else's key is following a sufficiently stringent protocol before they sign things.
Encrypted email is of course still vulnerable to traffic analysis (and public keyservers by their nature publish even more information about who may be communicating with whom); when using the ascii-based format the subject field is also unencrypted.
> Is there, right now, a better (security-wise and usability-wise) way to digitally authenticate a message (document/binary/payload)?
Not really. The above list may sound intimidating, but it's around the edges: the core of GPG is as good as it gets, and I'd trust it more than anything from the present decade. HTTPS with client certificates is probably a little better audited if you can make the client/server arrangement fit your use case and you trust the 200-odd root certificate authorities.
There's no real reason to use GPG. Make an arbitrary scheme on top of something like NaCl and you'll probably be safer.
We'd often be wrong in such hopes, regardless of how good the underlying primitives are.
We should listen to the experts in that regard, and preferably use higher-level libraries written by the experts when performing common crypto operations. This stuff is easy to get wrong.
I'd welcome some full-fledged libgpg that would reliably implement gpg the executable's functionality, similar to e.g. libcurl vs. the curl executable.
For the record, I'm a Signal user and advocate.
We will undoubtedly have to integrate and access libraries like NaCl. But we should do so in keeping with best practices recommended by cryptographers (e.g. through NaCl's documentation), not by layering an arbitrary scheme on top.
I hope this spreads. As long as notarization remains important, digital notarization is important.
(Seattle law requires notarization on leases over 12 months).
There's a PGP short ID listed on the e-signed document, but it's not yours. There is no point where Docusign checks your ID.
Have a set of Established Authorities who can grant notary status. They give notary status to people according to their own set of requirements.
The notaries can then add a record on the block chain saying roughly "I do notarization act X on document Y" (It'll be the equivalent of what they enter in their log books today and there will be some corresponding stamp that they'll stamp the physical document with, like they do today). They could now even notarize digital documents by including a hash of the digitized document in their record.
Finally, the agency receiving the notarized document (digital or electronic) can easily go onto the blockchain and verify that the document was indeed notarized as claimed and that the notarization is not a forgery.
Each agency that receives the notarized document could have their own subset of Established Authorities who's notaries they will accept. This means anyone could become an Established Authority, but individual agencies like the US Federal Government could publicly say "hey, our Authority Id is 'USRoxs'" but it'll be up to the receiving agencies like England's government to decide "We trust the system the US uses to validate it's notiaries, so we'll add 'USRoxs' to our list of accepted Established Authorities (along with 'TheEnglish' of course)"
Where would be the advantage of the scheme you describe to the current system? There is none. The system already works: people are given power to validate documents by the authority. The authority stores that centrally. The validation is mostly collected centrally. All stuff you can do perfectly fine without needing to run replicated servers storing an evergrowing immutable blockchain sipping authority from the real authority.
The current scheme allows things like secret notarization and revocation, stuff a blockchain is very bad at.
> it'll be up to the receiving agencies like England's government to decide "We trust the system the US uses to validate it's notiaries, so we'll add 'USRoxs' to our list of accepted Established Authorities (along with 'TheEnglish' of course)"
Countries already have systems in place to accept documents made in other countries. Works with official translators and stamps/seals of authenticity.
In better and funny: Blockchains Are a Bad Idea (James Mickens), https://www.youtube.com/watch?v=15RTC22Z2xI
In the U.S. notaries are traditionally decentralized, and a notary often maintains possession of their journals for years if not in perpetuity.
The primary functions of the notary in Common Law jurisdictions is the ceremonial and evidentiary value, not administrative value as in Civil Law countries. (All three functions matter in both systems.) Ceremonial because we can assume that when someone executes a notarized signature we can impute greater attentiveness to the contract. Evidentiary because the notary himself and the required third-party witnesses are (or should be) readily identifiable and available for questioning regarding the circumstances of the execution of the signature, including the authenticity and state-of-mind of the executor.
Plain signatures operate much the same way--we use them for their ceremonial and evidentiary value. It doesn't matter that a signature is easy to forge; the signature is a device for anchoring the act of consent to a concrete environment where we can begin asking and investigating pertinent questions as to authenticity and intent. In practice, the validity of signatures is rarely challenged in court. Either everybody agrees it's obviously or plausibly forged, or everybody agrees it's valid. But disputes regarding the circumstances surrounding the signature are endlessly varied. (Civil Law countries traditionally handle the problem by making notarized signatures the final and only word--non-notarized signatures have no value, notarized signatures cannot be repudiated. They sacrifice fairness for administrative efficiency. The trade-off between fairness and administrative efficiency is at the heart of most distinctions between Common Law and Civil Law systems.)
Public ledgers are not suitable substitutes for either of the above functions, whether according to the calculus of the Common Law or Civil Law systems. Arguably they're a step backwards. They're great for replacing all the other technical machinations of transactions except the most important ones--the ones that allow us to adjudicate disputes regarding intent and similar complex questions.
I'm curious about secret notarization and revocation. Why is that particularly desirable? I guess it would be a poor fit for a blockchain indeed...
You can also often get free notarization at your credit union, public library, local government, church or through your employer.
> Notary services are expensive, and some notaries are corrupt
A blockchain being the place where the act of bureaucracy ends up being stored changes nothing about that.
> OTOH this does seem like a good blockchain application
Exactly. It does at first, because it's about authoritatively storing information, and isn't this what a blockchain is good at? But then you think about how the system actually works and what the requirements are. A blockchain brings you immutable and decentralized storage of peer-validated information. None of these properties are of any value here. We just need a centralized storage that does not forget values by accident, which is basically every other solid information storing system. And most of those are a lot easier to run than a blockchain.
This is where a lot of blockchain concepts seem to break down. In most systems at some point you need to trust the data entered in by humans. But how can the members of the system be sure they can trust other members? Maybe certification or auditing by a trusted third-party? Oh, we're right back to where we started.
Hash the will. Store the signed hash on the blockchain. Then, no one knows what the hash represents until your lawyer reveals the will after you've died.
I don't see what role the blockchain plays here.
[1] and who's to say there aren't multiple signed hashes on the blockchain anyway?
> [1] and who's to say there aren't multiple signed hashes on the blockchain anyway?
The timestamping of the blockchain is the use case. If multiple signed hashes exist, the latest one supersedes all the previous.
> What do you gain if the lawyer has to reveal it anyway? If you don't trust the lawyer[1], just give a hash of the document to the people who would be affected.
I'm afraid I don't understand. Who would hold the original text of the document in your plan?
Edit: Nevermind, I see what you mean, here. I see the issue as one of public record. If there was a revision to the will which no one in the family liked, and benefited some estranged cousin of yours who lived in another country, the family and the lawyer could conceivably hide the new will and the fact that you were dead from this cousin. Having it all on the blockchain prevents this.
The blockchain places the production of the hashes in time; in this case showing that - all else being equal - this will supersedes any previous wills.
Proving things existed at a particular date is important for contracts, wills, IPR, and such.
It doesn't solve everything, you could have a collusion between relatives and lawyers such that they created multiple blockchain entries. But the blockchain would show, for example, if they did it after the subject had died. The relatives would also need to buy off those running the public blockchain, and not just the deceased's law firm, in order to get a legal attestation -- and audits would show the public servants lied. Auditors can be bought off too, no system involving people is perfect.
All hail blockchain as the most amazing non-solution to the problem.
Seriously? Most US banks and credit unions have free notaries for their members. And otherwise is around $5 elsewhere for a simple document.
> Finally, the agency receiving the notarized document (digital or electronic) can easily go onto the blockchain and verify that the document was indeed notarized as claimed and that the notarization is not a forgery.
Or, they could just sign it using their key using old school public key cryptography. If you want to check if a notary is real just use certificate chains, just like for TLS.
What is unique to blockchain is trustless timestamping but timestamping services work very well in the X.509 world and are used for example for code signing (so that even if your certificate expires the signature is valid).
Of cause you could make a blockchain based decentralized SaaS cloud service using Crispr to disrupt the established dogmas! You know to secure funding for your sure to become a unicorn startup.
If participants are willing trust some subset of other participants within the system for certain privileged tasks that are required by the design of this system, why would they not be willing to trust another subset of participant to operate data storage for the system? Note the potential that most any kind of datastore can underlie systems providing replication, operation of copies by multiple independent parties, consistency guarantees, availability through redundancy.
What potential byzantine faults exist in the design of the system such that providing fault tolerance benefits the system? Can those be eliminated by a better design? Can the risks posed by faults be absorbed or mitigated by the administrative/business/legal infrastructure for the system (which probably will have to exist, regardless)?
If byzantine fault tolerance is required, why is a ledger + immutable chain of history objects + Proof-of-* system the most suitable byzantine fault tolerance solution for the system, given inefficiencies (Cost of Proof-of-*, constraints on throughput), inconveniences (Immutability), and introduction of complexity which is auxiliary to the intended purpose of the system (a ledger of currency)?
Do participants have insufficient incentive to participate in the system such that providing them a balance of a currency is required? Can the system be redesigned to better incentivize those participants? If the system provides little incentive to participate in it from its primary purposes, is there any utility in creating the system at all? Does attracting participation from participants uninterested in the primary and ancillary functions of the system to speculate in the value of an auxillary currency pose a benefit to or liability upon the system?
If participants are motivated primarily due to the fashionableness of blockchain technology, do they realize it's not 2017 anymore, what will happen to the system when they catch up and get bored? Is there a way to use an "AI" instead?
Otherwise, they'll have to have one system for US, one system for England, one for India, etc.
If you mean blockchain technology as defined by the original bitcoin paper, then why? What use does the system gain by allowing anyone to participate anonymously (e.g. money).
Blockchains solve specific problems. Cryptographic ledgers, like we already use for things like CAs, are the better choice almost always. Certainly they could be made more like blockchains in their openness, transparency, and participation. But going full blockchain isn't required.
However some people have been using "blockchain technology" to include the ideas of cryptographic ledgers, so I want to be clear.
The issue with digital signatures is that if you're using it to verify physical goods then you have to have to store the digital signature somehow, either email it, print it out, etc and deliver it to the one who's accepting the notarized document. That person will still need to somehow get that signature, obtain the notary's public key, and verify the siganture. And if there are more than one agencies who's documents an organization accepts (think of embassies wanting notarized photocopies of passports from various countries) then that's a lot of systems you have to integrate with.
This blockchain approach simplifies that without requiring all these embassies/organizations to use a service offered by a single company.
And you’re back to square one
This can be done by multiple trusted third parties just fine.
https://blog.cryptographyengineering.com/2014/08/13/whats-ma...
Is there anything wrong with notaries being able to use GnuPGP?
Proof of publication Trustless time stamping Trustless transaction execution.
Let's say you have 2 key pairs as part of your identity. You sign a message with key 2 and publish it on the blockchain at block height H. Then at some point in the future, you lose the private part of key 2 or it becomes compromised. So now you sign a message with key 1 that says "replace key 2 with key 3 from this point on" and you publish it to the blockchain.
Now, any messages signed with key 2 before the replacement can still be deemed valid, but any future messages signed with the compromised key will not be valid.
Who will watch the watchmen?