RFC Possibility SQRL

As SAFE does not need logins to join sites etc. (it can handshake keys etc.) it allows significant ease of use, however it allows aggregation of data between sites (bad sharing). A very nice (and also very doable) addition would be to include SQRL into the mix. This would allow unique ID’s per site, but still automatic to users. See https://www.grc.com/sqrl/sqrl.htm here for a backgrounder.

This would make a great RFC for an upcoming sprint (does not need to be pre launch so no rush). If anyone wants to jump on such a feature it is not that hard as all the pieces are in place for this. Seems like a neat addition to ensuring SAFE stays SAFE from the darker side :wink:

21 Likes

A very favorable side effect of the implementation of SQRL will be the natural promotion of the SafeNet by Gibson.

4 Likes

Gibson are launching a Les Paul Troon? Finished in Arran Sunset Sunburst?

Rock n geeky roll!!!

This is the view from Troon beach BTW. Not only does Troon have brainy folk and superb bakery goods, its also looks onto some stunning scenery.

9 Likes

@dirvine maybe it would be better if we contact Ralf Wondratschek. He made the android implementation.

https://www.grc.com/sqrl/implementations.htm

there’s some more study materials

1 Like

@dirvine A related idea has been floated to allow a device (say $9 CHIP full linux) to do similar for logging into SAFE client. The network challenges the device and it responds just like SQRL. Killing off the keyloggers getting SAFE client login passwords

Not trying to go off topic here just a quick one line response to if you see it as having potential.

2 Likes

I have and RFID card reader on my machine. It would be great to be able to log in with that when one is available, and not have to expose my credentials.

2 Likes

If we have to log to a site like that it’s mostly because there is a donation or pay for something outside chat and or forum. That will not work if we have to transfer safe coin. Our identities will be on it. And they have to know who send the coin to offer the service.

Yes I agree, but you can have multiple identities (some you can throw away) so we could have our own “tumbler” like device where your unique ID could have a safecoin but it came from an unknown ID and you are using an unknown ID. There is no further leakage of anything beyond current and previous ID, so this can be wrapped into the scheme nicely I believe.

2 Likes

I edited in the same time your replied. But, I understand what you mean, but there is no way they know to which account the coin is linked to with SQRL. So how they can provide the service to the user?
EDIT: I get it, we don’t speak the same English.

:smiley: no worries, good thing with sqrl is you can extract the keys from the random ID, if this was tied to an anon identity and applied to a throw away account then you are fine. So throw away the SAFE account but keep the keys for SQRL access. I have not dived into detail yet, it will require some analysis of the sqrl source or papers to confirm this is OK from SQRL side. From SAFE side it is OK, ofc it does not need to be exactly sqrl it could be along the same lines though,.

2 Likes

This is what I believe the idea is.

You log in

You pay the coin from a use once payment address

They credit you as paying, but that address is not used anywhere else, so who cares if they know that address, its not linked to anything else.

(unless I misunderstood you)

2 Likes

No I though the idea is to have an SQRL id linked with our safe account. But I was wrong if I’m correct.

2 Likes

Only for any single payment, apart from that they are separated, this allows use of safecoin by hijacking the private key for a short time. They would be significantly separate though. So you have a SAFE SQRL keypair in your SAFE account for browsing/logging in and can become a SAFE account of that key for short periods, but that is temporary to xfer safecoin for a site (single site) if needed.

I am sure this will radically simplify and become clear as we proceed with the RFC.

3 Likes

There is an SQRL implementation already called Clef.

https://getclef.com/

Clef is not SQRL.
Where did you get that from?

That’s weird, because Wikipedia says there are no SQRL implementations used in production.

I was under the impression it was. Can anyone contact the Clef team to find out?

Wanna fork it? https://github.com/clef

@luckybit, a Clef discussion happened here, perhaps you can continue advocating Clef under that more appropriate topic. It’s 2FA, it doesn’t support anonymity and it strongly recommends (basically requires) that no other passwords (such as SAFE PIN, etc.) be used. This topic isn’t about that.

@luckybit Clef is not totally opensource, costs money, venture backed & is not a SQRL implementation. Clef works with Oauth (maybe still has vunerabilities). You can hear about Clef here from the CEO.

What maybe is more important is making some adjustments to SQRL, so that it could work in harmony with the SAFE Network. What if you could use the SAFE Network message to message your phone? And SQRL worked like this:

In the scenario above you’ll get a text for the Clef app. But what if you got a SQRL message from the SAFE Network message system instead of a master password (masterpassword is SQRL’s weakest point). Maybe instead of a masterpassword that SQRL has, you could also choose to have 2 or 3 phones as a substitute (multisig mobile). Let’s say you lost one phone, you would still be able to login with the other phone and a pin code.

Ideally this SQRL app should be on the SAFE Network, instead of Github or the Google Playstore. If only our mobiles OS was also on the SAFE Network, then it would be…

1 Like