GnuPG can now be used to perform notarial acts in the State of Washington(lists.gnupg.org)
lists.gnupg.org
GnuPG can now be used to perform notarial acts in the State of Washington
https://lists.gnupg.org/pipermail/gnupg-users/2018-September/060987.html
180 comments
> 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.
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).
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).
Perhaps not in detail, but in general outline:
* 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.
* 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.
Just for comparison the Estonian system:
* 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.
* 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.
The key is generated inside the card, but the key generation is initiated via your computer (but in fact, initiated by the card management system). So no, you can not intercept any keys in that process.
What I did not like about the process in Poland was that the key generation was done using a computer that wasn't mine. How do I know if the key was really generated on the card, rather than on the PC (and then a copy uploaded to the card)?
I have to trust the companies that provide the issuing services, which I do not like.
I have to trust the companies that provide the issuing services, which I do not like.
I don't know about your particular device but Yubikeys have remote attestation feature so that you (or anyone else) can validate that a given key was generated on the card, not imported (assuming you trust Yubico). This works only in PIV applet. Source: https://developers.yubico.com/yubico-piv-tool/Attestation.ht...
Thanks for correcting me, I vaguely remember external key generation being possible/done but google is being useless at helping me find where I read about it.
External key generation could still make sense as Estonian ID card were suspectible to the Infineon bug. One workaround to that bug would be generating the key in software and putting it on the card. (I'm not saying that's the case, but merely that it may make sense.)
Well, if you contract me to issue you a card, I'll intercept it myself. If you forget your PIN or whatever, I'm not issuing you a new one. I'll charge you for a new yubikey and and put the key on a new, reset card.
You know I've got a shell on your system, right?
The state supplies smart cards?!
I use Yubi-Nano for email signing as well as authentication/security with gpg-agent for remote SSH. I haven't figured out the problems I'm having with multiple sessions/sockets, but aside from the need to recycle my agent from time to time, this is extremely convenient and exceptionally secure.
I wrote a summary of this setup [1] a while back, that might be helpful, though yubikey has a good writeup [2] already.
[1]: https://blog.jeremyredd.com/
[2]: https://developers.yubico.com/PGP/SSH_authentication/
I wrote a summary of this setup [1] a while back, that might be helpful, though yubikey has a good writeup [2] already.
[1]: https://blog.jeremyredd.com/
[2]: https://developers.yubico.com/PGP/SSH_authentication/
[deleted]
Do you have your notary commission yet?
PGP is an alright protocol but I cannot recommend gpg for daily use by non-technical users. They make it extremely difficult to use long-term and simple issues like gpg-agent running as a background process become controversies where they could have just made it optional.
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.
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.
Usability is a key issue.
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.
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.
I like keybase.io for this. I don't recommend gpg stuff to non-techs...except when it's fairly straight forward, they do a good job.
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!
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!
Ask if they'll let you send text and zip files as attachments instead. You just save the file, use the encrypt file option, an encrypted file is generated, and attach that to the email. The receiver does gpg -d (file). It's how I use it. Let's me ignore most of GPG complexity and its potential risks. Also, I use zip with obscure names to hide content type.
Just make extra, extra sure you click the encrypted file in attach dialog, not original. It can help to put them in different directories.
Just make extra, extra sure you click the encrypted file in attach dialog, not original. It can help to put them in different directories.
How is it not cross-platform? It does run on "both Windows and macOS" which seems to be the usual definition.
I meant in general if the software isn't cross-platform and user friendly,it shouldn't be used for official purposes since a significant amount of citizens would be forcibly excluded. Gnupg gets the job done and is cross-platform but isn't user friendly.
Motivated non-technical users figured out how to use it to buy drugs on the dark web. It's not that hard to read a tutorial.
[deleted]
>If it isn't cross-platform and user friendly,it shouldn't be used by the average citizen
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.
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.
Why won't we ever have cross-platform and usre friendly signing software that also has bulletproof security?
We already have many programs that are cross-platform and user-friendly while also addressing way more complicated use cases than cryptographic singing.
We already have many programs that are cross-platform and user-friendly while also addressing way more complicated use cases than cryptographic singing.
This is the exact attitude that has gotten us where we are today (as in, pervasive bad security). "Do what you've always done, you'll get what you always got."
I disagree. It is possible to make decent, good, and perhaps great security that is easy to teach and not too inconvenient that users will rebel. I think it is unreasonable to keep someone from using GnuPG in a legal fashion because average people cannot use it. You will never find signing software with sufficiently bulletproof security that average people can use. To suggest such also implies that average people need to regularly perform notarial acts, which I think is imaginative.
The guy in the cubical next to me made a comment along the lines of "security is always inconvenient and hard" earlier today. And he's just expressing a widespread attitude, but I think it's not (or at least doesn't need to be) always true. If we do it right, we can make simple systems built from the ground up on fundamentally secure principals.
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.
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.
I would argue that the failure modes of a bank transfer are much better understood than any cryptocurrency.
Or was the parity wallet multi-sig attack something that most lay-people knew about as a risk before it happened?
Or was the parity wallet multi-sig attack something that most lay-people knew about as a risk before it happened?
>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.
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.
I cant find much on the block reward integer underflow hack in Bitcoin. Can you link us to more details?
I'm responsible for managing 30+ firewalls at my bank. If any one of them is incorrectly configured an attacker could get into our network and all that would take is a tiny incorrect detail on one line. And I'm keenly aware that I'm a mortal human being and very possibly could make such a mistake.
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.
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.
That's another good point, the reason the bank employs people to pore over every detail is because they're liable to make sure it works right. If I say "send $1000 to account X" and the $1000 vanishes, that's their fault.
But if something goes wrong in cryptocurrency, whoops, guess I should have just known better.
But if something goes wrong in cryptocurrency, whoops, guess I should have just known better.
Banks can run on systems like NonStop we have gotten to five 9's reliability with components simple enough to formally verify. Most people's money doesn't get robbed. If they do, they can mitigate it with $50 max reporting it quickly. They can also stop payment if a provider screws them over. Their stored money is worth about same day 2 as it was day 1 since it's an actual currency aimed at stability. Compare that to cryptocurrencies with volatile value, inefficient systems, lower volume, more hacks, and more closed exchanges.
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.
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.
> Compare that to cryptocurrencies with volatile value
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).
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).
" there is just no comparison between the technical and mathematical simplicity of the cryptocurrency transaction as opposed to a bank transaction."
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.
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.
> 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.
Idealists opposed to traditional banking have done that, with significant success. Hence, public benefit banks, public banks, and credit unions.
Wow. I cant believe I didnt mention that, esp credit unions (Im in one). I was still on my first cup of coffee. Thanks for the correction! :)
> If we do it right, we can make simple systems built from the ground up on fundamentally secure principals.
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.
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.
The next word was literally "example"... :-)
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.
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.
This is my approach to security as well. Security should aim to be simple in implementation but must be simple in interface.
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.
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.
HTTPS is a bad example because it's historically been hard to implement (and often expensive too), defaults to insecure protocols and ciphers on many servers (with clients still supporting insecure versions), and end users have since been conditioned to ignore SSL errors due to self signed certs etc.
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.
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.
You're talking about the server/admin end. For users,a properly configured https site shouldn't cause any trouble. Even on servers,I'd say it's always been fairly successful if you consider the successful setups.
> You're talking about the server/admin end.
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.
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.
You can use it,but your citize peers,lawyers ,judges and anyone opposing you in court need to also be able to use it.
Keybase managed it.
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.
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.
Cross platform is important for official matters because allowing a platform specific tool means the government,legal community and fellow citizens are also expected to use that platform to interact with content made or consumed by that platform specific tool.
I'm a strong advocate for writing platform agnostic code. My point was being cross platform is irrelevant to making something user friendly or secure.
In that case I agree with you,except to say "your platform isn't supported" is user-unfriendly.
Sorry but you're still missing my point (though I didn't really make it all too clear).
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).
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).
"Bulletproof" is a loaded term,something that is bulletproof may not be sulfiric acid proof for example.
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.
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.
So I get the impression GnuPG is considered obsolete by the security community. I'm unclear for which of the many possible scenarios it can be used for.
Is there, right now, a better (security-wise and usability-wise) way to digitally authenticate a message (document/binary/payload)?
Is there, right now, a better (security-wise and usability-wise) way to digitally authenticate a message (document/binary/payload)?
For simple operations like encrypting individual files or applying a signature to a document --- where the alternatives is already insecure --- PGP is fine, if clunky.
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 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.
I wish there was a more modern set of tools that implemented web of trust. I know that WoT will never be usable for the mainstream, but this does not mean that it is not useful at all. There are a lot of authentication situations where it is exactly what I want. Essentially the scenarios I want are: 1) I'm the guy you talked to last time and 2) I'm the guy that was talking to your friend. Having a central authority is inappropriate in a lot of cases, because the participants need to remain private (and it doesn't solve scenario #2).
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 ;-) ).
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 ;-) ).
> I wish there was a more modern set of tools that implemented web of trust.
What would you use it for?
What would you use it for?
In another part of the thread, I kind of specified it a bit, but I'll try to give a realistic scenario here:
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
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
> Imagine I am a remote worker who does contract work. I have never met my employer.
In your example, how did the remote worker discover the employer?
In your example, how did the remote worker discover the employer?
"but really there isn't much (outside of blockchainia, which is already hipster-deep in modern crypto esoterica) that really demands secure digital signatures."
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
http://www.surety.com
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.
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
http://www.surety.com
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.
GPG has supported Ed25519 signatures since v2.1
You successfully read half the sentence in which the term "Ed25519" appeared.
What are PGP alternatives for signing a document or encrypting individual files?
Can you elaborate on what you mean by (1-2) leaking meta-information and making deniability difficult? Do you mean that even when choosing to encrypt but not sign I am leaking definite proof (like a signature) of my private key information in the encrypted message?
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.
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.
Your public key is always clear text, or at a minimum your public key finger print (which can be used via a key-server to find your personal information and public key).
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 .
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 .
This is all true, but is a different question from deniability when sending messages, and leaking metadata when sending information, which is what tptacek claimed:
> ...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.
> ...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.
Not sure what OP was getting at (maybe the difficulty of deniability using GPG/GPG-encrypted mail defaults), but you'd still be sending to a recipient's long-lived public key.
That's practically different than a system like OTR that has forward secrecy by default.
That's practically different than a system like OTR that has forward secrecy by default.
Since anyone in the world can encrypt to a PGP public key, deniability is trivial. It is true that some systems (like enigmail) also encrypt to your own public key when sending messages, but this is also easily deniable.
You usually want the recipient to be able to verify the sender, but not be able to prove it to a third party. Throwing away authentication entirely is a pretty baby-with-the-bathwater solution to deniability.
I think the assumption is that authentication is bare minimum for a secure messaging system, so "just don't sign" isn't really an option.
Well okay but he said "message encryption"; everyone is reading into that to mean authentication as well but I don't know why we should extend that understanding when a plain reading of his post implies a harsher critique of PGP encryption than warranted. It's also amusing how many people downvoted me for disagreeing with tptacek.
I'm beginning to wonder if this is an artificially created theme. In every discussion about GnuPG this type of thread begins and has this type of sentiment.
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.
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.
Do you know what helps? Trying it out yourself and trusting your own judgement. To too many people nowadays, this is the first thing they abandon, while it should always be the last thing to be abandoned.
I keep on seeing this sentiment of "TLAs/short-sellers/Russian content-bots/pick-a-boogeyman could possibly have an interest in this topic, so they're probably manipulating the conversation (conveniently against me and never in my favor). Who knows what to believe?, so I'm just going to continue believing what I believed before."
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").
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").
It is odd, I agree. But on this specific topic I saw a) this weird tone shift seemingly overnight - while I really don't want to make this personal, a prominent individual adopting a quite different communication style to what they'd used before. And it came coupled with b) these inconsistent arguments that just don't make sense. Signal pushers smear those who disagree as "crypto nerds" and yet perfect forward secrecy, the one advantage their system has and the thing they use to argue for all the compromises they made in every other area, is the ultimate "crypto nerd" property: it's elegant and theoretically exciting but practically almost useless (I don't think I've ever seen a threat model where it actually makes sense).
We know the intelligence agencies have had an interest in this particular topic for a long time, and that they use a variety of means to discourage the use of encryption.
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.
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.
> So I get the impression GnuPG is considered obsolete by the security community.
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?
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?
It's considered obsolete by the mainstream security community. Their prior recommendations often got hacked a lot, too. There's a niche group that promotes stuff that is stronger even if there's drawbacks to using it. We also let people decide if they accept those drawbacks. I'm in that crowd.
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.
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.
Thomas Ptacek, who is in the security community, expatiates on this in a sibling thread. It’s a good read, and I think it answers your question , which I didn’t know I shared :)
https://news.ycombinator.com/item?id=18017982
https://news.ycombinator.com/item?id=18017982
The underlying crypto is fine (provided you don’t pick the weak algorithms) and use it correctly.
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.
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.
The underlying crypto is not really "fine". For instance, compare the PGP MDC construction to a modern authenticated cryptosystem.
The PBKDFs for symmetric (secring at rest and gpg -c) are also terrible. I'd love to be able to donate a few thousand dollars to a bounty to get this fixed.
What I meant was that the crypto primitives (the implementation of the math) is good enough for the application, the use/assembly of them (eg: the system) leaves much to be desired.
This also only applies to the algorithms that are currently considered not weak.
This also only applies to the algorithms that are currently considered not weak.
I'm talking about constructions, which are part of "the math".
> The underlying crypto is fine (provided you don’t pick the weak algorithms)
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.
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.
> The underlying crypto is fine (provided you don’t pick the weak algorithms) and use it correctly.
What is the target audience for GPG?
What is the target audience for GPG?
I am probably the target audience :-) Basically, to use GPG, you need to understand how it works. To understand that, you need to be quite technical and also willing to spend several days reading and thinking about what the implications are.
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.
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.
I can think of some uses:
* 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)
* 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)
Neither of those classes of user has the expertise to avoid picking "the weak algorithms."
I more or less trust the maintainers of dpkg and similar can figure it out or have someone point it out to them.
My own shell scripts are maybe more iffy, as I am not myself an expert, but my personal use doesn't see wide distribution.
My own shell scripts are maybe more iffy, as I am not myself an expert, but my personal use doesn't see wide distribution.
Unfortunately, even the maintainers of dpkg/apt, who rely on GPG extensively, don't manage to plug all holes: https://blog.packagecloud.io/eng/2018/02/21/attacks-against-...
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.
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.
Thanks for that. I know that Debian has had security blunders in the past (RNG problems anyone?) so as I typed it I had some hunches, but...
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.
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.
> GnuPG is considered obsolete
Not in banking anyway. It is widely used to protect ACH files and many other exchanges between banks (at least in the US).
Not in banking anyway. It is widely used to protect ACH files and many other exchanges between banks (at least in the US).
Disclaimer: I'm not a security expert.
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.
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 seems to me there's 2 reasons some people view it this way:
- 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.
- 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.
Somewhat offtopic, but I'd love something like gnupg to support deterministic key generation, similar to what BIP39 did for crypto. I currently generate keys on an offline computer, back them up to a usb driver, and the copy the keys to yubikeys. It works, but it's a PITA, and I'm always worried that I'll lose my backups despite going through a lot of effort to keep them.
Deterministic key generation is one thing crypto has gotten right.
Deterministic key generation is one thing crypto has gotten right.
"crypto" is not short for "cryptocurrency", which is what I assume you mean. For many people it is short for "cryptography", and if read as such, makes your comment very confusing.
Apologies - in this context cryptocurrencies would definitely make more sense.
It's short for both at this point. The cryptography community doesn't get to dictate the meaning of ambiguous abbreviations, despite their frustrations. I agree that its confusing in context, though.
In this context it'd be more prudent to use the full "cryptocurrency" though, and not use the "crypto" shortening at all.
It's pretty handy, but doing it for RSA and other crypto systems which rely on large primes is much harder than doing it for crypto systems which can basically use random numbers with a few safety checks just due to the nature of key derivation functions. It is possible though, I seem to remember seeing a paper on it a while back and it should be entirely achievable to do something simple like seed the rng you use for generating RSA keys with an explicit value like that.
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.
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.
For the record GnuPG supports ed25519 keys for some time so there is no need to use RSA.
There is OpenBSDs signify which is used for their packaging: https://www.openbsd.org/papers/bsdcan-signify.html
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
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
This is a port of OpenBSD's code:
https://github.com/aperezdc/signify/
https://github.com/aperezdc/signify/
> So I get the impression GnuPG is considered obsolete by the security community.
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.
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.
I don't know for sure, but I think a lot of people who work professionally on messaging security would argue that NSA very much wants you to use PGP rather than a modern messaging cryptosystem.
Now, that is exactly what an NSA agent would say at this point in this conversation, to further dissuade people from using PGP! Tinfoil hats at the ready! :)
To further thicken the plot imo NSA and other TLAs are a red herring in a world where WhatsApp was acquired for ~20B. I don't believe for one sec that messaging app peddlers just want to make sure users' conversations are secure.
When WhatsApp was acquired, it didn't have meaningful cryptographic security. Facebook funded the integration of Signal protocol into WhatsApp after the acquisition. So there goes that theory.
Absolutely not. In fact, security was a differentiator for competing products when WhatsApp did not have it. Just not one people would care about. It fits nicely.
It's certainly useful for signing github commits[1].
1: https://help.github.com/articles/signing-commits/
1: https://help.github.com/articles/signing-commits/
I feel like the whole "web of trust" thing failed, but otherwise, it's fine for signing things. Debian packages use it for that, for example (with a trusted way of bootstrapping the trusted keys).
Can you use Keybase for this?
Keybase uses gpg at it's core.
Nope. Keybase supports GPG keys, but they haven't been used or generated by default for three years: https://keybase.io/blog/keybase-new-key-model
There's no real reason to use GPG. Make an arbitrary scheme on top of something like NaCl and you'll probably be safer.
There's no real reason to use GPG. Make an arbitrary scheme on top of something like NaCl and you'll probably be safer.
Please, nobody who isn't a cryptographer (to be clear: I'm not one either) should be arbitrarily inventing schemes of combining cryptographic primitives and hoping they're secure in production use cases.
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.
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.
Nacl was designed by cryptographers for exactly this problem.
Additionally, NaCl/libsodium is actually designed as a misuse-resistant API to perform real-world tasks, unlike GPG, where the API is "call this binary and use its crappy out-of-band signaling mechanism to figure out if anything went wrong".
This is what bugs me most about GnuPG - there's no real API, just an executable program with sometimes unreliable output. I mean, there is the GPGME library which wraps the executable calls in a C API (plus few other language bindings on the side), but it doesn't handle all the features the executable offers, often leaving you with a mix of GPGME API calls and "manual" calls to the gpg executable.
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.
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.
Everyone would welcome it, but no-one's putting their money behind it. I suspect one of the real reasons that Signal uses a proprietary protocol (or rather, one of the real reasons that Signal was able to attract funding and improvements to GPG have not) is that having a locked-in userbase makes it easier to persuade VCs that there's a potential profit to be had. Whereas improving GPG would benefit everyone, but there's a tragedy of the commons around it.
What VCs are you talking about? Signal isn't VC-funded. It's grant-funded.
The Signal protocol isn't proprietary, though. But yes, you make a good point. Although I'm not sure how much VC funding Signal really attracts.
Zero. It's grant-funded.
Yeah, I expressed that badly, but meant to imply that they might receive VC funding in the future.
For the record, I'm a Signal user and advocate.
For the record, I'm a Signal user and advocate.
I'm glad it's a good library. I was responding especially to "Make an arbitrary scheme on top of" whatever underpinnings one might choose, good or bad. That's not something we amateurs should ad lib where security matters.
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.
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.
This sounds huge. There's entire businesses centered around very specific state laws like this (cf. notarize.com).
I hope this spreads. As long as notarization remains important, digital notarization is important.
I hope this spreads. As long as notarization remains important, digital notarization is important.
I've used both GNPG and Estonian eID. I have to say Estonian eID is way more usable when one needs to sign anything. The (digidoc4) software is just way more usable, nicer and designed for the task. I wish GNUPG were as good
Docusign has been allowed to be used a notary in Washington; or at least Seattle for notary requirements around housing documents.
(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.
(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.
This is extremely cool, but I wonder in practice whether people in Washington who accept notarized documents/etc would know this is a valid way of doing things? Education seems important here.
Notarizing documents sounds like it could actually benefit from blockchain technology.
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)"
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)"
Notarizing documents is a great example where some people think blockchain is a good use case, and it's never true.
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
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
Notary services are expensive, and some notaries are corrupt. I'm no fan of bitcoin, etc. OTOH this does seem like a good blockchain application, and the fact that it doesn't burn a stupid amount of electricity is nice too.
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...
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...
>Notary services are expensive, and some notaries are corrupt. I'm no fan of bitcoin, etc. OTOH this does seem like a good blockchain application, and the fact that it doesn't burn a stupid amount of electricity is nice too.
Seriously? Most US banks and credit unions have free notaries for their members. And otherwise is around $5 elsewhere for a simple document.
Seriously? Most US banks and credit unions have free notaries for their members. And otherwise is around $5 elsewhere for a simple document.
Private notaries allowed in US?
Not my area, but think of things like a will. You being a billionaire maybe do not want to let your murderous family know that you made a new one writing them out of your will.
> 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.
> 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.
> A blockchain being the place where the act of bureaucracy ends up being stored changes nothing about that.
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.
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.
> think of things like a will. You being a billionaire maybe do not want to let your murderous family know that you made a new one writing them out of your will
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.
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.
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 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?
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?
> 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?
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.
> [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 chances of a document making sense as a will and matching SHA and MD5 hashes placed in a blockchain must be infinitesimal.
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.
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.
We've solved the trusted-third-party problem by having a trusted-third-party (i.e. the lawyer).
All hail blockchain as the most amazing non-solution to the problem.
All hail blockchain as the most amazing non-solution to the problem.
At least in the US generally notary services aren't expensive. Most states set upper limits for the per signature fee that can be charged. Of those that set a limit California is the highest at $15. Of the states that have a set limit the vast majority set it at $5 or less.
You can also often get free notarization at your credit union, public library, local government, church or through your employer.
You can also often get free notarization at your credit union, public library, local government, church or through your employer.
Notaries work differently in different countries; they emphasize different facets of a notary system.
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.
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.
> 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.
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).
> 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).
Now class, please remember. You don’t need a decentralized ledger to store a record of a centralized entity. How many times do we have to go through this?
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.
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.
Bog standard blockchain antidote, feel free to steal and reuse as needed (or disregard as usual):
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?
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?
The benefit of the model I proposed is that from the perspective of the agency receiving a notarized document, they only have to make a single API call to validate any notarized document. Their system becomes much easier to validate and trust.
Otherwise, they'll have to have one system for US, one system for England, one for India, etc.
Otherwise, they'll have to have one system for US, one system for England, one for India, etc.
How does blockchain provide that property to the system? Why couldn't Stripe launch an API for a notary in multiple markets and why couldn't India chose bitnotary while Pakistan chooses dogenotary?
If you mean "blockchain technology" to mean cryptographic ledgers than yes.
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.
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.
Certificate Transparency implements similar aspects to what be considered a "blockchain" (to money hungry VC people), and it's a similar use case to being a notary.
I'm not sure what the blockchain part is for? Digital signatures + if you want a public list Certificate-Transparency-style logs (alternatively potentially timestamping services) seems like they'd do the same?
This is a reasonable point. The main benefit of this approach is that it centralizes the whole process (meaning, gives it a single Api) without making any one entity dependent on another entity for business critical functionality.
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.
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.
Any idiot can create a blockchain though, so which one do you trust?
And you’re back to square one
And you’re back to square one
As some one who usually hates on the blockchain, this actually sounds like a very reasonable use for it. It's a solid step up from the current system of embossed seals, the only potential pitfall it adds is some additional complexity (but I can very easily imagine platforms taking that on, ala DocuSign but for Notaries). My only concern is how this would fare out in an a court system that is constantly behind the times.
The only thing using a blockchain is being used for there is timestamping.
This can be done by multiple trusted third parties just fine.
This can be done by multiple trusted third parties just fine.
This is also possible with SSL. The state/government being the CA, and you being a signed entity. Public crypto fits this mold really, really, well.
[deleted]
Matthew Green had a good post on what is wrong with PGP:
https://blog.cryptographyengineering.com/2014/08/13/whats-ma...
https://blog.cryptographyengineering.com/2014/08/13/whats-ma...
GnuPGP can be used for a lot more than encrypted emails (the subject of that post).
Is there anything wrong with notaries being able to use GnuPGP?
Is there anything wrong with notaries being able to use GnuPGP?
No idea.
In theory, FedEx overnight envelopes, their most lucrative business, just died in Washington state. Am I right?
This is great progress for other locations as well!
That's pretty cool, bro.
tldr; do i still need to pay a notary or can i self attest using a gpg key tied to my email address?
All it needs now is a solid blockchain. Vechain could be one perhaps.
What do you need a blockchain for? Blockchains are necessary when you need:
Proof of publication Trustless time stamping Trustless transaction execution.
Proof of publication Trustless time stamping Trustless transaction execution.
You would use it to add a dimension of time to the signatures. This allows for revoking/replacing keys while still keeping past messages valid. At work we've ben implementing a system like this where an identity is made up of a hierarchy of keys.
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.
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.
Trustless time stamping seems to be a good thing to have for notarising.
If one needs proof of existence features, bitcoin already delivers this trustlessly at scale: https://opentimestamps.org/ You merkle hash effectively limitless data into a single bitcoin transaction. No need to spin up a new (and likely inefficient blockchain) to do notary tasks.
Isn’t trusting the notary the whole point?
Quis custodiet ipsos custodes?
Who will watch the watchmen?
Who will watch the watchmen?
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.