Congratulations on the launch, Zain and Grant.
I've come across a decent share of passwordless solutions in recent times (like gazepass.com and sawolabs.com to name two of the recent upstarts in the space), while GRC's SQRL has been around a lot longer.
The bane of passwordless auth systems is the whole ceremony around forgot-password / change-password flows (in this case, re-associating a new public/private keypair, on device loss, or on device change). Keybase solved the latter scenario by storing the TripleSec-wrapped keypair with a user-supplied password [0]; though, in a system we designed for our use, we use OPAQUE (password-based) to keywrap the material [1], while Signal recently demonstrated a rather elaborate scheme (passphrase-based) for tucking away user secrets [2]. SQRL solved the former in a rather unconventional way by treating DHKE as a two-way hash function [3], while Keybase has (IIRC) various recovery scenarios due to the nature of their service.
How does keyri.co handle these two scenarios? Backups don't help in cases where private-keys are compromised. Besides, some might even question the security behind backing-up private-keys to Google/Apple in the first place. I, personally, consider it an unacceptable compromise: Using an intermediary like evervault.com / scrt.network may be slightly better (or even MPC [4])?
If I may, I'm kind of curious about the cryptography involved when the authentication is delegated via the QR code. We designed ours based on the Keybase KEX [5] secured over a CPACE session [6].
Thanks.
[0] https://archive.is/XosXO
[1] https://archive.is/zmpxv
[2] https://archive.is/3sTZR
[3] https://archive.is/H72o2
[4] https://archive.is/Ojz9U
[5] https://archive.is/46VzS
[6] https://archive.is/4F1lp
I've come across a decent share of passwordless solutions in recent times (like gazepass.com and sawolabs.com to name two of the recent upstarts in the space), while GRC's SQRL has been around a lot longer.
The bane of passwordless auth systems is the whole ceremony around forgot-password / change-password flows (in this case, re-associating a new public/private keypair, on device loss, or on device change). Keybase solved the latter scenario by storing the TripleSec-wrapped keypair with a user-supplied password [0]; though, in a system we designed for our use, we use OPAQUE (password-based) to keywrap the material [1], while Signal recently demonstrated a rather elaborate scheme (passphrase-based) for tucking away user secrets [2]. SQRL solved the former in a rather unconventional way by treating DHKE as a two-way hash function [3], while Keybase has (IIRC) various recovery scenarios due to the nature of their service.
How does keyri.co handle these two scenarios? Backups don't help in cases where private-keys are compromised. Besides, some might even question the security behind backing-up private-keys to Google/Apple in the first place. I, personally, consider it an unacceptable compromise: Using an intermediary like evervault.com / scrt.network may be slightly better (or even MPC [4])?
If I may, I'm kind of curious about the cryptography involved when the authentication is delegated via the QR code. We designed ours based on the Keybase KEX [5] secured over a CPACE session [6].
Thanks.
[0] https://archive.is/XosXO
[1] https://archive.is/zmpxv
[2] https://archive.is/3sTZR
[3] https://archive.is/H72o2
[4] https://archive.is/Ojz9U
[5] https://archive.is/46VzS
[6] https://archive.is/4F1lp