Beep boop - this is a robot. A new show has been posted to TWiT…
What are your thoughts about today’s show? We’d love to hear from you!
@Leo I’ll be honest, I didn’t watch the whole event. WAAAAY over my head. And if this is covered in the last 30 minutes just tell me…so here’s my question. What is the big picture with SQRL? Should I be excited about it? Should I start using it? Don’t all web sites need to start using it before it really matters?
Very interesting presentation. Good job Steve!
1 Like
You should be excited about the promise it offers when sites adopt it: SQRL gives a site no secret to protect. This means that if the site gets compromised, they will not get a password hash (or heaven forbid an actual password) to try and break and then use elsewhere.
You could start using it, but the number of sites you could use it at are still very low. It’s still in the early stages of adoption of SQRL, and there aren’t any major sites that are using it yet. You could still get experience using it by heading over to Steve’s forums for it:
https://sqrl.grc.com/
2 Likes
One of the other TWiT shows will need to follow up with a demo showing how to use SQRL from an end user experience. Leo wanted this demo toward the end of Steve’s presentation, but it quickly got passed over by Steve. After my own fumbling around in the dark with Test Flight, it was wise for Steve to brush off the idea of doing a live demo. The browser add-on “extensions” work fine but having on a mobile device so you can scan a QR code to login is where the WOW kicks in. Really not ready for prime time on iOS yet. I also installed the WordPress plugin, and it works fine too.
2 Likes
The iOS client really isn’t ready for prime time, I’m afraid. I mean it works, but it is still not on the store, and it is really lacking in a bit of spit and polish. There are some necessary features that are still yet to be implemented, such as changing the password on your identity. There is a strict limit on the number of participants in the TestFlight process also… I think it’s 10K people. So if everyone started using it, that would soon be an issue.
Discount what I say, because it’s way over my head too, but I think what we have here is concept and proof of concept.
Steve has extensively documented the concept, and from the overview he gave I think I can see bits of what could make it revolutionary, although I don’t think I’ll ever have the depth of understanding to grasp it fully. Then he has created an iOS proof-of-concept which allows it to be demonstrated. Finally we have publication, which is what the documentation and this TWiT Event achieve.
From here on it’s up to developers and people who commission apps to adopt this for the future. It will take time, and publicity about the viability of the method will need to keep happening for the developer community to start experimenting with it.
2 Likes
This is not a criticism… I just want you to consider that you probably understand it well enough, you just may not realize it yet.
Traditional passwords are one way encoded for storage on the server. You don’t need to understand the SHA hash used (or the PBKDF2 algorithm) to understand how logging in with a user ID and password works… right?
For SQRL, it does one extra step. (This is a massive over simplification, of course, but in order to understand what it does, I think it helps.) It takes a secret value (which acts like a large random password) and does that same hash process, and then converts it to a private key and the corresponding public key. The first time you visit, and establish an account, the site stores the public key in your user record. When you make return visits the client proves that it [exclusively] has corresponding private key that matches the public key stored with the account.
Public key cryptography is difficult to explain non-mathematically, but an over simplification is this: the public key is called public because you can publish it widely, it does not give an attacker an advantage. The private key can do things that the public key can undo. If you sign a message with the private key, it will be publicly readable, and the public key can verify the signature. In this way you can “sign” a proof (like signing a paper contract you will be bound to.) SQRL uses this idea… you sign a document saying you’d like to join a site, and the site stores the public key. When you return later, you sign a document saying “I’m back again” and the site verifies the signature with the public key.
Since only the correct private key can match a public key, and if you keep the private key truly and fully private (much as you do with your passwords of today) then having control of the private key can work as a proof of your identity in the same way that passwords are used for this today.
2 Likes
That’s the point, Steve hasn’t created an iOS proof-of-concept. The standard is completely open and a SQRL enthusiast, who happens to be an iOS developer, threw together the iOS app. The same for the Android app, and I’m assuming macOS.
Anybody who wants to, and understands enough about crypto, can take the definition and write their own application for this. LastPass, for example, could incorporate it into their apps and browser add-ins, if they wanted to.
1 Like
Ah, I missed that. It’s going to depend on enthusiasts creating applications for specific implementations in the early days, until it gets taken up more widely.
1 Like
@PHolder @Clayton @big_D thanks for weighing in on this. You’ve all helped me understand this a bit more.
1 Like
Still looking forward to someone doing a TWiT show on setting up and using the various SQRL clients. Anything to share @Leo or @karsten ?
1 Like
What can I say? We gave Steve two hours - he chose what to talk about. I don’t see us doing any more on SQRL any time soon.
1:50:15 “do it in this show or separate show… what does the end user experience look like?”
@Leo then reaches inside coat and goes on to suggest downloading the SQRL Android client but Steve admits never using the Android client, so that ends that idea. Then @Leo suggests trying iOS client but that involves TestFlight. Leo’s disheartened expression at this point says it all. We just invested 2 hrs and ended up with no client side demo.
I don’t understand what the issue is @sawgrass. No one is forcing anyone to use SQRL. It’s not like there aren’t other choices. It took Steve a long time to feel it was properly designed (over 5 years) but it is still early days for adoption. If the early adopter geeks like it, the rest will come. There is no point having sour grapes at this early juncture.
2 Likes
@PHolder TWiT just seems to be the logical candidate to create a podcast showing how to use the various SQRL clients and browser add-ons. Feels like there would be an audience for such a podcast. Obviously some enjoyed the 2-hr deep dive Steve provided, but there are plenty more folks who would appreciate someone doing a client experience demo. That said, I don’t blame @Leo for not investing any further time in SQRL until it maybe someday matures.
I only just got around to watching this, and its implications are vast. Thank you, Steve and Leo, for publicizing this as early as possible following its conceptual viability. Beyond the durable, robust, and permanence-capable rubric for identity Steve articulated, I see in SQRL’s serialization (however marginal and grudging from Steve, at this point) the operation of necessary principles to facilitate intentionally finer-grained, more narrowly scoped interactions such as anonymized but traceable distributed databases where only your client can ever know where to look for all the encrypted pieces of your history to assemble into an intelligible log (e.g. blockchain), and for that degree of obfuscation to become the floor of privacy holding sites at arm’s length rather than allowing every bit of interaction to be tied to your single identity as Steve envisions using the technology right now. This I think is critical bedrock to deny blockchain the tyranny of absolute exposure yet does so while preserving trust. This is the foundation of the antidote to social media, as well, IMO, as it is adapted to private, but better managed, broad/ad-hoc communications amongst individuals on our own terms, not a corporation’s. That SQRL is open-source (and free of cost? I wasn’t quite clear on that (clients obviously being a separate question)) must prove among its greatest merits.
On the matter of misrepresentation, I think it is worth the friction of requiring a confirmation with the domain shown, similarly to how Apple intercepts important actions like purchases, reports the true aim of the action regardless of the way the originating app presented that action, and requires user confirmation before proceeding. It seems to me this problem should have already been solved in the rubric of PGP trust networks’ strength of affiliation if tightened to bar omni-directional valence being leveraged for collusion, by exposing the forward-only ties between the presented domain and the one a SQRL client holds for its user to be the intended correspondent: by auditing the presented domain token’s relationship to the domain from which the user initiated the request prompting its offering and the strength thereof, no domain could misrepresent itself with so strong a certificate as it itself held, yet the user could demand that it be at least as strongly tied to the intended domain. In other words, PGP already leverages accountability to establish veracity of identity, and SQRL could proffer the same to users forcing domains to provide credentials for use that are both most strongly tied to the public and official domain as well as being its child, affording a fairly robust degree of safety to users without allowing what I’m sure would become an Achilles Heel to fester in user ignorance/insouciance for SQRL. This is a burden needless to foist upon SQRL users, and PGP models how to avoid that, I think. Please pursue!
1 Like