Remind me again

Why don't websites use public keys for authentication instead of passwords?

Username
Public key

Forgot your public key?

I agree, the OS should provide some application to manage identities in.
Then you could just choose an identity in a website you want and maybe type the password for decrypting your private key.

Why not both?

>>3
macOS actually does this, with Keychain.app.

>>1
browsers don't support it because the CIA niggers infiltrate all major web browser development orgs. and shill against anything good

>>3
I wouldn't trust Windows to manage my identity.

We could just use ssh instead of http(s)/tls/etc.
Everything would be so much safer and nicer.
In fact, just using gpg on top of http would be much better than the current system.

>>1
I did some very basic experimentation with that a while ago, but then some dude from the IETF told me that they were working on a RFC for a similar protocol, so I abandoned the project.

Found it, the name is HOBA: https://tools.ietf.org/html/rfc7486

>>7
If you can't trust Windows to manage your identity, why do you trust it for anything at all? I don't get it, it's not reliable enough for your identity but it's reliable enough to trust it with the rest of your non-identity data?

>>3

maybe type the password for decrypting your private key.

For a normal user, this is exactly the same, except with the added hassle of having to generate some terrorist ``private key'' shit for g-d knows what reason.

This will never take off.

>>8
using gpg instead of usernames and passwords? yes, that would be a step up. using gpg on top of non-encrypted http? no, that's fucking stupid. gpg is designed for e-mail, not for interactive exchange of small packets like in ssl/tls. it guarantees no replay protection and no forward secrecy.

>>11
Why do you think he even uses Windows? Maybe he's a Linuxoid.

>>13
It is actually possible to implement both on top of gpg. Such as sending a public key signed by the main key of a newly generated subkey for each request to send a message (forward secrecy) and deleting the key when the message is received (replay protection) as well as keeping a timestamp in the message.

>>15
sure it is, but then you're constantly generating private/public keypairs. this is slow, and so is using public key crypto for everything. PK crypto for everything is acceptable for e-mail because they're usually neither big enough nor frequent enough for this to be noticeable (although per-mail keypair generation would probably be a bit annoying), and you can't simply use Diffie Hellmann key exchange due to their asynchronous nature. in a normal HTTP connection, packets are sent often enough for this to considerably slow down browsing and there's nothing preventing you from performing DHKE.

tl;dr stop putting square crypto in round protocols, just use SSL/TLS (it's not perfect but it's the best thing we have now)

>>16

but it's the best thing we have now

But that's ssh.

>>17
SSH for web browsing might be an interesting idea but IMHO authentication is too slow right now. it's bearable when you're connecting to a server for remote administration but it would suck if you needed to prove your identity this way for every website you visit

authentication is too slow right now

su -c "echo UseDNS no >> /etc/ssh/sshd_config"
And if you are connecting as an anonymous user the server would not have the need to verify your certificate, making it even faster. It should not be any slower than an average https connection.

if you needed to prove your identity this way for every website you visit

Only for the sites that require some kind of authentication, so only sites where you have some kind of account.

Not to mention that this kind of authentication would save people from getting their http seasons stolen as well as phishing scams.

>>16

but then you're constantly generating private/public keypairs

Just like how every forward secrecy scheme does.

because they're usually neither big enough

Size does not affect the speed of public key cryptography in gpg. gpg only encrypts the AES key with the pub key.

in a normal HTTP connection, packets are sent often enough for this to considerably slow down browsing and there's nothing preventing you from performing DHKE.

Which means that you can perform DHKE when you use gpg over http.

>>20

Just like how every forward secrecy scheme does.

no, most forward secrecy schemes use symmetric session keys and mid-to-long-term priv/pub keypairs which are generated relatively rarely

Which means that you can perform DHKE when you use gpg over http.

is it still PGP when it's synchronous and includes DHKE? introduction of DHKE alone makes it a different protocol IMO because it won't be compatible with normal PGP

>>21
check em

https://tools.ietf.org/html/draft-brown-pgp-pfs-03

>>23
I'm aware of that proposal, it's based on constantly generating short-term/one-time keypairs which has the drawbacks I mentioned before. using DHKE to generate one-time symmetric keys is superior

>>1 The idea seems logical until you realize people("the users") need to move computers and would have to copy the private key or write it down/remember it. Passwords are things people got used to.
Also, it creates a single-point of failure where if the private key is stolen - everything secured with it is stolen: passwords provides some redudancy, since each site will have different password(if the user is smart enough)

>>25

Also, it creates a single-point of failure where if the private key is stolen - everything secured with it is stolen: passwords provides some redudancy, since each site will have different password(if the user is smart enough)

unfortunately, it's a catch-22. a person can remember a few reasonably strong passwords/passphrases (not as good as randomly generated ones but still not bruteforceable in a reasonable time) but not enough for every site, which means there will be repeated passwords (unless there is a fairly predictable scheme behind those passwords which defeats the purpose). this is made worse by the fact that some fucking idiots not only invent retarded password policies which not only add retarded requirements (must contain special characters, may not contain trips, must end with an 11-digit prime) which in practice make people choose weaker passwords but also add laughable length restrictions which make it impossible to use that 30-character password you got memorized (to make matter worse, banks often do that). the logical solution here is to use a password manager but then we're back to a single point of failure

>>25

Also, it creates a single-point of failure where if the private key is stolen - everything secured with it is stolen

You can protect the key with a passphrase and can use a different key per site as well.

need to move computers and would have to copy the private key or write it down/remember it

Which is almost the same for a password. Except that for pk authentication you can use smartcards.

since each site will have different password

It's quite a bit impossible to have multiple strong passwords that you don't write down or don't use a password management system for it.
I feel sad for the people who are forced to use cloud password management solutions by their company.

Because *its simple*. Simple triumphs robust.

Most of the internet protocols are designed to be the simplest possible and obvious design. Why routers don't do rpki everywhere? It's simple not doing so. Why SMTP or DNS are such shitty protocols when they could be done far more robust? It's simple to keep em shitty.

Why Unix became universal OS for everything except PC? Because it was simple.

As for your question OP, yes, it is trivial to solve all auth problems, government signed citizen keys ensuring you get rid of sybils too - and all can be ZK as well, so no 1984. But it will never happen, because those are not simple protocols.

>>28

Most of the internet protocols are designed to be the simplest possible and obvious design

this is true for older internet protocols but not for the newer ones, especially the ones intended for security. this is not only due to security requirements but also because we don't want to replace the whole proto when one of the primitives becomes insecure - unfortunately, the complexity of those protocols can make them less secure (see: downgrade attacks)

>>29
It's not like people didn't try before (with oauth). It's just that nature of web does not lend itself to something truly robust, as you'd need reasonable pki infra in the first place (which we dont).

Same could be said, for example, about ipsec vs ip. Sure the protocols were designed, but that is a far cry from actual adoption in practice except few niches.

Adoption of extensions violating the "its simple" rule, and often being imperfect improvements happens only when the original simple things get really, really inadequate. ssh and telnet, https and http...

As for website password forms, you can simply generate per site password from master passphrase (see brainpass) - as a kludge for the lack of robust pki. It's not perfect, but works good enough. Just like how ssh copes with lack of trustworthy CAs in imperfect way, or SSL or DNSSEC being generally horrible protocol wise, yet everyone still sticking with it because its a standard.

>>30
ipsec is going to get big in the telecom industry soon because of IMS. I don't think it will be big among customers though because IMS is basically telecoms trying to get people to pay for what they have for free on the internet. also, it's not going to be e2e encrypted IPsec (just user-to-gateway) so you don't even get a privacy boost here.