I wonder about this too. I'm not even sure what this feature is supposed to do?
As best I can gather, this ties signing to keybase.io (which is anchored in a GPG-key). But it's unclear to me how this is an improvement for users. If you sign anything with a nacl sub-key, that can't be verified with gpg? It's not even clear if this will work off-line, when keybase is down, when keybase have revoked your account...?
> Technically, though, this is not a normal 2fa: the devices will share a secret with just each other.
This is exactly 2fa: two devices sharing a secret? Normally your idp and your TOTP app/token share a secret, now two of your devices share a secret?
I very much welcome someone hammering out a standard equivalent to GPG, but based on NaCL, that is: have a master key (off-line), have a private-sub-key (on-line, protected by smart card/pass phrase), enable further sub-keys -- and a companion tool (set) for verifying up the chain (like gpg2 --verify file.asc, but with file.asc being backed by a (device) sub-key, signed by the private key, signed by the "master" off-line key -- and allow for revoking "from this key and down" (eg: I lost my phone, revoke phone-key, my laptop got hacked, revoke my sub-key, and all device keys...)).
But I'm not sure if that is what keybase is trying to do?
I'm not even sure if it really makes sense to keep backwards comparability with GPG -- the main thing would probably be to be compatible with GPG agent and smartcards. For most everything else, I think a new standard would be a good thing. Perhaps with some kind of bridge, for easier transition (eg: nacl-gpg --verify file.asc, which gives similar output/return-codes to gpg, while file.asc can be signed by a "nacl-key" trusted by a gpg key. But the complexity would probably make for a less secure system until everyone could just move on to the new standard).
As best I can gather, this ties signing to keybase.io (which is anchored in a GPG-key). But it's unclear to me how this is an improvement for users. If you sign anything with a nacl sub-key, that can't be verified with gpg? It's not even clear if this will work off-line, when keybase is down, when keybase have revoked your account...?
> Technically, though, this is not a normal 2fa: the devices will share a secret with just each other.
This is exactly 2fa: two devices sharing a secret? Normally your idp and your TOTP app/token share a secret, now two of your devices share a secret?
I very much welcome someone hammering out a standard equivalent to GPG, but based on NaCL, that is: have a master key (off-line), have a private-sub-key (on-line, protected by smart card/pass phrase), enable further sub-keys -- and a companion tool (set) for verifying up the chain (like gpg2 --verify file.asc, but with file.asc being backed by a (device) sub-key, signed by the private key, signed by the "master" off-line key -- and allow for revoking "from this key and down" (eg: I lost my phone, revoke phone-key, my laptop got hacked, revoke my sub-key, and all device keys...)).
But I'm not sure if that is what keybase is trying to do?
I'm not even sure if it really makes sense to keep backwards comparability with GPG -- the main thing would probably be to be compatible with GPG agent and smartcards. For most everything else, I think a new standard would be a good thing. Perhaps with some kind of bridge, for easier transition (eg: nacl-gpg --verify file.asc, which gives similar output/return-codes to gpg, while file.asc can be signed by a "nacl-key" trusted by a gpg key. But the complexity would probably make for a less secure system until everyone could just move on to the new standard).