UI Progress

Gang...

I am methodically working through the SQRL user-interface, 
trying to produce 100% finished work at each stage. Although
I know I will fail at that, it's the only way I'm able to work.

For example, I forgot to include the site-provided "friendly 
name" in the two "finished" password prompt dialogs I had 
designed... so I'll get them added next.

>---------------------------------------------------------------

When the user first runs a SQRL app on a machine, mobile or not, 
it will immediately notice that it cannot find any associated 
identities. This will either mean that the user is running SQRL 
for the first time anywhere, or that they're running it for the 
first time on THIS new device.

Either way, there are no SQRL identities present, so SQRL needs 
to know how to proceed.

Therefore, they are presented with a dialog that briefly 
explains this, with buttons for "Create Identity" or "Import 
Identity"

But in case this IS the first time they are using SQRL, there's 
also a more prominent "Learn More About SQRL" button, which I 
expect many/most people will choose.

In that case, a "How SQRL Works" / "What you need to know" 
dialog is presented to give the pure neophyte some idea what 
SQRL is all about.

I've spent portions of the past week working on the careful 
design of the text in that dialog... and you'll see some new 
ideas presented there. When you're examining it, remember WHO 
the target audience for this is... this app is being aimed for 
the use of EVERYONE who uses the Internet.

(And just so we're clear, it is my hope that all other SQRL 
clients, on whatever platform, will adopt the same UI flow and 
use the same text if they choose.  Copy & Paste is your friend.)

>---------------------------------------------------------------

As I have mentioned before, I'm using Visual Basic as my UI 
prototyping platform, mostly because it allows me to quickly 
assemble production-grade interfaces, and also generate metrics 
files that I will eventually be able to turn directly into 
Windows resource files to invoke the same UI from my assembly 
code.

My plan is to lay out the ENTIRE user-interface graphically on a 
web page so that the presentation is complete and 100% platform 
agnostic.  And I intend to begin assembling and publishing that 
shortly.  But until then, if anyone is curious to see that first 
"How SQRL Works" dialog, it's posted in the /dev/SQRL directory:

https://www.grc.com/dev/sqrl/FirstHelp.exe

This is a Windows EXE that (apparently) depends only upon a 
single redistributable .Net v4 DLL (which may already exist in 
newer systems).  But if you receive a complaint about it being 
missing, it's in the directory too:

https://www.grc.com/dev/sqrl/mscoree.dll

>---------------------------------------------------------------

You'll also note the appearance of a SQRL "Mascot" icon/image 
for the first time.  I have purchased an unrestricted commercial 
usage license for it, and I have it in postscript, Corel, large 
scaleable bitmap, etc, formats. They will all be made available 
for developers of other clients and SQRL-related websites.

I'm not married to the image, but it's the best thing I've found 
so far.  I have it in various treatments: brown, all grey, lines 
only, etc.  They'll show up in various places throughout this UI 
work and we'll see whether this particular little "Squirrel" 
sticks.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/14/2014 6:42:12 PM
grc.sqrl 459 articles. 0 followers. Follow

80 Replies
892 Views

Similar Articles

[PageSpeed] 17

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--9IFkFkwkwAFWsRihVwtotw6hfOEBspo5I
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I've looked at it using Wine and there are a bunch of glitches. Not sure
whether you will be using the same framework in the end, but I would
very much describe it as unusable :(. Maybe some other Wine guys can
confirm and/or disprove this?

Nevertheless I read through the texts and have a couple of thoughts:

Am 14.02.2014 19:42, schrieb Steve Gibson:
> Therefore, they are presented with a dialog that briefly=20
> explains this, with buttons for "Create Identity" or "Import=20
> Identity"

I'm not sure about this premise and whether we should hassle the user
with too much information. In my mind the UI should be simple enough
(wizard style), so that the user doesn't need to know that much about
SQRL at all. The user is only instructed to wave around his device and
to enter a passphrase used for authentication. In the last step the
export would be performed / suggested / enforced. From then on SQRL
should be usable by clicking/scanning/tapping - depending upon the device=
=2E

Realistically most users are not going to read and/or understand
extensive descriptions anyway, and I'm worried that too much text will
be counterproductive. Just think about the way all of us are dealing
with EULAs ;).

You keep referring to the identity as "It's just a 77-digit random
number". I probably would omit this entirely and refer to it as unique
bit pattern or something similar.

I have another problem with this statement:

> Since you never need to use an eMail address or a password, you never
> give a website your actual identity to protect. If the website's SQRL
> identities are ever stolen, not only would the stolen identities only
> be valid for that one website, but SQRL's cryptography prevents
> impersonation using stolen identities.

I very much doubt that this will hold true in practice, because most
services will probably associate your identity with some name and/or
email address. I don't think that the average Joe understands the
implications of all of this, so I wouldn't claim something of that sort.

To be honest, I'm not sure I actually like all of your descriptions that
much. I would prefer them to be shorter and more expressive. We will run
into trouble when we try to get all of this content onto our mobile
devices in a nice way.

Actually there are only a couple of messages we *need* to get across:

- Try to remember your passphrase
- Backup your identity and store it in a safe location
- (There is a rescue code, which hopefully will never be needed)

Everything else is nice-to-know, but shouldn't be needed in order to use
SQRL.

Best regards,
Karol Babioch


--9IFkFkwkwAFWsRihVwtotw6hfOEBspo5I
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJS/ng3AAoJEHSaZc1HnzIV2KEP/3uyXmUqaztJXB2lj2YuVIfD
UnIWkyL4yvJtWQNP18cCKbgolkHpOS4DiZ6WZ4QRzTjqQkX4mAARehUOij9DK5MC
R10No7SbOlJ58/r7blaCH5vdphmUCoGPZ/h4jIBRI2GeoY4P53/dpoo5Z4IGqDZs
9hyUbh74TE7O/uxq6doHAYT/E7f5xmXxqE/aoyEcVbHA5lH3pV8NWSrpHzvgtDfY
o9XqrHx0wi1toxpHYP4FZgWHbBX6Sn1YumDolG3n12LFrIee+hPB97NSXs1UjMd1
TI4oQNzhbR0LDWnqTyyV6m9wdvbSkIN2/6uVQXJkQYZPlK5bY3p0tmpkoL51Ixak
sOzbcrgTED0THapok72faXXrjahkgLm3PKYgOHUJDBUzMljvkcsve0FcADS4WmdB
dBSIxQ44k19ur0S57ZinI1AJZ8x/xFAtQV7GBWlBmTJn9hp0k4a4vymc3ULrmXiR
zrzwE9Kn4JqqRftGUaLKxYCkgsE8ooKr27f1NMnODAu4IdFlmlMsO7SqKUDBnXoC
Y6yKcT4pDlcqJ7yKG5V1oGkPxHQ2c8VNCXE5dC602zfBXesC3/U6tpEZZRljj1Mw
y3KXyNv555Lh0UTVqlsuGbxGHLrZjij1Ohy3AoX7urayIg/SPr8Iy8ZM/HueAnK0
gUJkCrgI4/G5AM08V0Zx
=jS9B
-----END PGP SIGNATURE-----

--9IFkFkwkwAFWsRihVwtotw6hfOEBspo5I--
0
Karol
2/14/2014 8:10:27 PM
[for the unabridged version, see Karol Babioch's post above]

> Hi,
> 
> I've looked at it using Wine and there are a bunch of glitches.
> Not sure whether you will be using the same framework in the end,
> but I would very much describe it as unusable :(. Maybe some other
> Wine guys can confirm and/or disprove this?

I'm not surprised Karol.  And, no... NOTHING of this other than 
the on-screen visual interface will survive. So far, at least, I 
don't code in any "frameworks"... I just call the raw Win32 API 
directly from my own assembly code.

(And example of this, in case you haven't seen it already, is 
the DNS Benchmark which is both quite UI graphics heavy and also 
quite happy to run under WINE.)

GRC's SQRL client will *definitely* be 100% WINE-compatible... 
and I'll be looking to people here, such as yourself and 
presumably Mark Cross and others to help me identify any spots I 
need to fix.  Though... as I recall... WINE has matured to such 
a degree that so long as the WINE libraries were current, things 
went surprisingly well.


> Nevertheless I read through the texts and have a couple of thoughts:

> > Therefore, they are presented with a dialog that briefly
> > explains this, with buttons for "Create Identity" or "Import
> > Identity"
> 
> I'm not sure about this premise and whether we should hassle
> the user with too much information. In my mind the UI should
> be simple enough (wizard style), so that the user doesn't need
> to know that much about SQRL at all.

I agree completely, though neither do I want to leave the 
wanting-to-know-more user puzzled about what's going on.

My UI style offers information but doesn't require that the user 
follows it.  Rather, I salt the information throughout the UI so 
that it's contextually relevant.

For example, THIS is the dialog that the new user first sees:

https://www.grc.com/sqrl/ui/Welcome.png

We STRONGLY NEED to discourage anyone who doesn't understand how 
SQRL works from creating a new identity on every device. So this 
dialog page explains the WHAT more than the WHY, then gives them 
the choice.

The four-tab dialog whose EXE I posted is only revealed if they 
click the entirely optional "Learn more about SQRL" button.

UI design is tricky, and it's a definite balancing act.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/14/2014 9:35:35 PM
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--4SGr3kIGDcw2QgtUnss0bCHjGWmNNe5jW
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Am 14.02.2014 22:35, schrieb Steve Gibson:
> GRC's SQRL client will *definitely* be 100% WINE-compatible...=20
> and I'll be looking to people here, such as yourself and=20
> presumably Mark Cross and others to help me identify any spots I=20
> need to fix.

Yeah, we'll figure this one out. I'm not concerned too much about it
though, because I still think a native client would be better. But that
is something to be discussed in the future.

> For example, THIS is the dialog that the new user first sees:
>
> https://www.grc.com/sqrl/ui/Welcome.png

I think colors would be of great help here. Make your warnings yellowish
or red instead of uppercasing them. Personally I would like to have
radio buttons for the choice between "create" and "import", though this
is probably just a matter of taste.

> We STRONGLY NEED to discourage anyone who doesn't understand how
> SQRL works from creating a new identity on every device. So this
> dialog page explains the WHAT more than the WHY, then gives them
> the choice.

> The four-tab dialog whose EXE I posted is only revealed if they
> click the entirely optional "Learn more about SQRL" button.

Ok, that's perfectly fine then. Although I wouldn't worry too much about
this either, because you could easily link to your pages (once they are
up to date ;)) as anyone who has installed the client is expected to
have an Internet connection anyway.

Am 14.02.2014 22:35, schrieb Steve Gibson:
> UI design is tricky, and it's a definite balancing act.

Definitely. Unfortunately we as programmers tend to be really bad UI
designers, as we tend to make wrong assumptions based upon our own
experience. I don't know whether there are any professional UI designers
in this newsgroup, but there are a couple of great books about this topic=
=2E

However, I don't think that we should worry too much about it for now.
We can reiterate on the design once we have a working prototype, which
would give us some more insights on the typical use cases.

Best regards,
Karol Babioch


--4SGr3kIGDcw2QgtUnss0bCHjGWmNNe5jW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJS/qJZAAoJEHSaZc1HnzIV9+0QAK7QIqPnJP2AonZ6mgqPQ15G
kT/aPBGOjER7QXSRXvRbjx4bn+04x8JhRDP7Ad/tO4IPsmUKE8G9zIMGyooIuGZI
4W17OIZ6wWol+gFJPu2A6c1D0ddGyUnsLo3UVKZCRz/WeKXZiUXI30LmyPWe+u3r
Df4ug7FTGi7urxphHvyUx1q49A2i/VHifFNlmYv1gay3wZ8ZO/TotUqlHf/qXF0J
eoPQQ2Eml/p45D6+9/sXMiIG/CgHqhgzTDWQ0xM2HPhYdrvlpRMNXK0JNgI9VOwj
ZvPrZkfe/AoNRpReVJ8U/hWNyMBZzPu5wumq7LLC5UNj8YbtovNf8XSQoARlK7q/
RifzqwJ+kT+zERiYtOxHrmugylVOnwGY9vcFe9kra46PutswufSD39RxnNSBaFog
dKPMuE/Qo+WpO6tWa1yohJCCcQQPJwh22hcKlPz7tsbiTbMgJ6SfY7RejYqqPiYq
PmaRLb0XUVl7svSmHYxM91zpgk5pF5TeldGg9Fk+kT6g4VJC2I/Tz2zlRyQf11Va
dAi9VNpe2KkcERtQpq/iiph8YhHGK4tKaWm1zalQPEQkG8AOtml/NZOXd36S3sU/
stUQvO1QUwLYuD1xXdLpvEkmnejqKQngMzHyKphs1GTsbc9Jyl6Nv0Nxdm3V7Njm
2jGVSvQJ61cf0hHVNxCN
=3G1Z
-----END PGP SIGNATURE-----

--4SGr3kIGDcw2QgtUnss0bCHjGWmNNe5jW--
0
Karol
2/14/2014 11:10:12 PM
[for the unabridged version, see Karol Babioch's post above]

+1!

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/14/2014 11:23:15 PM
[for the unabridged version, see Steve Gibson's post above]

I have the initial SQRL UI page posted:

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

I'll be updating that page as I get additional pieces designed 
and laid out.

Next up is the amended password dialogs, then the identity 
creation wizard...

More soon.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/15/2014 12:58:26 AM
On Fri, 14 Feb 2014 16:58:26 -0800, Steve Gibson wrote:

> [for the unabridged version, see Steve Gibson's post above]
> 
> I have the initial SQRL UI page posted:
> 
> https://www.grc.com/sqrl/operation.htm
> 
> I'll be updating that page as I get additional pieces designed and laid
> out.
> 
> Next up is the amended password dialogs, then the identity creation
> wizard...
> 
> More soon.

First a typo in the reference text tab:- SQRK's Rescue Code

In the Welcome explanation you say:_
# We want to be sure that newcomers do not create new SQRL identities for 
# every instance of SQRL they use.
# 
# SQRL's “Personal Identities” are meant to be global, created once and 
# reused everywhere.
By all means discourage but never prevent having multiple identities. I 
for one need to have them. I have multiple desk top machines, each with 
several VMs available. Each VM is dedicated to a different task such as 
banking or general web browsing. I have tried to make it obvious which VM 
is which by having unique desktop wallpapers etc but at present there is 
very little to prevent me inadvertently doing a task, say banking, from 
the wrong machine. With SQRL I could have an ID that is only used for  
banking on just the banking machine and nowhere else. I would then be 
forced to use the correct machine. No other machine in the world, 
compromised or otherwise, could be used to do my banking. 
The reverse situation occurs where a household has a single machine and 
everybody uses the same family log-in. You now need to be able to select 
the correct ID to use for each user. What happens if the first person 
uses their ID to download a film and whilst that is progressing the 
second person wants to get their E-mails or chat? Concurrent IDs? 

-- 
dave_k
0
dave_k
2/15/2014 12:25:34 PM
[for the unabridged version, see dave_k's post above]

> First a typo in the reference text tab:- SQRK's Rescue Code
> 
> In the Welcome explanation you say:_
> # We want to be sure that newcomers do not create new SQRL
> # identities for every instance of SQRL they use.
> # 
> # SQRL's “Personal Identities” are meant to be global,
> # created once and reused everywhere.

I'm not spotting the typo in what you quoted above, dave?


> By all means discourage but never prevent having multiple
> identities.

Oh, of course not!  I completely agree.  And when I use the word 
"discourage" I mean only that we simply want to be sure that the 
user understands the way SQRL works, and that unless they need 
to be seen as ANOTHER identity somewhere, a single SQRL identity 
probably already does what they intend.


> I for one need to have them. I have multiple desk top machines,
> each with several VMs available. Each VM is dedicated to a
> different task such as banking or general web browsing. I have
> tried to make it obvious which VM is which by having unique
> desktop wallpapers etc but at present there is very little to
> prevent me inadvertently doing a task, say banking, from the
> wrong machine. With SQRL I could have an ID that is only used
> for banking on just the banking machine and nowhere else. I
> would then be forced to use the correct machine. No other
> machine in the world, compromised or otherwise, could be used
> to do my banking.

Yes.  That's an interesting and valid use for multiple carefully 
managed SQRL identities.  :)


> The reverse situation occurs where a household has a single
> machine and everybody uses the same family log-in. You now
> need to be able to select the correct ID to use for each user.
> What happens if the first person uses their ID to download a
> film and whilst that is progressing the second person wants
> to get their E-mails or chat? Concurrent IDs?

That'll work well too.

The title bar of the Password prompt dialog shows WHO is being 
logged in. And if the person doesn't notice that the currently 
selected person is not them, their own password will be 
incorrect.  They would then select the proper identity, provide 
the correct password, and login as themselves.

Since logging in is "transactional", someone else could be 
previously logged into a different app or web page as themselves 
without there being any conflict.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/15/2014 3:40:00 PM
On 02/15/2014 10:40 AM, Steve Gibson wrote:
> [for the unabridged version, see dave_k's post above]
>
>> First a typo in the reference text tab:- SQRK's Rescue Code

>
> I'm not spotting the typo in what you quoted above, dave?
>

Typo is in this tab:

SQRK's Rescue Code
0
Paul
2/15/2014 4:10:37 PM
[for the unabridged version, see Paul Babiak's post above]

> SQRK's Rescue Code

Ah!  Thanks!!!  Such a perfect example of not being able to see 
one's own mistakes!  :)

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/15/2014 5:48:23 PM
Steve Gibson wrote:
> [for the unabridged version, see Steve Gibson's post above]
>
> I have the initial SQRL UI page posted:
>

I have not had time to read and digest every message in this NG, but I do 
not understand what this sentence is referring to.

In the "Your SQRL password" section, the sentence "And to make longer, more 
complex passwords less painful to use, the password's first four characters 
may be used to "refresh" the full password you originally entered." worries 
me, and, I think, would worry any potential SQRL user.

It gives me the impression that I only have to key in a long password once, 
and thereafter, forever, I can just type the first 4 characters. So my SQRL 
ID is only protected by a 4 character password, that doesn't sound very secure.

Perhaps it needs rephrasing or explaining in more detail.

AlanD

0
AlanD
2/15/2014 6:34:21 PM
[for the unabridged version, see AlanD's post above]

Alan,

> I have not had time to read and digest every message in this
> NG,

(Who has?? :)

> ...but I do not understand what this sentence is referring to.
> 
> In the "Your SQRL password" section, the sentence "And to make
> longer, more complex passwords less painful to use, the password's
> first four characters may be used to "refresh" the full password
> you originally entered." worries me, and, I think, would worry
> any potential SQRL user.
> 
> It gives me the impression that I only have to key in a long
> password once, and thereafter, forever, I can just type the
> first 4 characters. So my SQRL ID is only protected by a 4
> character password, that doesn't sound very secure.
> 
> Perhaps it needs rephrasing or explaining in more detail.

Ah, I see what you mean.  I just changed "originally entered"
to "recently entered".

That "quick help" area wasn't the place to go into extra detail, 
but the detail IS now posted on the page along with the 
"Password" and "Password Hint" dialogs.

The idea behind the "hint" is that someone using SQRL repeatedly 
is going to quickly become VERY ANNOYED if they are being asked 
to re-enter their full password for every single thing they do. 

If SQRL were to provide them with no relief from that the user's 
reaction would be to change their really good and strong 
password into something short and simple that they could easily 
enter upon demand.

So, instead of encouraging people to use short and insecure 
passwords, SQRL encourages the reverse -- the use of long and 
strong passwords -- by ONLY requiring the re-entry of the first 
four characters of an ALREADY IN RAM PASSWORD. **AND**, if *any* 
mistake is made, RAM will be scrammed and they will be prompted 
for the full password.

In that fashion, the user beginning a "session" -- unlocking 
their phone, logging into their desktop, unblanking the screen, 
etc. would need to FULLY authenticate only the first time they 
used SQRL at the beginning of that session.  From then on they 
just need to "refresh" their authentication using the first four 
characters of their password.

>---------------------------------------------------------------

In terms of implementation, we do NOT want to actually retain 
ANY of the user's actual password in RAM.  So when they enter 
their FULL password, we hash not only the entire password, but 
also the first four characters alone.

We then use the result of the full EnScrypt process to decrypt 
into RAM their permanently stored encrypted master key.  And 
we're good to go.

At the same time we re-encrypt their decrypted master key under 
the key generated from the first n-characters (by default 4) of 
their full password. We keep in RAM the hint-encrypted key and 
its OCB auth-tag.

Once we've used the decrypted key for its purpose, we scram it 
from RAM under the general policy of NEVER leaving anything 
unencrypted in RAM that we don't need to.

So now... the NEXT TIME we need to re-authenticate during this 
same session -- and assuming that the current session is still 
valid and that nothing has happened to cause us to scram the 
keys from RAM (like the screen saver engaging or them locking 
their mobile device) -- we see that we still have the hint-
encrypted key in RAM.  So we prompt for the user's short 
password hint, hash it and decrypt the RAM-stored hint-encrypted 
key, and verify the OCB-tag.  If it verifies... we use the hint-
decrypted key.  Otherwise we overwrite and erase all RAM 
resident keys and prompt the user for their full password.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/15/2014 8:38:47 PM
Steve Gibson wrote:
> [for the unabridged version, see AlanD's post above]
>

> Ah, I see what you mean.  I just changed "originally entered"
> to "recently entered".
>
That makes more sense.

>
> The idea behind the "hint" is that someone using SQRL repeatedly
> is going to quickly become VERY ANNOYED if they are being asked
> to re-enter their full password for every single thing they do.
>
> If SQRL were to provide them with no relief from that the user's
> reaction would be to change their really good and strong
> password into something short and simple that they could easily
> enter upon demand.
>
I agree

A lot of people may be interested in SQRL, but anything that gives a false 
impression at first sight will quickly become a turn-off. All 
"publicity"/initial screens/writeups need to be checked very carefully for 
ambiguity. It may even be worth getting non-native English speakers to 
review the text and syntax.

AlanD
0
AlanD
2/15/2014 10:31:41 PM
In grc.sqrl, Steve Gibson wrote ...

> [for the unabridged version, see Paul Babiak's post above]
> 
> > SQRK's Rescue Code
> 
> Ah!  Thanks!!!  Such a perfect example of not being able to see 
> one's own mistakes!  :)

It's also an example of random alphabetic strings being harder 
for the brain to process.  The brain tries to associate unknown 
words or symbols with the closest known word or symbol.  Like 
you, I didn't see it until it was pointed out.  My brain told me 
I saw SQRL, not SQRK.  :)

-- 
Terry //
0
Terry
2/16/2014 2:37:07 AM
On 14-02-15 03:38 PM, Steve Gibson wrote:
> [for the unabridged version, see AlanD's post above]

> So now... the NEXT TIME we need to re-authenticate during this
> same session -- and assuming that the current session is still
> valid and that nothing has happened to cause us to scram the
> keys from RAM (like the screen saver engaging or them locking
> their mobile device) -- we see that we still have the hint-
> encrypted key in RAM.  So we prompt for the user's short
> password hint, hash it and decrypt the RAM-stored hint-encrypted
> key, and verify the OCB-tag.  If it verifies... we use the hint-
> decrypted key.  Otherwise we overwrite and erase all RAM
> resident keys and prompt the user for their full password.
>
For a mobile device:-
This is an interesting idea, as a way of creating an intermediate step 
between no-authentication re-launch of a background thread and full 
authentication via a re-build of a closed thread (or a background one 
that retains no state).

If it is used to replace the assumed re-launch without further 
authentication then this is a good thing, provided all care is taken to 
ensure that this new feature does not result in a weakened security model.

To that end, the use of salt, our memory hard algorithm and any other 
aspects of the full password hashing should also be enforced for the 
shorter one, lest we leave a tempting target for a maleficent lusting 
for a ram image to be tested against a pre-computed hash.


0
ramriot
2/16/2014 3:13:51 AM
On Sat, 15 Feb 2014 12:38:47 -0800, Steve Gibson wrote:

> [for the unabridged version, see AlanD's post above]
> 
> Alan,
> 
>> I have not had time to read and digest every message in this NG,
> 
> (Who has?? :)
> 
>> ...but I do not understand what this sentence is referring to.
>> 
>> In the "Your SQRL password" section, the sentence "And to make longer,
>> more complex passwords less painful to use, the password's first four
>> characters may be used to "refresh" the full password you originally
>> entered." worries me, and, I think, would worry any potential SQRL
>> user.
>> 
>> It gives me the impression that I only have to key in a long password
>> once, and thereafter, forever, I can just type the first 4 characters.
>> So my SQRL ID is only protected by a 4 character password, that doesn't
>> sound very secure.
>> 
>> Perhaps it needs rephrasing or explaining in more detail.
> 
> Ah, I see what you mean.  I just changed "originally entered" to
> "recently entered".
> 
> That "quick help" area wasn't the place to go into extra detail,
> but the detail IS now posted on the page along with the "Password" and
> "Password Hint" dialogs.
> 
> The idea behind the "hint" is that someone using SQRL repeatedly is
> going to quickly become VERY ANNOYED if they are being asked to re-enter
> their full password for every single thing they do.
> 
> If SQRL were to provide them with no relief from that the user's
> reaction would be to change their really good and strong password into
> something short and simple that they could easily enter upon demand.
> <SNIP>
> So, instead of encouraging people to use short and insecure passwords,
> SQRL encourages the reverse -- the use of long and strong passwords --
> by ONLY requiring the re-entry of the first four characters of an
> ALREADY IN RAM PASSWORD. **AND**, if *any*
> mistake is made, RAM will be scrammed and they will be prompted for the
> full password.
Great idea. My personal choice would be to use >4 characters but I think 
4 is just about right for the non-tech users. For the ultra cautious we  
could have a hint disable feature, say setting the number of characters 
required to zero? But may be that is an unnecessary bloat for the very 
small number of users that would actually use it. 
> 
> In that fashion, the user beginning a "session" -- unlocking their
> phone, logging into their desktop, unblanking the screen, etc. would
> need to FULLY authenticate only the first time they used SQRL at the
> beginning of that session.  From then on they just need to "refresh"
> their authentication using the first four characters of their password.
> 
Your reply to my post further up thread cleared up the confusion I was 
having but now it has crept back in, possible because I was not clear in 
my questions but probably because my brain is only firing on one cylinder.
By session I mean an instance of a SQRL log-in attempt, whereas you 
appear to mean a much broader action like coming out of the screen saver.
With a slow file transfer or when working on multiple VMs I often find 
that the screen saver will kick in so it will be a real pain to have to 
use my long password all the time.

The majority of households that I know of have just one PC with a single 
user name and password that is used by everyone in the household 
[abc/123]. Therefore the logged-in user name has no relation to the ID of 
the person using SQRL.

Alice signs on to movies.invalid, orders some films and whilst they are 
downloading goes off to wash the car.
Along comes Bob, opens another tab in the browser and logs into his cloud 
store to sync his picture library.
Clare is expecting an urgent email so jumps in and opens another browser 
tab to check if it has arrived.

How does SQRL know which ID to try for each of these new session, does it 
list all the IDs for selection or try the offered password in each until 
it gets a match? On a college PC there could be thousands of SQRL IDs. 
How long will that take?

Will SQRL be able to keep track of the fact that switching between 
browser tabs will also be switching between SQRL IDs?

Alice, Bob and Clare's passwords all start with 'monkey' so how will SQRL 
cope if all three are active at the same time?

Uncle Fred comes to stay for a few weeks and clones his SQRL ID on to the 
PC, Unfortunately his password is identical to Alice's. [monkey123]
Is this a problem for SQRL?

In terms of security the above stinks but I see it all too often in the 
real world. It's how people use computers now and they will expect to use 
SQRL in the same way, or else they will just carry on using monkey123 on 
every site.
>
>>---------------------------------------------------------------
> 
> In terms of implementation, we do NOT want to actually retain ANY of the
> user's actual password in RAM.  So when they enter their FULL password,
> we hash not only the entire password, but also the first four characters
> alone.
> 
> 
> We then use the result of the full EnScrypt process to decrypt into RAM
> their permanently stored encrypted master key.  And we're good to go.

> At the same time we re-encrypt their decrypted master key under the key
> generated from the first n-characters (by default 4) of their full
> password. We keep in RAM the hint-encrypted key and its OCB auth-tag.

> Once we've used the decrypted key for its purpose, we scram it from RAM
> under the general policy of NEVER leaving anything unencrypted in RAM
> that we don't need to.

> So now... the NEXT TIME we need to re-authenticate during this same
> session -- and assuming that the current session is still valid and that
> nothing has happened to cause us to scram the keys from RAM (like the
> screen saver engaging or them locking their mobile device) -- we see   
> that we still have the hint- encrypted key in RAM.  So we prompt for   
> the user's short password hint, hash it and decrypt the RAM-stored hint-
> encrypted key, and verify the OCB-tag.  If it verifies... we use the   
> hint-decrypted key.  Otherwise we overwrite and erase all RAM resident 
> keys and prompt the user for their full password.

-- 
dave_k
0
dave_k
2/16/2014 6:22:42 PM
[for the unabridged version, see ramriot's post above]

> > So now... the NEXT TIME we need to re-authenticate during this
> > same session -- and assuming that the current session is still
> > valid and that nothing has happened to cause us to scram the
> > keys from RAM (like the screen saver engaging or them locking
> > their mobile device) -- we see that we still have the hint-
> > encrypted key in RAM.  So we prompt for the user's short
> > password hint, hash it and decrypt the RAM-stored hint-encrypted
> > key, and verify the OCB-tag.  If it verifies... we use the hint-
> > decrypted key.  Otherwise we overwrite and erase all RAM
> > resident keys and prompt the user for their full password.

> For a mobile device:-
> This is an interesting idea, as a way of creating an intermediate
> step between no-authentication re-launch of a background thread
> and full authentication via a re-build of a closed thread (or a
> background one that retains no state).

> If it is used to replace the assumed re-launch without further 
> authentication then this is a good thing, provided all care is
> taken to ensure that this new feature does not result in a
> weakened security model.

> To that end, the use of salt, our memory hard algorithm and
> any other aspects of the full password hashing should also be
> enforced for the shorter one, lest we leave a tempting target
> for a maleficent lusting for a ram image to be tested against
> a pre-computed hash.

You're 100% right that we need to do all we can do, but if we 
want this feature -- and as we'll see as I get more of the UI 
published it's both tunable and optional, AND the user can also 
explicitly ask for their in-RAM password to be erased at any 
time -- we must also accept that a RAM snapshot captured at that 
moment will offer weakened security.  There's just no getting 
around that.

We will have deliberately created a scenario where, from what's 
in RAM, a MUCH SHORTER sequence of unknown characters can 
decrypt an in-RAM key to obtain the user's operating identity 
master key.

However... we must again maintain perspective about the nature 
of the threat. For example... if there's malware present with 
the capability to capture RAM, AND this "Password Hint" facility 
was not present, that malware could simply capture the RAM after 
the FULL password had been entered.  Or capture the entry of the 
password itself keystroke-wise.

My point is that we have already established that we're unable 
to offer any affirmative protection against the threat of smart 
executing process RAM-scrapping capable malware. Our response 
was the design of the Identity Lock Protocol which does succeed 
in limiting the damage that the user's loss of control over 
their client might cause.

Given that the hint-length can be set, and that the user's 
password can be wiped on demand, I think the password hinting 
solution creates the right usage incentives and helps to make 
SQRL even easier to use.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/16/2014 7:08:26 PM
Steve Gibson was heard to say :

> GRC's SQRL client will *definitely* be 100% WINE-compatible...

I've been thinking about this and I *WAS* on the idea that whether it does 
work in wine or not is pretty much irrelevant. That you will be expending 
some amount of time/effort that would be better put to use somewhere else.
Also, if the idea is to catch up, even modestly, there will be a linux 
native solution very quickly. All the information IS public. I was going to 
say that the day you posted this, but something told me that, somehow, I was 
missing a piece of the puzzle. And that is that: this is a reference 
implementation, something that everyone will be looking at to measure if 
they have reached interoperability, that without wine compatibility, most 
Mac users will be left out.

So, yes, I was wrong, we do need this to be working.

So, I'll participate.


> and I'll be looking to people here, such as yourself and
> presumably Mark Cross and others to help me identify any spots I
> need to fix.

Sure, (now) count me in.

> Though... as I recall... WINE has matured to such
> a degree that so long as the WINE libraries were current, things
> went surprisingly well.

Let me put that to the test, I'll post something as soon as I have tested 
some wine versions (old and new) on the app.

-- 
Mark Cross @ 02/16/2014 3:03 p.m.
Worry is like a rocking chair; it keeps you busy, but gets you nowhere.
0
Mark
2/16/2014 7:26:51 PM
Steve Gibson was heard to say :

> [for the unabridged version, see Steve Gibson's post above]
> 
> I have the initial SQRL UI page posted:
> 
> https://www.grc.com/sqrl/operation.htm
> 
> I'll be updating that page as I get additional pieces designed
> and laid out.
> 
> Next up is the amended password dialogs, then the identity
> creation wizard...
> 
> More soon.

Nit-picking:    :-)

Where it say "77-digit number".  Sorry, but 256 is 78 chars.

In 77 decimal digits could there be only 255,78 bits of entropy. And as all 
the results have to be rounded to an integer, that amounts to 255 bits

Yes, of course, the capacity of 78 decimal digits is 259,11 bits of entropy, 
which is clearly space enough to contain the 256 bits of the keys.

But I believe that just saying:
       "more than 75 decimal digits"
    or "almost 80 decimal digits"
    or "a bit less than 78 digits"
    or "a tiny bit more than 77 digits"
could be reasonable descriptions.


However I would recommend saying: "in the order of 78 decimal digits"


As said: just nit-picking :-)

-- 
Mark Cross @ 02/16/2014 3:27 p.m.
There are no traffic jams on the extra mile. — Zig Ziglar

0
Mark
2/16/2014 7:39:19 PM
[for the unabridged version, see dave_k's post above]

> > So, instead of encouraging people to use short and insecure
> > passwords, SQRL encourages the reverse -- the use of long and
> > strong passwords -- by ONLY requiring the re-entry of the first
> > four characters of an ALREADY IN RAM PASSWORD. **AND**, if *any*
> > mistake is made, RAM will be scrammed and they will be prompted
> > for the full password.

> Great idea. My personal choice would be to use >4 characters but
> I think 4 is just about right for the non-tech users. For the ultra
> cautious we could have a hint disable feature, say setting the
> number of characters required to zero? But may be that is an
> unnecessary bloat for the very small number of users that would
> actually use it. 

The UI I have designed does make it variable and optional, as 
well as allowing the user to manually wipe their credentials 
from RAM on demand.


> Your reply to my post further up thread cleared up the confusion I was 
> having but now it has crept back in, possible because I was not clear in 
> my questions but probably because my brain is only firing on one cylinder.
> By session I mean an instance of a SQRL log-in attempt, whereas you 
> appear to mean a much broader action like coming out of the screen saver.
> With a slow file transfer or when working on multiple VMs I often find 
> that the screen saver will kick in so it will be a real pain to have to 
> use my long password all the time.

That's also configurable. I'm setting defaults for best security 
but also not preventing smart users from setting SQRL up the way 
they desire.


> The majority of households that I know of have just one PC with
> a single user name and password that is used by everyone in the
> household [abc/123]. Therefore the logged-in user name has no
> relation to the ID of the person using SQRL.

Right.


> Alice signs on to movies.invalid, orders some films and whilst
> they are downloading goes off to wash the car.

> Along comes Bob, opens another tab in the browser and logs
> into his cloud store to sync his picture library.

> Clare is expecting an urgent email so jumps in and opens
> another browser tab to check if it has arrived.

Okay.


> How does SQRL know which ID to try for each of these new session,
> does it list all the IDs for selection or try the offered password
> in each until it gets a match? On a college PC there could be
> thousands of SQRL IDs.  How long will that take?

The SQRL password dialog shows whose identity is "current" in 
SQRL.  I was planning to have it changeable from the app's 
context menu in the tray... but I think I'll add an optionally-
appearing text-link in the password dialog.


> Will SQRL be able to keep track of the fact that switching
> between browser tabs will also be switching between SQRL IDs?

No.  This is not SQRL's responsibility.  SQRL will attempt to 
authenticate with whatever is the currently selected identity at 
the time of login.


> Alice, Bob and Clare's passwords all start with 'monkey' so how
> will SQRL cope if all three are active at the same time?

That won't matter.  SQRL doesn't "find" the identity by matching 
with the proper password.  The user selects the identity they 
wish to authenticate with.  If the user fails to notice that 
someone else's identity is current then their password will fail 
for that wrong identity.


> Uncle Fred comes to stay for a few weeks and clones his SQRL ID
> on to the PC, Unfortunately his password is identical to Alice's.
> [monkey123] Is this a problem for SQRL?

It's fine UNLESS Fred and Alice fail to notice when the other's 
identity is currently selected and they authenticate with a 
password that works with the other's identity.

This trouble could me mitigated simply by having visiting Uncle 
Fred change his password on that one machine during his visit.


> In terms of security the above stinks but I see it all too often
> in the real world. It's how people use computers now and they
> will expect to use SQRL in the same way, or else they will just
> carry on using monkey123 on every site.

The only thing I can see doing differently might be to have an 
option in SQRL -- when more than one identity is installed -- to 
EXPLICITLY PROMPT for the identity the current user wishes to 
use.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/16/2014 7:43:57 PM
Steve Gibson was heard to say :

> https://www.grc.com/sqrl/operation.htm

About:    Why Backup?

You explain (correctly) the reason and need to store and/or print the "SQRL 
private identity" which is (I believe) the older called IdUK. And as it is 
encrypted, it is then "the encrypted IdUK". That is fine and correct.

However you miss to explain how to backup the "Rescue Code".

You miss the chance to explain that if, for any reason, the "Encrypted IdUK" 
and the "Rescue Code" are stored together, no matter how big is the "rescue 
Code" it will provide zero (0) bits of protection.

You must explain then: that the printed QR of the IdUK should be stored in 
the safe with your other papers. and the "Rescue Code" should be kept in the 
wallet.

-- 
Mark Cross @ 02/16/2014 3:44 p.m.
History has shown there are no invincible armies. — Joseph Stalin

0
Mark
2/16/2014 7:58:59 PM
[for the unabridged version, see Mark Cross's post above]

> > Though... as I recall... WINE has matured to such
> > a degree that so long as the WINE libraries were current,
> > things went surprisingly well.
> 
> Let me put that to the test, I'll post something as soon as
> I have tested some wine versions (old and new) on the app.

Mark,

If by "the app" you mean the DNS Benchmark, then, yes, by all 
means.  But if by "the app" you meant that FirstHelp.exe I 
posted... while I would be curious to see whether your 
experience matches Karol's... I am *MUCH* less concerned since 
that was compiled from VB in .NET architecture... whereas the 
reference SQRL client I'll be writing will -- like the DNS 
Benchmark, and thus my reference to it -- be raw assembly code 
directly calling into the base Win32 API... which I believe WINE 
has pretty much nailed.  :)

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/16/2014 8:06:29 PM
Steve Gibson was heard to say :

> https://www.grc.com/sqrl/operation.htm

About "user password".
The dialog is designed to indicate a Log-in to a known ID.

In the button "other", you also specify the: "removing their SQRL identity 
from a website, or exchanging their old identity for a new one".

However, there seems to be no place to indicate/flag the "new identity".
Maybe below the enter field, between "clear" and "show".?

-- 
Mark Cross @ 02/16/2014 4:01 p.m.
Mother told me to be good, but she's been wrong before.

0
Mark
2/16/2014 8:06:46 PM
Steve Gibson was heard to say :

> [for the unabridged version, see AlanD's post above]
> 
> Alan,
> 
>> I have not had time to read and digest every message in this
>> NG,
> 
> (Who has?? :)

Am I the only one?  :-O
 

-- 
Mark Cross @ 02/16/2014 4:09 p.m.
Life is pleasant. Death is peaceful. It's the transition that's troublesome. 
— Isaac Asimov

0
Mark
2/16/2014 8:11:09 PM
[for the unabridged version, see Mark Cross's post above]

> Nit-picking:    :-)

No problem.

 
> Where it say "77-digit number".  Sorry, but 256 is 78 chars.

Hmmmm.  By my math,  Log10(2^256) = 77.06367888997919

That's where I got my "77-digit number" statement.

I (obviously) liked referring to SQRL's 256-bit keys as, 
instead, something more readily visualizable... namely a
77-digit number.

So... are we saying the same thing in different ways?


> In 77 decimal digits could there be only 255,78 bits of entropy.
> And as all the results have to be rounded to an integer, that
> amounts to 255 bits
> 
> Yes, of course, the capacity of 78 decimal digits is 259,11 bits
> of entropy, which is clearly space enough to contain the 256 bits
> of the keys.
> 
> But I believe that just saying:
>        "more than 75 decimal digits"
>     or "almost 80 decimal digits"
>     or "a bit less than 78 digits"
>     or "a tiny bit more than 77 digits"
> could be reasonable descriptions.

Ah!  Your: "a tiny bit more than 77 digits" does imply that you 
are looking at the same "77.06367888997919" that I was.

So... the nit you're picking is over the "rounding error" in my 
statement?

If so, it was deliberate.  :)

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/16/2014 8:14:20 PM
Steve Gibson was heard to say :

> But if by "the app" you meant that FirstHelp.exe

Yes, I meant FirstHelp.exe.

> I posted... while I would be curious to see whether your
> experience matches Karol's... I am *MUCH* less concerned since
> that was compiled from VB in .NET architecture... whereas the
> reference SQRL client I'll be writing will -- like the DNS
> Benchmark, and thus my reference to it -- be raw assembly code
> directly calling into the base Win32 API... which I believe WINE
> has pretty much nailed.  :)

Ok, got it.

-- 
Mark Cross @ 02/16/2014 4:13 p.m.
I'd buy you a drink, but I'd be jealous of the straw.

0
Mark
2/16/2014 8:15:16 PM
[for the unabridged version, see Mark Cross's post above]

> Steve Gibson was heard to say :
> 
> > https://www.grc.com/sqrl/operation.htm
> 
> About:    Why Backup?
> 
> You explain (correctly) the reason and need to store and/or print the "SQRL 
> private identity" which is (I believe) the older called IdUK. And as it is 
> encrypted, it is then "the encrypted IdUK". That is fine and correct.
> 
> However you miss to explain how to backup the "Rescue Code".
> 
> You miss the chance to explain that if, for any reason, the "Encrypted IdUK" 
> and the "Rescue Code" are stored together, no matter how big is the "rescue 
> Code" it will provide zero (0) bits of protection.
> 
> You must explain then: that the printed QR of the IdUK should be stored in 
> the safe with your other papers. and the "Rescue Code" should be kept in the 
> wallet.

I agree with all of that, Mark... but this wasn't the right 
place for that.  I will *definitely* make that clear when we get 
to that point in the UI.  At this juncture I was just wanting to 
convey some overall sense for the major issues facing SQRL 
users.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/16/2014 8:16:50 PM
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--viFEHtWwEvjDq2KR1g9hKPWkRvKpowlpo
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Am 16.02.2014 21:15, schrieb Mark Cross:
>> I posted... while I would be curious to see whether your
>> > experience matches Karol's... I am *MUCH* less concerned since
>> > that was compiled from VB in .NET architecture... whereas the
>> > reference SQRL client I'll be writing will -- like the DNS
>> > Benchmark, and thus my reference to it -- be raw assembly code
>> > directly calling into the base Win32 API... which I believe WINE
>> > has pretty much nailed.  :)
> Ok, got it.

Nevertheless it would be great if you could actually test it in your
environment, because it was quite glitchy for me - especially when
switching tabs. Not sure whether there is something wrong with my
graphics stack, or whether it is the application itself, although I
can't remember having so much glitches with any other application in the
past.

Best regards,
Karol Babioch


--viFEHtWwEvjDq2KR1g9hKPWkRvKpowlpo
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTASDmAAoJEHSaZc1HnzIVS5oP/jbTnVnPEd9gzRaMFsjPzjSy
CkewiaLJrPem5wlg+SNr2hF6r2CgpGyCBYuIr8JxVjEZUNlzFRAVuTnZS1O3AnKD
ck1EbbIiV8X5IKLJWx1xvoZAw26S1XXBYi7+2ybb3rlSusomiK8YGxAl285PydKI
2K/gOstdxtomZV1Ah+pCNcSNkmNh/U18C4Pwr09k68TVHt6ljekBmkT5ISbQ7/VY
9MZV7D4aysQScbSgKcoRTbLgvYUh7VRbwUYfx0hMb3IrqaP0pYmcvkZ5V2MZaiQK
wxM3At7om+eglzRDfRC8Q7pcFvWfohGkrwhTSkXNgPIM3df4fwBMiw29DhjVDh3O
BHTKI6kapZGR1FXvFFrWo9avVdZ7HxDm7F94njhwRwU9sZoEwHQX32P7rmIVpHBu
F4F0LzIf8CompcAiaCts/sbZGm8CN0VYa7Eq5fAyqnhe0mjZkSTOkPEwqF0e4npw
cHc/xZKWpD5xowBvH6Wxil/a7smNL6sBYy90KyL7uCs5/OaZduKKSM+c1o9MKjGa
q3qnSVINqYFRhx5ILWriCI/3IZD1Gmt4RZ++fZyCAsFuBBqj0JUTi0ogsi6BFper
IWLQJgutic9KvEMaYJpErGNwLYDtXBoMvFUCBDm5sw5jNobne9YU5Y3wAWYSSZk/
7i6g3cvDwrCAKNSQa46p
=Al+m
-----END PGP SIGNATURE-----

--viFEHtWwEvjDq2KR1g9hKPWkRvKpowlpo--
0
Karol
2/16/2014 8:34:46 PM
Steve Gibson was heard to say :

>> Where it say "77-digit number".  Sorry, but 256 is 78 chars.
> 
> Hmmmm.  By my math,  Log10(2^256) = 77.06367888997919
> 
> That's where I got my "77-digit number" statement.

Hmmm, What I did was: log2(10^77)=255,788
And:                  log2(10^78)=259,11

Which represents the entropy contained in a 77 and 78 "10-digit" number.

What you did is equivalent to:
    log2(2^256) / log2(10)  =    77.06367888997919

Which ROUNDED UP to the nearest integer is 78 digits.

See: the number you got means that a little bit more than 77 is needed.

> I (obviously) liked referring to SQRL's 256-bit keys as,
> instead, something more readily visualizable... namely a
> 77-digit number.
> 
> So... are we saying the same thing in different ways?

Kind of, yes. But, by a very narrow marging, 256 bits could NOT fit inside 
just 77 decimal digits.

>> In 77 decimal digits could there be only 255,78 bits of entropy.
>> And as all the results have to be rounded to an integer, that
>> amounts to 255 bits
>> 
>> Yes, of course, the capacity of 78 decimal digits is 259,11 bits
>> of entropy, which is clearly space enough to contain the 256 bits
>> of the keys.
>> 
>> But I believe that just saying:
>>        "more than 75 decimal digits"
>>     or "almost 80 decimal digits"
>>     or "a bit less than 78 digits"
>>     or "a tiny bit more than 77 digits"
>> could be reasonable descriptions.
> 
> Ah!  Your: "a tiny bit more than 77 digits" does imply that you
> are looking at the same "77.06367888997919" that I was.
> 
> So... the nit you're picking is over the "rounding error" in my
> statement?

> If so, it was deliberate.  :)

Well, it either fits or not. If it hits the walls, even if it only means a 
long paint scratch on both sides, it does not fit !! ;-)

-- 
Mark Cross @ 02/16/2014 4:21 p.m.
Unix is user friendly – it's just picky about its friends.

0
Mark
2/16/2014 8:35:32 PM
Karol Babioch was heard to say :

> Nevertheless it would be great if you could actually test

Sure, Karol, just give some slack to make the VMs ready. :-)

I'll be back soon.

-- 
Mark Cross @ 02/16/2014 4:36 p.m.
All programmers are optimists. — Frederick P. Brooks, Jr

0
Mark
2/16/2014 8:38:06 PM
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--K09rQkLdePw91Ks9fwG9cR84xO6mAKsEm
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Am 16.02.2014 20:43, schrieb Steve Gibson:
> This trouble could me mitigated simply by having visiting Uncle=20
> Fred change his password on that one machine during his visit.

Maybe you could implement some sort of avatar right next to the chosen
identity. At least that was my plan for the Android client, because this
kind of personalization is good habit on mobile devices anyway.

Best regards,
Karol Babioch


--K09rQkLdePw91Ks9fwG9cR84xO6mAKsEm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTASJEAAoJEHSaZc1HnzIVwxgQALIuyVCxbjI4Io3/wvX8c8Ah
LhC7xaUrRLlhNnR9m05XuCn4gZifYHL5jPSvDPPWqRUFc2Rg5j/JjssCyqmD8Zoy
C0xGlk9EHPsxLwJ4WCYTHUIzVmUuCvzoAMjIT5X+dvTf3AR9b3ixX1A0qdwiKVcQ
sv8MA/ZWZ22GeCFowkeWpJ4qr57vd5PlfJR10Y+t1Egbt/BV/z1wXkAJFX5YAsbq
zIANQCIliXx4MjBdYGek1yKQjcPq/pXOwnp1XqKvd1UPHe3wy7TdaVeZ197tcdVt
Tg4rGX4gtecCAKzNnQTP8pHDWa7nJdUb1FDlxRQQQWk1jcre2Qv5S9YMvGHzmeHY
hKs/7It8dbQnqbEx2W1AkWEGnv8TZ6Em+Wxkgkq06kS0g5mVHWK8cB1wNGrN/Tyx
LW90MFM8RQB0Whv5B/Z1STsVHOvEWxs08sFkOZaLAkIMmHiC0xwRRPoqIMhAA3o6
r2LWw8yECQL38p/2gvUxz4GcxU98fuCqeGZIswrQFJtty/u+szU3txA0c5EEGRN1
9NTgshA0zHtzv4fP5YQPlGifmvVEMfq6clPJy3PQf4ekXQJez5afgkfsnbFxzUZN
iBfsd4xAoP+HWuwmDM8qTVLSmTUmrfF1BcDzbZdPR3/YjoiM6051UeU9S1R7y965
uRTBgorhN0DpyNb3SUQZ
=7loW
-----END PGP SIGNATURE-----

--K09rQkLdePw91Ks9fwG9cR84xO6mAKsEm--
0
Karol
2/16/2014 8:40:36 PM
[for the unabridged version, see Karol Babioch's post above]

> Maybe you could implement some sort of avatar right next to
> the chosen identity. At least that was my plan for the Android
> client, because this kind of personalization is good habit on
> mobile devices anyway.

I was thinking of, perhaps, allowing the user to set the 
background coloration of their identity's password prompt 
dialog. That has the advantage of not requiring any external 
resources. They would quickly become accustomed to "their 
color" and notice when the color was wrong.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/16/2014 8:49:21 PM
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Aqje32cJMlEp1fuXilGIFNGUX12ChrVv7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Am 16.02.2014 21:11, schrieb Mark Cross:
> Steve Gibson was heard to say :
>=20
>> > [for the unabridged version, see AlanD's post above]
>> >=20
>> > Alan,
>> >=20
>>> >> I have not had time to read and digest every message in this
>>> >> NG,
>> >=20
>> > (Who has?? :)
> Am I the only one?  :-O

No, I try to stay current, too, although I missed a lot of messages in
the very beginning. But it is *definitely* time consuming and I'm not
claiming to completely understanding each and every proposal with all of
its consequences for the whole architecture.

So Steve's job isn't that desirable, and I think - generally speaking -
he does a pretty damn good job! Hats off!

Best regards,
Karol Babioch




--Aqje32cJMlEp1fuXilGIFNGUX12ChrVv7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTASZDAAoJEHSaZc1HnzIVbVcP/1FDPLNuJXViooY4HEf8N04x
F1yybemdDg4ik76EuoYOUIDVWTKL/FrMPBYprSR4eJtyF7iitlm1HyOLyLn+cXVK
9ok9OHk4spCMEy9BY3kHaB7fOCrz5oKIH68gDIcjRZ3ac3iVFJlti1/VNIdUigyJ
If8Q7FMZjwdwGy2bBR6qM1PtdFY+FlQIap2jrGRPgINbfeYHOToQDcp0vufs2IPr
5fEDb4LdH8JmRd1II8fhaF7z3Tje6hVUrwbbEQVlya1Dpyfei5l6fn7AMzTJEohI
+cBxZhcB2OxMlyuhEbWQyPhzLdWmbclJt+9u1Tn9AnipZ9qmKyM9VWp02NWB9Rr9
7yY8lq5d196UHKuB/Ab51KMn5/1XyC2JJBbce3/9Lk+lkGCO5ik9TtO5WgyRVw5D
aBwDgTrCoJnZrev9Ah3CXp0cFBpB2LpQmbTzf1foWl6LxqqwolpgryXhVrZtWKVZ
r/A+61Ka4fOEqoENOHwQ3s/tHVgMI48DbH/ZdNoNQ0clvM2SihShoS876UYTFdcY
+wR3kqOFB8o+msrRUCjTrx//CrbASHt8+4u8eQ4z1UB+IVRIRFiQ4m7xAf7YWvMn
Kj1fIV9N6tsWBW6a76jeuz6sxSEps6xUQdbiNQd9bLNTyjupXCSziORE98JM0Zhs
x+ijB+HyJR8Ud36HuwHx
=aorJ
-----END PGP SIGNATURE-----

--Aqje32cJMlEp1fuXilGIFNGUX12ChrVv7--
0
Karol
2/16/2014 8:57:39 PM
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--VQtDqUdDTM0fn8IOTUsJKSo3uNi7Un8rv
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Am 16.02.2014 21:49, schrieb Steve Gibson:
> I was thinking of, perhaps, allowing the user to set the=20
> background coloration of their identity's password prompt=20
> dialog.

Yeah, that will work just fine in the beginning. Not sure whether it is
the best solution, but at least it makes it obvious (to us) that
something is "wrong" in these cases.

> That has the advantage of not requiring any external=20
> resources.

Couldn't a small avatar/picture be part of the identity itself? At least
GPG offers this option and with my (admittedly rough) understanding of
your "secure storage format" proposal it should be possible in theory.
On the other hand I'm not sure whether the planned QR code(s) can
actually hold that much information.

If not, it starts to get a mess ...

Best regards,
Karol Babioch


--VQtDqUdDTM0fn8IOTUsJKSo3uNi7Un8rv
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTASeKAAoJEHSaZc1HnzIVBbIP+wYa6MJw+lbyfT52MlcThK6a
D0SeCJiJJMW44/BJ7l9tRF/2UqhzWZZa9eoX7M1iD0l0GE53qWAwJVCFKFs7yIb/
9ne4zhGVf+MRLDJt1HvB9n9yWeIi3Ov0a/2rTIHhkz3H3Q6v8q0cfNBRK6fqUXMQ
3stiXKS2D6tER2RcgToFZMszgoYfGtRz3b1usn2hRRnLIBMNPh77iMcV0aelfI1n
+zfKTQorx6iK7VrEg9KT5elWzck0Kt7c9zBtm54qYxLBpGYMBC41BvXaAJLmIlgs
PnTx2Mv6ucrqxCKEUAGiAIf2fg6fvfL4qy8/dAzFSYcbjAIbPcrXxXHJWwRzFrxf
s/k15JSLjo3UslHsoqnE9XUuyTlUnxY/IKHa+1fTSAiD64+5UWvwuNOJr06qlHx2
NXFy2GhqhWsYXodNiSqPFVaOV+VYaU+0tvjT898udrRUg4hmVoXgZeiCTfLIEpj7
v+wNqKumO5qq55wuLPQ82KdxzmHCiVhDTqq8isBen8zASCoUJGT6+ztXazlMRxrV
o8qtBXVLjFap62+QRm6jKprTI2KjwMgkEoPFH3ba1+xJzk6Xiuk7KivUIsByMBaj
8sYaluD9nqnk0IfxATDtyaKC1apktxOhheaTfCtuQ8VfZItZzRGUfl9NZ5QTdbn7
o9rU+NZAleKwxG5id344
=vyc3
-----END PGP SIGNATURE-----

--VQtDqUdDTM0fn8IOTUsJKSo3uNi7Un8rv--
0
Karol
2/16/2014 9:03:06 PM
Karol Babioch was heard to say :

> Hi,
> 
> Am 16.02.2014 21:11, schrieb Mark Cross:
>> Steve Gibson was heard to say :
>> 
>>> > [for the unabridged version, see AlanD's post above]

>>> > Alan,

>>>> >> I have not had time to read and digest every message in this
>>>> >> NG,

>>> > (Who has?? :)

>> Am I the only one?  :-O
 
> No, I try to stay current

Was intended as a tongue in cheek comment Karol, I do not believe this is a 
competition, other than to joke about it. :-)


-- 
Mark Cross @ 02/16/2014 5:00 p.m.
If you try and don't succeed, cheat. Repeat until caught. Then lie.

0
Mark
2/16/2014 9:05:57 PM
On 2014-02-15 10:34, AlanD wrote:
> Steve Gibson wrote:
>> [for the unabridged version, see Steve Gibson's post above]
>>
>> I have the initial SQRL UI page posted:
>>
>
> I have not had time to read and digest every message in this NG, but I
> do not understand what this sentence is referring to.
>
> In the "Your SQRL password" section, the sentence "And to make longer,
> more complex passwords less painful to use, the password's first four
> characters may be used to "refresh" the full password you originally
> entered." worries me, and, I think, would worry any potential SQRL user.

Think of the full password as what you have to enter to login when you 
first boot your system, and the "refresh" as what you enter to unlock 
your screensaver.

Basically, having decrypted the hard-copy from the hard-drive or SD-card 
of your device, your SQRL app is now keeping the encryption keys in 
memory, but may still lock its UI.

The software may even encrypt the key in memory with this short string, 
though that theoretically weakens the password. Though of course only an 
attacker with bad timing would need to care -- if they can steal the 
memory containing a key encrypted with the first four characters, then 
they just have to be active at a different time to steal the key when it 
is unencrypted.

I guess forensics on swap files might be a concern. An attacker might 
have an old hard drive and no ability to go back and try again. Even so, 
a weakly encrypted SQRL identity will be better than an unencrypted 
identity.

My preference is for UI unlocking via a shortened password to be 
optional. Is there any thought towards adding an options block to the 
SQRL identity, or would this be something to request as a configuration 
option on a per-app rather than per-identity basis?

Regards,
Sam
0
Sam
2/17/2014 6:00:21 AM
On 2014-02-16 12:34, Karol Babioch wrote:
> Hi,
>
> Am 16.02.2014 21:15, schrieb Mark Cross:
>>> I posted... while I would be curious to see whether your
>>>> experience matches Karol's... I am *MUCH* less concerned since
>>>> that was compiled from VB in .NET architecture... whereas the
>>>> reference SQRL client I'll be writing will -- like the DNS
>>>> Benchmark, and thus my reference to it -- be raw assembly code
>>>> directly calling into the base Win32 API... which I believe WINE
>>>> has pretty much nailed.  :)
>> Ok, got it.
>
> Nevertheless it would be great if you could actually test it in your
> environment, because it was quite glitchy for me - especially when
> switching tabs. Not sure whether there is something wrong with my
> graphics stack, or whether it is the application itself, although I
> can't remember having so much glitches with any other application in the
> past.

It would probably be something to forward to the wine developers, if 
anything.

It could be that Wine's .net thingamajigs aren't up to where they 
should/could be.

As to utility for SQRL itself? Steve has already mentioned that this is 
just a UI prototype, and doesn't necessarily resemble, codewise, what 
his app toolchain would emit.

Regards,
Sam
0
Sam
2/17/2014 6:53:59 AM
On 2014-02-15 12:38, Steve Gibson wrote:
[...]
> In terms of implementation, we do NOT want to actually retain
> ANY of the user's actual password in RAM.  So when they enter
> their FULL password, we hash not only the entire password, but
> also the first four characters alone.
>
> We then use the result of the full EnScrypt process to decrypt
> into RAM their permanently stored encrypted master key.  And
> we're good to go.
>
> At the same time we re-encrypt their decrypted master key under
> the key generated from the first n-characters (by default 4) of
> their full password. We keep in RAM the hint-encrypted key and
> its OCB auth-tag.

It is probably going to be a bit trickier than that. We will need the 
decrypted MK value in memory at some point, though we don't want to keep 
it longer than we absolutely have to.

> Once we've used the decrypted key for its purpose, we scram it
> from RAM under the general policy of NEVER leaving anything
> unencrypted in RAM that we don't need to.

So the user unlocks their SQRL program using the full password, then has 
to enter the hint every time they want to authenticate?

Or does the program keep the hash of the hint in memory for some short 
period (say, 5 minutes) to decrypt the hint-encrypted key when 
authentication actually needs to be performed?

FWIW, the hint-encrypted key won't be significantly resistant to 
brute-force, even if we use EnScrypt. And obtaining the hint-encrypted 
key could potentially weaken the "real" password -- an attacker who can 
brute-force the hint will learn the first four characters of the 
password (in addition to the MK -- the real prize). On the plus side, it 
is only an attacker with very bad timing reading RAM while the key is 
encrypted who would have to stoop to brute forcing.

It is still miles better than keeping everything decrypted in RAM.

Another approach I can think of, that would remove the potential 
password weakening (but not the potential decryption of the MK from RAM 
-- that is pretty much impossible) would be for the hint to be 
deterministically derived from the password and salt. You could EnScrypt 
the final key with weak parameters to produce a "hint key" (used to 
hint-encrypt the in-memory storage) then transform the hint-key to 
produce a 4-digit "PIN" that would be uniquely chosen for a given 
identity and password. Store the "verifier" in memory, but only offer to 
use it if the same derived PIN is entered. Users could request new PINs 
when generating (or recovering) their identity by having the SQRL app 
generate new salt for their current password if they don't like the PIN 
they have.

Overall, I don't think risking four characters of the password is a 
problem that really needs solving in the face of a memory-accessing 
attacker who would also be obtaining the MK (by obtaining those four 
password characters). From a UI point of view, where you are at 
currently, it would be a bunch of additional headache anyways, and 
people probably won't want to remember "their" password and "our" PIN.

Regards,
Sam
0
Sam
2/17/2014 7:16:51 AM
On 2014-02-16 11:08, Steve Gibson wrote:
[...]
> Given that the hint-length can be set, and that the user's
> password can be wiped on demand, I think the password hinting
> solution creates the right usage incentives and helps to make
> SQRL even easier to use.

My plan will be to create a password that looks something like this:

[easy-stuff-for-a-pin][password-meeting-my-worst-case-entropy-requirements].

Something like:
5*[0-9]N*[diceware word]

Of course, an attacker who has brute-forced 5*[0-9] will have my MK from 
memory, but it won't be revealing anything about how I choose the rest 
of my password.

If an attacker brute-forced a hint that went "it was the best of times", 
they might surmise that the user in question was fond of book quotes or 
something, in addition to obtaining their MK.

I know I'd be more worried about the MK. :P

Regards,
Sam
0
Sam
2/17/2014 7:22:37 AM
On 2014-02-16 10:22, dave_k wrote:
[...]
> Alice, Bob and Clare's passwords all start with 'monkey' so how will SQRL
> cope if all three are active at the same time?
>
> Uncle Fred comes to stay for a few weeks and clones his SQRL ID on to the
> PC, Unfortunately his password is identical to Alice's. [monkey123]
> Is this a problem for SQRL?

Do none of these people have smartphones? *g*

I could suggest that the Windows/Mac/Linux SQRL.exe be "portable", 
capable of running from any folder on the system.

So when Alice and Bob create their SQRL identity, they would just copy 
SQRL.exe into a new folder, and the .sqrl file consisting of their 
identity would exist in that folder (or any other folder, if SQRL.exe 
was installable with a file association).

All we really need is a way to distinguish between multiple SQRL windows 
on a desktop (or mobile) OS, and allow multiple concurrent instances. I 
*think* each SQRL identity was going to have an optional "name hint" or 
something -- we could display that prominently in each window. So 
Alice's SQRL windows might all say "Mom" at the top of the window, and 
so on.

Or we could create our own cryptographic naming hint, derived from some 
static part of the identity (the MK?) that each user would come to 
recognize. Something like the first four characters of:

SHA-256-HMAC("naming-hint",MK)

Regards,
Sam

0
Sam
2/17/2014 7:30:57 AM
On 2014-02-16 11:43, Steve Gibson wrote:
> [for the unabridged version, see dave_k's post above]
[...]
>> In terms of security the above stinks but I see it all too often
>> in the real world. It's how people use computers now and they
>> will expect to use SQRL in the same way, or else they will just
>> carry on using monkey123 on every site.
>
> The only thing I can see doing differently might be to have an
> option in SQRL -- when more than one identity is installed -- to
> EXPLICITLY PROMPT for the identity the current user wishes to
> use.

Would multiple SQRL.exe processes with multiple "windows" (or 
trayicons?) be a simpler approach?

I guess that is a bit tricky if SQRL.exe is being called by a URL 
handler. Inter-process communication. Ugh. ;)

Regards,
Sam

0
Sam
2/17/2014 7:33:51 AM
On 2014-02-16 13:03, Karol Babioch wrote:
[...]
> Couldn't a small avatar/picture be part of the identity itself? At least
> GPG offers this option and with my (admittedly rough) understanding of
> your "secure storage format" proposal it should be possible in theory.
> On the other hand I'm not sure whether the planned QR code(s) can
> actually hold that much information.

We could try something like this, then SQRL would just have to display a 
tiny version of the QR code. *g*

http://research.swtch.com/qr/draw

Regards,
Sam

0
Sam
2/17/2014 8:05:26 AM
Karol Babioch was heard to say :

> Couldn't a small avatar/picture be part of the identity itself?

http://digitalconsumption.com/forum/Visiglyphs-for-IP-visualisation
Based on Don Park's idea:
    http://blog.docuverse.com/
    http://haacked.com/archive/2007/01/22/Identicons_as_Visual_Fingerprints.aspx/
    http://en.wikipedia.org/wiki/Identicon
        
This does something similar, but too low resolution IMO:
    http://identicon.org/


-- 
Mark Cross @ 02/17/2014 4:23 a.m.
There are 10 types of people, those who understand binary and those who 
don't.

0
Mark
2/17/2014 8:36:52 AM
Steve Gibson wrote:
>
>> Uncle Fred comes to stay for a few weeks and clones his SQRL ID
>> on to the PC, Unfortunately his password is identical to Alice's.
>> [monkey123] Is this a problem for SQRL?
>
> It's fine UNLESS Fred and Alice fail to notice when the other's
> identity is currently selected and they authenticate with a
> password that works with the other's identity.
>
> This trouble could me mitigated simply by having visiting Uncle
> Fred change his password on that one machine during his visit.
>

But that assumes that Fred and Alice somehow realise that they have the same 
password, or everyone discloses their password to Fred so he can check that 
his is different.

AlanD
0
AlanD
2/17/2014 11:34:09 AM
[for the unabridged version, see Sam Schinke's post above]

> Would multiple SQRL.exe processes with multiple "windows"
> (or trayicons?) be a simpler approach?
> 
> I guess that is a bit tricky if SQRL.exe is being called
> by a URL handler. Inter-process communication. Ugh. ;)

Right.  And if we did have multiple instances, then the user 
would still need to remember to choose the right one.

Password & Hint re-prompting is, I think, a sufficiently good 
solution for this case.  At some point this begins moving "out 
of scope" for us.  

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/17/2014 4:32:24 PM
[for the unabridged version, see AlanD's post above]

> But that assumes that Fred and Alice somehow realise that they
> have the same password, or everyone discloses their password
> to Fred so he can check that his is different.

Right.  This would likely happen the first time either of them 
logged into the other's account inadvertently. I don't see any 
obvious way around that.

If the communal-computer problem seems to worrisome, the house's 
users could fall back to using their smartphones, if available.

I think that allowing a background coloration, and perhaps
a pattern, to be set on the password dialogs is likely the 
simplest visual reminder.  Though, again... all we can do is 
provide the tools.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/17/2014 4:37:12 PM
[for the unabridged version, see Sam Schinke's post above]

> I *think* each SQRL identity was going to have an optional
> "name hint" or something -- we could display that prominently
> in each window. So Alice's SQRL windows might all say "Mom"
> at the top of the window, and so on.

Yes. It's in the current UI design.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/17/2014 4:39:42 PM
[for the unabridged version, see Sam Schinke's post above]

> It is probably going to be a bit trickier than that. We will
> need the decrypted MK value in memory at some point, though
> we don't want to keep it longer than we absolutely have to.

Right. The logic would be to prompt for the password or the 
hint, verify that it validates for the user's sake, use that to 
decrypt the MK, use it to sign the transaction(s), holding it 
until we have confirmation that we're finished, then overwrite 
it in RAM.


> > Once we've used the decrypted key for its purpose, we scram it
> > from RAM under the general policy of NEVER leaving anything
> > unencrypted in RAM that we don't need to.
> 
> So the user unlocks their SQRL program using the full password,
> then has to enter the hint every time they want to authenticate?

That's one option.  There will be many.  In my own environment I 
would prefer that for malware protection.  Not requiring 
something from the user means that the MK is sitting there 
statically decrypted in RAM.  I think I'd rather quickly enter 
the start of my password.


> Or does the program keep the hash of the hint in memory for
> some short period (say, 5 minutes) to decrypt the hint-encrypted
> key when authentication actually needs to be performed?

There will be plenty of options.  I'm working to get the 
settings pages published.


> FWIW, the hint-encrypted key won't be significantly resistant
> to brute-force, even if we use EnScrypt.

True.  Did you encounter my rather thorough discussion of the 
clear security implication of this?


> And obtaining the hint-encrypted key could potentially weaken
> the "real" password -- an attacker who can brute-force the hint
> will learn the first four characters of the password (in addition
> to the MK -- the real prize).

Right.


> On the plus side, it is only an attacker with very bad timing
> reading RAM while the key is encrypted who would have to stoop
> to brute forcing.

A point I made yesterday.  We need to keep our threat model at 
least somewhat realistic.  Once an attacker is able to snapshot 
RAM, we have no real protection with or without "hinting".

The best I think we can do is minimizing the "snapshot window" 
by NOT leaving everything "open" once the application has been 
"unlocked" with the full-strength password.

Though, again, we'll have settings...  <g>

> It is still miles better than keeping everything decrypted in RAM.

Right.


> Another approach I can think of, that would remove the potential 
> password weakening (but not the potential decryption of the MK
> from RAM -- that is pretty much impossible)

Yep.


> ...would be for the hint to be deterministically derived from
> the password and salt. You could EnScrypt the final key with
> weak parameters to produce a "hint key" (used to hint-encrypt
> the in-memory storage) then transform the hint-key to produce
> a 4-digit "PIN" that would be uniquely chosen for a given identity
> and password. Store the "verifier" in memory, but only offer to
> use it if the same derived PIN is entered. Users could request
> new PINs when generating (or recovering) their identity by
> having the SQRL app generate new salt for their current password
> if they don't like the PIN they have.

All of that's certainly true... and I considered the security 
implications of the design I'm proposing (as I wrote elsewhere 
yesterday... you've likely found it by now. <g>)

It boils down to balancing user convenience versus security. 

I think the "problem" this poses is, while inarguably real, is 
also mostly synthetic: I designed it NOT as protection from a 
RAM scraper, but as a means for providing low-friction, per-use 
authentication so that no one else could use an already unlocked 
instance of the app.  And also because providing a short re-auth 
feels right.

Without this, we were either leaving the application completely 
unlocked (and thus the RAM scraping window propped wide open), 
or requiring the user to continually re-enter a (hopefully) long 
and complex password.

The reason I suggest that this is a synthetic "problem" is that 
if we're in the presence of a RAM scraper... we're blown anyway. 
That's NOT something it's practical for us to protect against. 
Any RAM scraper simply needs to (and WOULD) wait for the 
interactive communications to be occurring... and take their 
snapshot then.  No matter WHAT we do, we're vulnerable.


> Overall, I don't think risking four characters of the password
> is a problem that really needs solving in the face of a memory-
> accessing attacker who would also be obtaining the MK (by
> obtaining those four password characters).

You know, Sam, that the user's password doesn't matter AT ALL to 
a RAM scraper.

ALL they need to do is wait for when SQRL is communicating and 
they have what they need. An unfortunate side effect of the more 
interactive evolution of the design is that we need to keep the 
master key decrypted and available IN BETWEEN exchanges.  If it 
was just a single-shot event we could decrypt, sign, scram the 
key, and only then send the signed reply.

And if malware can grab keystrokes (which seems more likely -- 
though I do have on-screen keyboards coming) it's game over when 
the user enters their full password anyway.

By definition, NO SECURITY SYSTEM can operate in an environment 
of full malicious access to its the app's process space.


> From a UI point of view, where you are at currently, it would
> be a bunch of additional headache anyways, and people probably
> won't want to remember "their" password and "our" PIN.

I agree.  Or even "their" PIN.  That's why I thought the first 
few chars of their password was such a slick solution. It seems 
intuitive.  They know it already.  They recently provided the 
whole thing.  So they just "remind" the system by proving the 
first bits.  :)

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/17/2014 5:59:38 PM
[for the unabridged version, see Sam Schinke's post above]

> My preference is for UI unlocking via a shortened password to
> be optional.

Oh!... It's DEFINITELY optional.  I'll get those panels designed 
and posted ASAP.  That's my entire focus now.


> Is there any thought towards adding an options block to the 
> SQRL identity, or would this be something to request as a
> configuration option on a per-app rather than per-identity basis?

I think it makes more sense to keep the interchange about only 
the key.

Configuring will be simple and straightforward, and different 
platforms and apps will have different options.  Some make sense 
only on specific platforms.  And adding that to the key store 
would hugely complicate things for, IMO, little benefit.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/17/2014 6:04:08 PM
Steve Gibson wrote:

> And if malware can grab keystrokes (which seems more likely --
> though I do have on-screen keyboards coming) it's game over when
> the user enters their full password anyway.
>

Are there any implications from Windows 8 and it's touchscreen centric design?

In teh past virtual screen keyboards for crypto apps have not all presented 
a traditional QWERTY layout in an effort to reduce screen scraping. Now that 
the OS supports/encourages touch screen and virtual keyboards, there are 
probably more hooks available to apps to capture keystokes.

AlanD
0
AlanD
2/17/2014 7:14:55 PM
On 2014-02-17 8:32, Steve Gibson wrote:
> [for the unabridged version, see Sam Schinke's post above]
>
>> Would multiple SQRL.exe processes with multiple "windows"
>> (or trayicons?) be a simpler approach?
>>
>> I guess that is a bit tricky if SQRL.exe is being called
>> by a URL handler. Inter-process communication. Ugh. ;)
>
> Right.  And if we did have multiple instances, then the user
> would still need to remember to choose the right one.
>
> Password & Hint re-prompting is, I think, a sufficiently good
> solution for this case.  At some point this begins moving "out
> of scope" for us.

Right. I was just trying to consider which approach would be simpler on 
the programming side. While multiple-users, single system-login isn't 
really a scenario I would want to cater to, a single user with multiple 
SQRL identities is definitely worth thinking about, and that takes care 
of the former example too.

The simplicity of a single application that presents an "identity 
chooser" of some sort when activated by a URL-handler (likely to be a 
decoded SQURL sent via a command-line or other IPC parameter) seems 
vastly simpler than multiple independent running applications and some 
entirely separately programmed handler/helper app that lets users choose 
between those applications.

Sandboxing between the processes holding different loaded identities 
would be one benefit of multiple processes, but that can be obtained by 
a multi-threaded app as well (eg, like Chrome -- threads rather than 
forks). Or just re-locking identities that need to be sandboxed when 
less secure activities are occurring. If it isn't even partially 
decrypted in memory, anywhere, you are doing way better than a mere sandbox.

Regards,
Sam
0
Sam
2/17/2014 8:51:21 PM
On 2014-02-17 8:39, Steve Gibson wrote:
> [for the unabridged version, see Sam Schinke's post above]
>
>> I *think* each SQRL identity was going to have an optional
>> "name hint" or something -- we could display that prominently
>> in each window. So Alice's SQRL windows might all say "Mom"
>> at the top of the window, and so on.
>
> Yes. It's in the current UI design.

Yeah, I though I remembered it being mentioned, but things are changing 
pretty quickly at this point. I think it may be telling of the 
complexity that SQRL has become (or just the pace of change) that "all 
the details" are starting to escape my (if not our collective) grasp.

I'd rather throw out an un-needed reminder/query (and re-assurance to 
dave_k) than say nothing about one way the specific problem being 
discussed may be mitigated.

Regards,
Sam

0
Sam
2/17/2014 8:55:14 PM
On 2014-02-17 9:59, Steve Gibson wrote:
> [for the unabridged version, see Sam Schinke's post above]
>
>> It is probably going to be a bit trickier than that. We will
>> need the decrypted MK value in memory at some point, though
>> we don't want to keep it longer than we absolutely have to.
>
> Right. The logic would be to prompt for the password or the
> hint, verify that it validates for the user's sake, use that to
> decrypt the MK, use it to sign the transaction(s), holding it
> until we have confirmation that we're finished, then overwrite
> it in RAM.

Right.

I know the "ram scraping adversary" is already a star-killer, as it 
were, but I don't think that should stop us from looking at potential 
footholds that lesser forms of that adversary (ie, able to scrape RAM 
once, not able to choose the time of their attack, etc) might be able to 
take advantage of.

One issue with waiting for confirmation before wiping the MK from memory 
is that an attacker could potentially manipulate the flow of network 
traffic to prevent this confirmation. This leaves the potential for the 
MK to be left decrypted longer than intended, and a network-interfering 
adversary may also attempt various exploits at the same time as they 
believe they have "frozen" a MK in RAM. This could broaden the attack 
window for obtaining a fully decrypted MK somewhat.

Of course, a network-manipulating adversary could always try to exploit 
the system when they believe there is a "hint" encrypted MK present on 
the system, so preventing the receipt of confirmation isn't a *huge* 
gain for the adversary.

I don't think there is a ton that can be done about the former with the 
current multiple-round-trip SQRL protocol, other than to time-out 
aggressively/opportunistically.

>>> Once we've used the decrypted key for its purpose, we scram it
>>> from RAM under the general policy of NEVER leaving anything
>>> unencrypted in RAM that we don't need to.
>>
>> So the user unlocks their SQRL program using the full password,
>> then has to enter the hint every time they want to authenticate?
>
> That's one option.  There will be many.  In my own environment I
> would prefer that for malware protection.  Not requiring
> something from the user means that the MK is sitting there
> statically decrypted in RAM.  I think I'd rather quickly enter
> the start of my password.

Right, statically decrypted, or only encrypted by a value also in RAM or 
on disk.

>> Or does the program keep the hash of the hint in memory for
>> some short period (say, 5 minutes) to decrypt the hint-encrypted
>> key when authentication actually needs to be performed?
>
> There will be plenty of options.  I'm working to get the
> settings pages published.

No problem. :) I was going with the idea that even if only for UI 
simplicity there would be some defaults.

>> FWIW, the hint-encrypted key won't be significantly resistant
>> to brute-force, even if we use EnScrypt.
>
> True.  Did you encounter my rather thorough discussion of the
> clear security implication of this?

Yep. I was posting as I caught up on the thread, but I see, to my 
complete lack of surprise, that others raised similar queries or reached 
similar conclusions, as well as your further details.

>> And obtaining the hint-encrypted key could potentially weaken
>> the "real" password -- an attacker who can brute-force the hint
>> will learn the first four characters of the password (in addition
>> to the MK -- the real prize).
>
> Right.
>
>
>> On the plus side, it is only an attacker with very bad timing
>> reading RAM while the key is encrypted who would have to stoop
>> to brute forcing.
>
> A point I made yesterday.  We need to keep our threat model at
> least somewhat realistic.  Once an attacker is able to snapshot
> RAM, we have no real protection with or without "hinting".

Right -- we can mitigate, and be clear about what our mitigation 
accomplishes.

> The best I think we can do is minimizing the "snapshot window"
> by NOT leaving everything "open" once the application has been
> "unlocked" with the full-strength password.

Right. This is similar to how various password/key managers give 
different settings for how and when to re-lock them, though I think the 
idea of using a substring of the full password for a "soft(er) lock" is 
a new one to me.

The closest I could come to it is a discussion I had with someone in one 
of the other newsgroups about encrypted filesystems on Android phones. 
In particular we talked about how the default configuration is to 
require the full decryption passphrase each time the phone needs to be 
unlocked, which is a usability nightmare. The other party to the 
discussion mentioned customizing some scripts or running some automation 
via Tasker or something in order to ensure that a weaker unlock method 
was permissible after the device finished booting.

[...]
> The reason I suggest that this is a synthetic "problem" is that
> if we're in the presence of a RAM scraper... we're blown anyway.
> That's NOT something it's practical for us to protect against.
> Any RAM scraper simply needs to (and WOULD) wait for the
> interactive communications to be occurring... and take their
> snapshot then.  No matter WHAT we do, we're vulnerable.

Right. Which is why I mentioned a less capable/unlucky ram scraper and 
swap-file forensics. It isn't something we can solve, but I think we are 
agreed on being clear about what is exposed at given points in time.

>> Overall, I don't think risking four characters of the password
>> is a problem that really needs solving in the face of a memory-
>> accessing attacker who would also be obtaining the MK (by
>> obtaining those four password characters).
>
> You know, Sam, that the user's password doesn't matter AT ALL to
> a RAM scraper.

Right. My point there was that if some degenerate form of ram scraper 
were only able to capture the hint-encrypted MK, the attacker would be 
*vastly* more pleased (and the user vastly more harmed) by their 
eventual decryption of a MK than at any information they may obtain 
about passwords.

Yes, a bit of password information would be guessed, but that is like 
worrying about a mosquito bite while staring down the barrel of a gun.

> ALL they need to do is wait for when SQRL is communicating and
> they have what they need. An unfortunate side effect of the more
> interactive evolution of the design is that we need to keep the
> master key decrypted and available IN BETWEEN exchanges.  If it
> was just a single-shot event we could decrypt, sign, scram the
> key, and only then send the signed reply.

Hmm. I wonder if there would be any way to get around that. Kidding!

Though I'm sure we could come up with some convoluted system like the 
IUK/ILK system to accomplish this minor good, it would still only 
progressively narrow the window in which the decrypted MK must be 
present in RAM.

> And if malware can grab keystrokes (which seems more likely --
> though I do have on-screen keyboards coming) it's game over when
> the user enters their full password anyway.

Right. I'm not too convinced by the idea of on-screen keyboards as a 
security improvement. Sure, they may lay waste to things like hardware 
keyloggers (especially with randomized layouts, as mouse input could 
also be logged), but IMO, anything sniffing keystrokes in software can 
also do screencaps if it wanted to.

> By definition, NO SECURITY SYSTEM can operate in an environment
> of full malicious access to its the app's process space.

Well, we could go all the way down to the last turtle and propose TPM, 
or code running on a JavaCard device (eg, Yubikey Neo).

But yeah, your point is taken.

>>  From a UI point of view, where you are at currently, it would
>> be a bunch of additional headache anyways, and people probably
>> won't want to remember "their" password and "our" PIN.
>
> I agree.  Or even "their" PIN.  That's why I thought the first
> few chars of their password was such a slick solution. It seems
> intuitive.  They know it already.  They recently provided the
> whole thing.  So they just "remind" the system by proving the
> first bits.  :)

Yes, it is a slick system. And a user concerned about the potential 
leakage of a few password characters in a situation where their MK is 
also compromised, and wanting to do something about it, merely needs to 
take the potential exposure of those password characters into account by 
lengthening their password or making those few characters something that 
is disposable.

SQRL is intended, at least in part, to eliminate 
use-the-same-password-everywhere-itis, anyways. ;)

Regards,
Sam
0
Sam
2/17/2014 9:31:56 PM
In article <MPG.2d680362978dbcea3c20@4.79.142.203>, Steve says...
> .  And I intend to begin assembling and publishing that 
> shortly.  But until then, if anyone is curious to see that first 
> "How SQRL Works" dialog, it's posted in the /dev/SQRL directory:
> 
> https://www.grc.com/dev/sqrl/FirstHelp.exe

The content looks good.

Thanks to the thread I understand the "refresh" thing (I didn't upon 
first read).

My geezer-level English objects to the verb "to login" found in the Your 
SQRL Password item (first sentence of second paragraph). But perhaps 
that's modern usage.

  --John (back to my cave)
0
John
2/18/2014 7:58:04 PM
:: On Sun, 16 Feb 2014 12:06:29 -0800
:: (grc.sqrl)
:: <MPG.2d6aba1da9402803c2c@4.79.142.203>
:: Steve Gibson <news007_@_grc.com> wrote:

> experience matches Karol's... I am *MUCH* less concerned since 
> that was compiled from VB in .NET architecture... whereas the 

Steve ... http://ilspy.net/ pick it, fire the app and point it to your
exe (or to whatever .NET dll/exe you want) ;-D

0
ObiWan
2/19/2014 3:28:40 PM
[for the unabridged version, see John W Baxter's post above]

> My geezer-level English objects to the verb "to login" found
> in the Your SQRL Password item (first sentence of second
> paragraph). But perhaps that's modern usage.

I've gone around and around about it, and there's been some 
discussion of it here. I've also spent some time searching
the Net for current thought. I think this is in the process
of moving from slang to formal acceptance.


>   --John (back to my cave)

Thanks for poking your head out.  There's a LOT more of the same 
now available here:  https://www.grc.com/sqrl/operation.htm

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/19/2014 6:14:45 PM
[for the unabridged version, see Sam Schinke's post above]

> Well, we could go all the way down to the last turtle and
> propose TPM, or code running on a JavaCard device
> (eg, Yubikey Neo).

As it happens, I'm meeting Yubico's Stina Ehrensvard tomorrow 
morning at 6am for coffee. She wrote a few weeks ago, saying:

"I will be in Irvine on Thursday Feb 20, and if you are 
available I would love to catch up for a early morning coffee at 
your local Starbucks, to discuss SQRL, FIDO and new upcoming 
Yubico inventions."

I have no idea what's on her mind... but I am certainly curious. 
She went completely silent after I sent her the links to those 
first early SQRL concept pages.

What would also be interesting, since "identity" is truly her 
personal crusade, is what, if any, effect the work on SQRL has 
had within the FIDO community.  (As we know, FIDO is the only 
real competition SQRL's adoption faces.)

Since Stina has always trusted me with information that I need 
to treat confidentially, I don't know what I'll be able to 
share, but I have planned to share what I can.  :)


> > I agree.  Or even "their" PIN.  That's why I thought the first
> > few chars of their password was such a slick solution. It seems
> > intuitive.  They know it already.  They recently provided the
> > whole thing.  So they just "remind" the system by proving the
> > first bits.  :)

> Yes, it is a slick system. And a user concerned about the potential 
> leakage of a few password characters in a situation where their MK is 
> also compromised, and wanting to do something about it, merely needs to 
> take the potential exposure of those password characters into account by 
> lengthening their password or making those few characters something that 
> is disposable.

Precisely.  AND, we do allow the user to change their password 
and its protection settings at any time... so they could use a 
virtual PIN prefix (as you mentioned back at the start of the 
discussion of this topic.)

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/19/2014 6:33:56 PM
On 14-02-19 01:33 PM, Steve Gibson wrote:
> [for the unabridged version, see Sam Schinke's post above]
>
>> Well, we could go all the way down to the last turtle and
>> propose TPM, or code running on a JavaCard device
>> (eg, Yubikey Neo).
>
> As it happens, I'm meeting Yubico's Stina Ehrensvard tomorrow
> morning at 6am for coffee. She wrote a few weeks ago, saying:
>
> "I will be in Irvine on Thursday Feb 20, and if you are
> available I would love to catch up for a early morning coffee at
> your local Starbucks, to discuss SQRL, FIDO and new upcoming
> Yubico inventions."
>
> I have no idea what's on her mind... but I am certainly curious.
> She went completely silent after I sent her the links to those
> first early SQRL concept pages.
>

Been quietly working on a similar idea here. If you take your lovely 
diagram at the top of page: https://www.grc.com/sqrl/key-flow.htm and 
draw a vertical dotted line down between the EnScrypt and OCB Encrypt 
boxes i.e.

|Enscript>---|--key-->(OCB Encrypt)

              |

              |

|Enscript>---|--key-->(OCB Encrypt)

  **Client**  |      **TPM**

Then everything to the left can be run in an SQRL Client Application on 
PC, Tablet, Phone etc and everything on the right can run in a low 
performance embedded device connected to it via serial port emulation 
and a simple API carried on whatever transport medium they share (NFC, 
Bluetooth, USB etc).

In addition the rest of the SQRL normal operation (signing, digesting, 
site key generation etc) would be API calls to the same device. Thus at 
no time are any private keys etc. exposed unprotected to a heterogeneous 
processing environment.

Now if Stina and Yubico plan to do this also the more the merrier, I 
also plan to GPL everything about my implementation once it is working.

Right now I'm trying to decide on hardware for the prototype, choice 
between Arduino, PIC and ARM Cortex M4 in the TI Stellaris Launchpad. I 
was also looking at using one of those really cheap tp-link 703n routers 
but with the unused interfaces disabled. That though needs an order of 
50 or so units to make it economical.
0
ramriot
2/19/2014 9:14:59 PM
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--miiauounBhO7REOF115KAk8ISdIB5NMeW
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Am 19.02.2014 22:14, schrieb ramriot:
> Right now I'm trying to decide on hardware for the prototype, choice
> between Arduino, PIC and ARM Cortex M4 in the TI Stellaris Launchpad.

I'm not sure that I understand the full scope of what you are trying to
achieve here, but if you really try to implement crypto within a
microcontroller, I would strongly encourage you to inform yourself about
the capabilities of the microcontroller being used.

Although it might be possible to pull off such a stunt with Arduinos,
AVRs and/or small PICs, it is definitively not necessarily something you
want to do. These small 8-bit microcontrollers are simply too "small" to
perform state of the art crypto. There exist only a few libraries, which
personally I would categorize as proof of concepts. They either lack
support for important ciphers and/or have never actually been reviewed
by experienced people within the field leaving space for all kinds of
mistakes (side channel attacks, etc.). This is a recipe for disaster.

Best regards,
Karol Babioch


--miiauounBhO7REOF115KAk8ISdIB5NMeW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTBVrHAAoJEHSaZc1HnzIVdhAP/0yxcDLdTxX1sJ0RV9c8wZ0i
t+2Db137syTww7CdmTzzE+CL/WrCmwizfnlUYecZwuJnGaOIancVmwUPMwaTVXKc
KZJhuI60WB+NGYj/Na7bkKr81wPYaADuCKeT3Mq6ERSWMNuhXzT1w6OZqAFAUl78
aj7zNslV2/voTrUntbp++xGuD0tIocwXl6bfqM3Qpr+KkDW9CR5Maq8p6rwCHEyi
H1GjauZbFlHVN8GMO8Sa011elD6WJTl90kab0sfqEgnc3fMrZwmxEoMoez/wMChW
lRc2+4RVfZ7Toyp6ly4W2wsEEPUvfcmH2QwLG9+hcrS/Bggcs73zAly9O3lk7QVR
BSWo+Auq6uk37X7atVOwHr/V3a0IOMbW/Bc35t8pervGekWIcH+aBeq/QlFRkT5Q
V4n0WMabW3SsWH6VfqDYK41psxdmfRVjS65GJv3p7lzDCcPwrqwzHGBDfRqOHhma
Aedg+gMP9D5yglV3lQB9EeUfW/FFXBGegKrlHtZMQ1zdxNZlF3W8PP6xNqVm0awI
CeyJ1qwUKW4S86o0nH7vmMyXnCuymfP7nAWHwbo9Rj0m/tAVtIc7moSV+tQTBGVu
bSIUHOXlQTaHtF2uUjImBCsE+JZjPdUAxcrDpLe9gDXouDAA/6EHE6YgviL9EBBu
xhGgMZgDsHDtSSPS27kF
=71Et
-----END PGP SIGNATURE-----

--miiauounBhO7REOF115KAk8ISdIB5NMeW--
0
Karol
2/20/2014 1:30:47 AM
[for the unabridged version, see Steve Gibson's post above]

> As it happens, I'm meeting Yubico's Stina Ehrensvard tomorrow 
> morning at 6am for coffee. She wrote a few weeks ago, saying:
> 
> "I will be in Irvine on Thursday Feb 20, and if you are 
> available I would love to catch up for a early morning coffee at 
> your local Starbucks, to discuss SQRL, FIDO and new upcoming 
> Yubico inventions."
> 
> I have no idea what's on her mind... but I am certainly curious. 
> She went completely silent after I sent her the links to those 
> first early SQRL concept pages.
> 
> What would also be interesting, since "identity" is truly her 
> personal crusade, is what, if any, effect the work on SQRL has 
> had within the FIDO community.  (As we know, FIDO is the only 
> real competition SQRL's adoption faces.)
> 
> Since Stina has always trusted me with information that I need 
> to treat confidentially, I don't know what I'll be able to 
> share, but I have planned to share what I can.  :)

Gang...

After three hours of (mostly) listening to Stina, I am unclear 
about exactly what she would and wouldn't wish me to repeat. So 
I am naturally going to err on the side of being certain not to 
betray any confidences.

But I can say that I am no longer worried --AT ALL-- about ANY 
competition to SQRL from FIDO. NO software-only solution exists, 
working or planned, within FIDO.  So nothing "FIDO" can be free. 

And there's also no hurry. We have time. The sense I got was 
that, being a large consortium of major players, each with their 
own differing agenda, the net result is every bit as lumbering 
and slow to move as one might expect. And even though the FIDO 
specs as they stand are now public, they are unfinished, and it 
is the hard parts that remain unresolved.

Secondly...

Yubico DOES want, and plans, to support SQRL.

I'm unable to say more than that.  But there is some VERY COOL 
next-generation stuff on the way... and SQRL appeared in time to 
make it onto their radar and to be incorporated into their next-
generation plans. 

So any SQRL user who wants hardware-enhanced security that no 
software-only solution can supply, WILL, it appears, be able to 
use a future Yubi-device.

We are going to need to think about and produce an "HSM" spec 
describing how a SQRL client can offload the sensitive crypto 
bits to a hardware device.  :)

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/20/2014 6:49:43 PM
[for the unabridged version, see ramriot's post above]

ramriot...

Since you've been thinking about this longer than I have, I 
can't yet offer any useful input. But my shooting from the hip 
sense is that the addition of hardware may change some of the 
tradeoffs and balances we incorporated into the current pure 
software solution. For example, the user-authentication model 
might change to "hardware + PIN".  I just don't know at this 
point.

But in any event, after my meeting with Stina, where she made it 
clear that Yubico is more than interested... this is another 
aspect that's going to need some thought. (Though I'm not going 
to let it derail my work on the UI and on getting a software-
only client running.)

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/20/2014 7:06:03 PM
[for the unabridged version, see Karol Babioch's post above]

Karol...

I believe we're beginning to see microcontroller chips that 
directly incorporate PKI-support hardware.

For example, Googling "microcontroller PKI" returns:

http://www.alcom.be/binarydata.aspx?type=doc/INSIDE_C.pdf

8/16 bit microcontroller with AES, RSA and ECC crypto 
acceleration.

And...

http://www.nxp.com/documents/short_data_sheet/A700X_FAM_SDS.pdf

"High-performance secured Public Key Infrastructure (PKI) 
coprocessor (RSA up to 2048-bit keys, ECC over GF(p) up to 320-
bit keys)"

"Secured AES coprocessor (128-, 192-and 256-bit keys)"

So... while I agree that for a general purpose microcontroller 
the task might be daunting, it's pretty clear that solutions are 
appearing for non general purpose use.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/20/2014 7:16:54 PM
On 14-02-20 01:49 PM, Steve Gibson wrote:
> [for the unabridged version, see Steve Gibson's post above]
>

> Yubico DOES want, and plans, to support SQRL.
>
> I'm unable to say more than that.  But there is some VERY COOL
> next-generation stuff on the way... and SQRL appeared in time to
> make it onto their radar and to be incorporated into their next-
> generation plans.
>
> So any SQRL user who wants hardware-enhanced security that no
> software-only solution can supply, WILL, it appears, be able to
> use a future Yubi-device.
>
> We are going to need to think about and produce an "HSM" spec
> describing how a SQRL client can offload the sensitive crypto
> bits to a hardware device.  :)
>

Thanks for the update Steve, that is good news. I hope they also plan to 
open license their solution (I certainly will see 
http://www.GRC.com/groups/sqrl:5286) so that security auditing can be 
done without need for pesky NDA's.

When you say HSM I assume you mean: 
https://en.wikipedia.org/wiki/Hardware_security_module (strangely only 
the second Google result after High School Musical).

As I am already moving in that direction, an HSM would be a good next 
move if you are willing to offload a little work I would be willing to 
put a draft together for review.

As a fist stab I do plan to fix the API boundary where I stated in my 
prior post and keep the PBKDF (EnScript) outside of the TPM to leverage 
the higher performance that will I think be a certainty there.
0
ramriot
2/20/2014 7:29:40 PM
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--gx4dtsmqLhLVDVqQ5OEUi0rGwedhruwBj
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Am 20.02.2014 20:16, schrieb Steve Gibson:
> I believe we're beginning to see microcontroller chips that=20
> directly incorporate PKI-support hardware.

Yeah, and all I wanted to accomplish with my post was for ramriot to
have an intensive look at the available variety rather than sticking to
the "known" (Arduinos, AVRs and PICs).

Best regards,
Karol Babioch



--gx4dtsmqLhLVDVqQ5OEUi0rGwedhruwBj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTBl8jAAoJEHSaZc1HnzIVDMAQAJhGYcD/ZJNJGkaTuYY1a9wp
o6DbIYenIMEQdlxF81PWsW49+vvsL2NQyO7ZZmgtvmpKK6oC0ThJi+1KaE+LfuNL
Lzo5UX2lt5IhEaVQxxW1MRb4dzzJGbS/T/q4BgGnE6MqQR9/t8ZbOgzmEz3gpogp
zrDpUsCchH+kpJowCHEiDMqLxOb+pnSAswCaW6P/bJnJF2AuVQwEGTE/WuCPakV8
cSxD9VqvYSorMUS152MYSr1qRtGdWKGYMWpv38wpGnBsMOfclLQ9CGWRP9oSw5L9
b0YzI2f7pvDE+tqWU19IbjaGQpaiHlBVpmL4WKb75MdkMcT+tBjCzwgfRX0ZdEvU
vHF9uLbe7Xoe96ieoOlwE8WncIeGiYufrakxvyVp1/pCVs/MyKNNHYp1d9hnJi0G
7FyIUClSrKlKk8Xxl6opzmMQ+XgjDM/rq6m7cKahpzOEgZ9VGDXU+KQrSLWxfK4u
Dqsybi/0Ff3AhdBNtPgORVZvZPqkeglO62sYiaM8T42PHNIAWL492aF9Fu4PKYYI
Vuqk/MRNSh0IfiIrELlut62q9UmFXsyDw8EEhFWm88gZ4mNxjUOAodNjLOVh5vKp
90wnyLyAcdaqtzUkVlERMKYGN4dyTG8hUTr7F9GR00PZqO4tnech7SHM6iE9EDp3
F0M2CymswKStXEdvHJFy
=+W84
-----END PGP SIGNATURE-----

--gx4dtsmqLhLVDVqQ5OEUi0rGwedhruwBj--
0
Karol
2/20/2014 8:01:39 PM
On 2014-02-20 11:06, Steve Gibson wrote:
[...]
> But in any event, after my meeting with Stina, where she made it
> clear that Yubico is more than interested... this is another
> aspect that's going to need some thought.

Ah, neat.

The issue with tiny dongles like the Yubikey is that they provide no 
feedback. And I'd be cautious about trusting a front-end application on 
the client computer that does too much for the dongle.

IMO, if there is going to be a sub-set of SQRL commands for 
"push-button" or screenless devices, it should probably exclude things 
like the "ASK" verb and form submission. Those are both, IMO, subsidiary 
features anyways.

Regards,
Sam
0
Sam
2/20/2014 10:20:38 PM
On 2014-02-20 11:29, ramriot wrote:
[...]
> As a fist stab I do plan to fix the API boundary where I stated in my
> prior post and keep the PBKDF (EnScript) outside of the TPM to leverage
> the higher performance that will I think be a certainty there.

I think trusting the HSM to securely store the key, unencrypted, is the 
correct approach.

Whether the HSM stores just the MK or also has something to do with the 
IUK is another question we'd have to answer.

Regards,
Sam
0
Sam
2/20/2014 10:24:46 PM
On 2014-02-20 10:49, Steve Gibson wrote:
[...]
> So any SQRL user who wants hardware-enhanced security that no
> software-only solution can supply, WILL, it appears, be able to
> use a future Yubi-device.

Ah, that is great. I wonder if this means on-chip or 
hardware-accelerated Ed25519 and Curve25519 will be a reality, or if 
that would just be "software".

Regards,
Sam
0
Sam
2/20/2014 10:26:27 PM
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Lm250FvJ4ULThIAMR5vtrXqkxUGeWp3kU
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Am 20.02.2014 23:20, schrieb Sam Schinke:
> The issue with tiny dongles like the Yubikey is that they provide no
> feedback. And I'd be cautious about trusting a front-end application on=

> the client computer that does too much for the dongle.

Well, we don't know any details yet, so we shouldn't speculate too much
about it for now. But it would be not that great of a deal to integrate
some sort of display. chipTAN devices here in Germany do have a simple
LCD display and from my understanding of the U2F documentation there are
already plans for the "next generation" devices with the capability to
sign single transactions, which probably will work quite similar.

Best regards,
Karol Babioch


--Lm250FvJ4ULThIAMR5vtrXqkxUGeWp3kU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTBo0EAAoJEHSaZc1HnzIVYpQP/2b9CIktbbJPZzarQCGDqLob
GpkZAeq+SKO0w90Ql0slo8tIJyZS189hdHTxI1YZL5B90AodFBBRQLnwNIclKMsP
snu+JcvOC3r9oATGitbLrfDuNKPYEdyAj6mhVwWh7fDR4+v+00IoR/NgiSkeIo+6
ckBEGHcApg+2JKehlSfrvLgYd8bLrPxqEPvmjuTW+BRa0or6QrdVkwbwePvmfCGX
jmA4SNidAbs9qBzpLZegPLUm5+7tYfAqatPRwfef7QUodCY9oj0UZX26XhewiQ5E
00WYAmB1E067eL1920NNZX5ZycAeUTeQ82xzLZ+/7P7Q9JoNShMd5RSUaBMrbX4u
h255ei7Hn5gUy+QfO0i5R+B/VbiV2bYthP1fn744A3pjrjF0/bDOsS15aS+zmaBY
TpGxIoiQi2Z/FpYhKr5cb/LPkGFlHUwbj9RawRFXcLMJHo7XuSWkUkktfmUHpxQT
EZMDf2FkCl29fzZ8NQWPu+vDkKQ0MZhwMHdF88kQf5Ryb/MfETJID48r8A2/pSyi
cleff1gnYQXauOFR0Emc0aINYOsKnwiDe5Cr6VFY2sQvZpnnAp7PKBYqrj0rvJYw
ogutBfltbjyjznwRcAxsP2FmeeCG7ksp4F0FVxx+3ExXwdH3zb7YUW4mBbbZzUrJ
i+ZJdXIJxiOnVb/MfhA4
=hvtn
-----END PGP SIGNATURE-----

--Lm250FvJ4ULThIAMR5vtrXqkxUGeWp3kU--
0
Karol
2/20/2014 11:17:24 PM
On 2014-02-20 15:17, Karol Babioch wrote:
> Hi,
>
> Am 20.02.2014 23:20, schrieb Sam Schinke:
>> The issue with tiny dongles like the Yubikey is that they provide no
>> feedback. And I'd be cautious about trusting a front-end application on
>> the client computer that does too much for the dongle.
>
> Well, we don't know any details yet, so we shouldn't speculate too much
> about it for now. But it would be not that great of a deal to integrate
> some sort of display. chipTAN devices here in Germany do have a simple
> LCD display and from my understanding of the U2F documentation there are
> already plans for the "next generation" devices with the capability to
> sign single transactions, which probably will work quite similar.

Right, or they could have small speakers, which might suit YubiCo's tiny 
form-factors better. I don't think you could fit much of a display on 
something like a Yubikey Nano for instance:

http://www.yubico.com/products/yubikey-hardware/yubikey-nano/

Anyways, I stand behind my comment about it being smart to be able to 
restrict the SQRL features supported by "pushbutton only" devices (This 
should be the responsibility of the device). Such a device is great for 
authenticating logins, not so great for authenticating specific details 
of financial transactions, etc.

Regards,
Sam

0
Sam
2/20/2014 11:43:25 PM
On 14-02-20 05:24 PM, Sam Schinke wrote:
> On 2014-02-20 11:29, ramriot wrote:
> [...]
>> As a fist stab I do plan to fix the API boundary where I stated in my
>> prior post and keep the PBKDF (EnScript) outside of the TPM to leverage
>> the higher performance that will I think be a certainty there.
>
> I think trusting the HSM to securely store the key, unencrypted, is the
> correct approach.
>
> Whether the HSM stores just the MK or also has something to do with the
> IUK is another question we'd have to answer.
>
> Regards,
> Sam

I think you misconstrued I am not suggesting storing any keys 
unencrypted, I am not quite that trusting in the security of the 
hardware, or even my own abilities as a programmer ;-(

I am though suggesting doing the PBKDF function outside of the module 
and the passing in the strengthened key to unlock the IUK/MK etc. This 
way a HSM would not need to have anywhere near the compute power of the 
device to which it is tethered while that is running the rest of the 
client application (PC for want of a better name).

This I think would not unduly weaken the security model. That is 
assuming we exclude real time malware attacks against the PC directly or 
the connection to the HSM where those would normally be fatal in the 
case of a software client only and expose all keys. In this case though 
a HSM it would only leak the means to do later authentication with that 
specific HSM and encrypted authentication payload.

Assuming an attacker gains possession of a HSM without also having any 
access keys they would still be limited to either, brute forcing a 
password list through our existing PBDFK function or brute forcing the 
strengthened key directly (1/2^256 probability) both to the HSM at its 
maximum API speed.

In any case I would set up the HSM API to be deliberately slowed in 
accepting commands (but still unnoticeable to a human operator) and to 
only accept a limited number of tries before taking action on further 
attempts by progressive exponential slowing perhaps or even deleting its 
encrypted payload.

This way the potential for any unprotected keys from being present in 
the ram of the HSM is limited to when a correct access passphrase is 
presented with a correctly formed API request.

API requests obviously will *not* include any means to read out 
unprotected versions of the IUK/MK but may include import and export of 
encrypted payloads containing those keys (provided the access passphrase 
is present).

Finally I think Steve's idea of a shortened passphrase being able to 
launch repeat authentications for a short period of time could still be 
accomplished by passing in the EnScrypt of the 1st N symbols of the 
passphrase on an initial SQRL request with the full EnScrypted 
passphrase and allowing the HSM to accept the reduced access key 
(possibly still using OCB encryption of the payload against the 
shortened key) for a timed period before purging the unprotected keys 
from its RAM.

Possibly also accompanied by a colour change of an external indicator 
LED to signify the weakened security state. Whereupon unplugging or 
pressing an external key could reset the state and purge the RAM.
0
ramriot
2/21/2014 12:28:34 AM
Sam Schinke was heard to say :

[...]
> Right, or they could have small speakers, which might suit YubiCo's tiny
> form-factors better. I don't think you could fit much of a display on
> something like a Yubikey Nano for instance:

Speakers? Gosh, how last century. How about a wifi web server, as tiny as it 
gets. Want to do anything, use the wifi, log in the web address, done.

-- 
Mark Cross @ 02/21/2014 12:09 a.m.
As soon as you trust yourself, you will know how to live. — Goethe

0
Mark
2/21/2014 4:11:55 AM
[for the unabridged version, see Sam Schinke's post above]

> > But in any event, after my meeting with Stina, where she made it
> > clear that Yubico is more than interested... this is another
> > aspect that's going to need some thought.

> Ah, neat.

Indeed!  The missing piece for SQRL, for those who want ultimate 
theft-proof identity security.


> The issue with tiny dongles like the Yubikey is that they
> provide no feedback. And I'd be cautious about trusting a
> front-end application on the client computer that does too
> much for the dongle.

I'm unsure that I understand what you mean, Sam. I assume that 
what we want is to treat the dongle like a black box containing 
the user's immutable identity keys. Then, since we cannot safely 
export those keys, we need to ask the black box to perform the 
key-based operations for us.

So, for example, it would sign hashes we provide it without ever 
exposing the private signing key.

So I see the implementation as... taking an existing working 
SQRL client and then optionally "subcontracting out" to system 
hardware the super-sensitive things that we cannot allow to have 
exposed.


> IMO, if there is going to be a sub-set of SQRL commands for 
> "push-button" or screenless devices, it should probably exclude
> things like the "ASK" verb and form submission. Those are both,
> IMO, subsidiary features anyways.

I don't see this being headless.  For example, the user would 
need to decide whether they still wanted to be prompted for 
their password hint. (I think they should.)

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/21/2014 5:49:59 PM
[for the unabridged version, see Mark Cross's post above]

> Sam Schinke was heard to say :

> > Right, or they could have small speakers, which might suit
> > YubiCo's tiny form-factors better. I don't think you could
> > fit much of a display on something like a Yubikey Nano for
> > instance:
> 
> Speakers? Gosh, how last century. How about a wifi web server,
> as tiny as it gets. Want to do anything, use the wifi, log in
> the web address, done.

Wow.  You guys have taken this far in another direction than
I had. (Which is not bad for brainstorming, but it's not what 
Stina or I foresaw.)

Frankly, a stand-alone device, perhaps like 'ramriot' was 
considering (?) doesn't need any Yubi-thing... since it's not 
subject to tampering in the same way that software running in
a phone or a PC is.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/21/2014 5:54:54 PM
[for the unabridged version, see Sam Schinke's post above]

> > As a fist stab I do plan to fix the API boundary where I
> > stated in my prior post and keep the PBKDF (EnScript) outside
> > of the TPM to leverage the higher performance that will I
> > think be a certainty there.

I would use the term "HSM" here because (a) that's what it is 
and (b) TPM strongly implies something that's complies 
specifically to the TPM specification.  IOW, the TPM term is 
already taken. <g>


> I think trusting the HSM to securely store the
> key, unencrypted, is the correct approach.

Exactly.  But I needs not only to store it, but also to use it, 
since we cannot allow it to be exported.  So it needs to be able 
to perform the core crypto primitives.


> Whether the HSM stores just the MK or also has something to
> do with the IUK is another question we'd have to answer.

Right.  That's what I meant by nothing that the whole idea of 
offloading SQRL's sensitive crypto work to an HSM is something 
that needs to be fully thought through.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/21/2014 6:02:24 PM
[for the unabridged version, see Sam Schinke's post above]

> > So any SQRL user who wants hardware-enhanced security that no
> > software-only solution can supply, WILL, it appears, be able to
> > use a future Yubi-device.

> Ah, that is great. I wonder if this means on-chip or hardware-
> accelerated Ed25519 and Curve25519 will be a reality, or if
> that would just be "software".

You probably saw links up-thread.  Such "crypto chips" already 
exist... natively supporting elliptic curve math in their 
hardware -- or firmware... but at least, yes, on chip.  :)

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/21/2014 6:05:09 PM
On 2014-02-21 9:49, Steve Gibson wrote:
> [for the unabridged version, see Sam Schinke's post above]
>> The issue with tiny dongles like the Yubikey is that they
>> provide no feedback. And I'd be cautious about trusting a
>> front-end application on the client computer that does too
>> much for the dongle.
>
> I'm unsure that I understand what you mean, Sam. I assume that
> what we want is to treat the dongle like a black box containing
> the user's immutable identity keys. Then, since we cannot safely
> export those keys, we need to ask the black box to perform the
> key-based operations for us.
>
> So, for example, it would sign hashes we provide it without ever
> exposing the private signing key.

Right. But if the dongle is providing "last ditch" security, and is 
being used on a compromised machine, there is absolutely no guarantee 
that what is being presented to the user via the compromised machine is 
the same as what the dongle is being asked to validate/authenticate.

If the machine says "Approve transfer of $25 to online-retailer.com" and 
you click "Yes", then click the Yubikey's activation button to complete 
the signature, what could actually be sent to the Yubikey for signing 
might be "Approve transfer of $10,000 to online-gangster.com".

OTOH, SQRL is inherently designed to be much safer than a username and 
password in situations where an adversary tricks you into logging in to 
the wrong website. Faking the system's UI up to make you think you are 
logging in to "amazon.com" while actually logging you in to a phishing 
site will require a more complex setup to try to socially-engineer other 
valuable information from a user.

> So I see the implementation as... taking an existing working
> SQRL client and then optionally "subcontracting out" to system
> hardware the super-sensitive things that we cannot allow to have
> exposed.

Right, I completely agree on that approach. With or without a 
"pushbutton" on the device, it does a much better job of protecting the 
keying material at the core of SQRL.

A dongle without a pushbutton will likely just sign/validate whatever 
the host machine presents. It will secure the keying material, but 
inserting such a dongle on a compromised machine will allow an attacker 
to authenticate arbitrary things without user feedback so long as the 
dongle is inserted.

I guess something could be designed with TOTP/HOTP/SRP on the dongle 
itself, allowing it to perform a challenge/response, but really we'd be 
getting into infinite recursion if we start down that road.

You could pre-configure and use your smartphone to answer the HOTP 
challence on your authentication dongle, so your smartphone has to be 
secure. So we're back where we started, pretty much, but with more 
moving parts that all have to work perfectly.

>> IMO, if there is going to be a sub-set of SQRL commands for
>> "push-button" or screenless devices, it should probably exclude
>> things like the "ASK" verb and form submission. Those are both,
>> IMO, subsidiary features anyways.
>
> I don't see this being headless.  For example, the user would
> need to decide whether they still wanted to be prompted for
> their password hint. (I think they should.)

My point is only that if the system is compromised, you can't really 
trust anything that might be presented on a UI on that system.

If the dongle isn't providing some kind of interface, as Karol indicates 
is possible for some form-factors, information presented by the host PC 
already depends on trusting the host PC, at which point all a dongle 
would be providing would be transience of key presence.

Regards,
Sam
0
Sam
2/21/2014 9:26:54 PM
On 2014-02-21 10:05, Steve Gibson wrote:
> [for the unabridged version, see Sam Schinke's post above]
>>> So any SQRL user who wants hardware-enhanced security that no
>>> software-only solution can supply, WILL, it appears, be able to
>>> use a future Yubi-device.
>
>> Ah, that is great. I wonder if this means on-chip or hardware-
>> accelerated Ed25519 and Curve25519 will be a reality, or if
>> that would just be "software".
>
> You probably saw links up-thread.  Such "crypto chips" already
> exist... natively supporting elliptic curve math in their
> hardware -- or firmware... but at least, yes, on chip.  :)

Right, but I would expect those chips to support specific ECC suites 
and/or specific curves. I saw one of them supports ECIES for instance, 
which is a pretty specific creature, and much mention of ECDSA. But no 
mention of Ed25519, Curve25519 or EdDSA.

Anyways, it could be a completely wasted concern -- hardware designed 
for current ECC algorithms and ECDSA might be perfectly capable of 
handling Ed25519 and Curve25519 with only software tweaks.

Regards,
Sam
0
Sam
2/21/2014 9:32:51 PM
[for the unabridged version, see Sam Schinke's post above]

Ah, yes.  I see what you and Karol are referring to.

Moving the critical crypto into the dongle provides ABSOLUTE 
protection from the user's credentials being exfiltrated...
but not necessarily from them being used in place.

I do expect that it would continue to have a "touch to do" 
button, so that helps a bit... though we would always have
"the malware in the middle" problem of malware intercepting
our use of the HSM and using it for its own purposes.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/21/2014 9:38:34 PM
[for the unabridged version, see Sam Schinke's post above]

> Right, but I would expect those chips to support specific ECC
> suites and/or specific curves. I saw one of them supports ECIES
> for instance, which is a pretty specific creature, and much
> mention of ECDSA. But no mention of Ed25519, Curve25519 or EdDSA.
> 
> Anyways, it could be a completely wasted concern -- hardware
> designed for current ECC algorithms and ECDSA might be perfectly
> capable of handling Ed25519 and Curve25519 with only software
> tweaks.

Stina wasn't able to commit, and I didn't push, of course. But 
the STRONG sense I got was that Yubico expects SQRL to succeed 
in the industry and that they have already looked closely at 
SQRL's crypto and HAVE found a feasible and inexpensive solution 
for a SQRL HSM... and she did mention specifically for SQRL's 
specific elliptic curve choices.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/21/2014 9:55:48 PM
On 2014-02-21 13:38, Steve Gibson wrote:
> [for the unabridged version, see Sam Schinke's post above]
>
> Ah, yes.  I see what you and Karol are referring to.
>
> Moving the critical crypto into the dongle provides ABSOLUTE
> protection from the user's credentials being exfiltrated...
> but not necessarily from them being used in place.
>
> I do expect that it would continue to have a "touch to do"
> button, so that helps a bit... though we would always have
> "the malware in the middle" problem of malware intercepting
> our use of the HSM and using it for its own purposes.

Right. It is still a *vast* improvement.

I think the Yubikey does support a couple of interactions with the 
single button. Short press, long press, double press or something like that.

So perhaps an option would be one interaction for use on a trusted 
machine (ie, one you'd normally trust to do banking) and another 
interaction on a less trusted machine -- one you might login to an 
account, but wouldn't approve any ASK-related transactions on.

Short press = Login
Long press = Sign supplemental ASK request

I don't know, that does seem like it is getting to be complex for such a 
simple device. A user whose home machine is infected without their 
knowledge will not be helped much, either. And a "super secure" dongle 
that does less than a merely "secure" encrypted file won't see adoption.

Regards,
Sam
0
Sam
2/21/2014 10:45:34 PM
On 14-02-21 05:45 PM, Sam Schinke wrote:
> On 2014-02-21 13:38, Steve Gibson wrote:
> So perhaps an option would be one interaction for use on a trusted
> machine (ie, one you'd normally trust to do banking) and another
> interaction on a less trusted machine -- one you might login to an
> account, but wouldn't approve any ASK-related transactions on.
>
> Short press = Login
> Long press = Sign supplemental ASK request
>

I was going to ask here as to the necessity of having a button at all, 
But having reread the earlier posts I can see how it may prove useful in 
preventing malware from performing an SQRL authentication outside of 
user control.

Certainly an interesting addition to the security model, it would though 
only work if the button were to be pressed to initiate each of the HSM's 
loop responses.

For example, the following interaction model would seem the logical way 
to go:-

User: plugs in / tethers HSM
User: launches client from SQRL:QR/URL
Client: asks user for client access passphrase
User: Types in same
Client: sends API query with Enscrypted version of passphrase to HSM
HSM: unlocks stored keys, generates authentication request and sets 
device LED to flashing RED.
User: Clicks on HSM to prove human presence
HSM: set LED to GREEN flashing, passes request blob to client with API.
Client: Sends out authentication request loop one transmit.
Client: Receives Loop 1 response, breaks out server ID and display, make 
API call to HSM with EnScrypted passphrase again for loop Two transmit 
stuff.
HSM: generates loop Two transmit, set LED to RED Solid.
User: Checks that screen matches expectation, Click on HSM button again.
HSM: set LED to green solid and passes loop two transit blob to client.
Client: sent out loop two transmit.
Client: loop Two response (Authenticated), display same and redirect 
user to browser.

Finally it is noted that if device in which you run the client has 
malware that can gain control over the client, then it is just as likely 
for the client APP to show the user one thing on the client display 
while the HSM is presented with an entirely different set of credentials 
or even site SQRL:URL.

That could only be prevented if the HSM had its own display and possibly 
even its own keyboard, one option I may consider exploring. I already 
have a 32 Char 2 line I2C LCD with a 5 button keyboard tied to one of my 
arduino devices, it is presently acting as an OATH token.
0
ramriot
2/23/2014 4:44:29 AM
Reply:

Similar Artilces:

[UI] the benchmark progress bar...
could change color when the test is done (it could go from grey before the test, to blue during the test, and grey again when the test is finished). Philippe > could change color when the test is done (it could go from > grey before the test, to blue during the test, and grey again > when the test is finished). I suppose it's just a personal taste thing... but I like the bar showing how much of the most recent test was completed. Since it can be stopped part way through, and the data is correct up to that point, the bar serves to give a visual indication of th...

Printing, progress bars, and UI responsiveness
Bug 650960 proposes to remove the progress bars for printing and print previewing. In the former case, what the user cares about is the time till the printer is actually done, which we have no visibility into; in the latter case, it should go fast enough to be unnecessary. However, since the DOM is single-threaded, I'm worried that the UI might freeze up for quite some time if you're trying to print a large file; right now at least you have a progress bar so you can tell that the browser's doing *something*. It is already possible to *disable* the progress bars v...

Adjust UI fonts from the UI
You are never going to please all people in all environments with the UI font defaults you choose. Adjusting the UI fonts via editing userChrome.css is a hassle. Please consider adding a font chooser in the browser, mail client, and irc client that would let you toggle the fonts ( and without rebooting ). Thanks Steve I demand that Steve may or may not have written... > You are never going to please all people in all environments with the UI > font defaults you choose. > Adjusting the UI fonts via editing userChrome.css is a hassle. And here's me editing...

XML UI Language only for UI
Hi, I dont know how many of you find this stupid, but i really want to know. XUL stands for XML UI Language it can be used to develop UI easily and fast. Events can be handled using JavaScript. Most of the time we find situations where scripting language cannot be used, we may require serious programing where we may need a real complex compiled code like C++ or Java. Is it possible to use the UI capability of XUL and programming concepts of other languages. XUL as far as i know provides a platform independent UI components and Java provides platform independent code can we co...

Progress
http://news.yahoo.com/s/livescience/20090326/sc_livescience/youpaycomputerpraysforyou;_ylt=AqPdmBpMdTTBGWLprKJf8Kes0NUE;_ylu=X3oDMTM1cDI2b2pxBGFzc2V0A2xpdmVzY2llbmNlLzIwMDkwMzI2L3lvdXBheWNvbXB1dGVycHJheXNmb3J5b3UEY3BvcwMxMARwb3MDMTgEc2VjA3luX3RvcF9zdG9yeQRzbGsDeW91cGF5Y29tcHV0 <quote> Information Age Prayer is a site that charges you a monthly fee to say prayers for you. A typical charge is $4.95 per month to say three prayers specified by you each day. "We use state of the art text to speech synthesizers to voice each prayer at a volume and speed equivalent to typica...

Progress
Can I create proxy tables on ASE to a remote Progress database? I tried to find some info about ASE and Progress and get none. Or is there another way? Thanks. ASE interacts with foreign databases through a mediation layer that we call a 'Direct Connect', which is an Open Server process. In the open server, DBMS- specific interfaces are used to mediate between ASE/CIS and the foreign DBMS. Currently, we have no Direct Connect for Progress. However, there is another way: ASA also contains the CIS layer, and uses ODBC to interact with foreign databases. Therefo...

UI
Name: B. Adji Maharyatno Email: maharyatno_at_gmail.com Product: Firefox 2 Beta 2 Summary: UI Comments: I like UI in beta 1 as similar to common Firefox (pre 2). Beta 2 UI is strange and not all work correctly. The navigation buttons are cleaner in previous version. Browser Details: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1b2) Gecko/20060821 Firefox/2.0b2 ...

Progress
I know Steve does not like deadlines, but am I the only one that is beginning to doubt whether or not the DNS Benchmark utility will ever be finished. Last I heard, Steve was working on the "dreaded documentation." Steve has mentioned that he does not like doing the documentation and I know that I tend to procrastinate when it comes to doing the things that I don't like doing. Combining Steve's apparent disdain for documentation with his insistence upon maintaining complete control over every aspect of his projects, I am seriously beginning to doubt whether the DNS...

UI
 I have searched code for UI designing and got the below code in .js extension file..var arrowimages={down:['downarrowclass', 'down.gif', 23], right:['rightarrowclass', 'right.gif']}var jqueryslidemenu={animateduration: {over: 500, out:200}, //duration of slide in/ out animation, in millisecondsbuildmenu:function(menuid, arrowsvar){    jQuery(document).ready(function($){        var $mainmenu=$("#"+menuid+">ul")        var $headers=$mainmenu.find("ul"...

UI
Name: Gregory Kornblum Email: tensailabsattensailabsdotcom Product: Firefox Summary: UI Comments: I am a die hard Chrome user and fan of Safari for following in its footsteps regarding UI. Yes, there are themes that try to emulate this but are still far from being close due to the inherent restrictions. Love the work on implementing the emerging HTML5 standards but if you could get the minimal UI going you would then have the perfect browser. Browser Details: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1) Gecko/20090616 Firefox/3.5 From URL: http://hendrix.mozil...

Progress
OK I did a iprntcfg trace and it produced a traceerr.txt file the first two entries covers the errors: 9/20/2005 - 12:57:32 PM Module: spoolsv.exe Trace Info: myhttp.c, line 1747, thread 000006B8 Routine: HTTPReadResponseHeader - bad HTTP status (401) Error: HTTP 401 - Unauthorized. 9/20/2005 - 12:57:32 PM Module: spoolsv.exe Trace Info: registry.c, line 5577, thread 000006B8 Routine: GetUserPasswordCache - RegQueryValueEx failed 2 Error: The system cannot find the file specified. not giving me where this is corrected. Any ideas? This is the ...

Progress
Name: Rui Mota Product: Firefox Summary: Progress Comments: I have been using Firefox for many years now. One problem was the amount of CPU resources it used. This could nearly or totally halt the computer and often crash itself. The more tabs open the more this happened. Now, with Windows 7 it is completely different. We can have many tabs and some windows open with very low resources use. Congratulations and keep going the same way you always have. Rui Mota Browser Details: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET...

PROGRESS
------=_NextPart_000_0201_01C0C1EF.7E733D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I saw in a mensage posted here about 4 months ago that the module = DBD::PROGRESS have the development discontinued. I need to connect to the PROGRESS database by an Web application, and I = had hope to use some DBD, now I am looking at the JDBC, PHP or other = thinks... Do anyone have experience with PROGRESS -> PERL talking ? Thanks Slepetys ------=_NextPart_000_0201_01C0C1EF.7E733D80-- Roberto, It was my message. Li...

Web.UI vs Sys.UI
Newbie Q. I've been trying to find a working example of the FadeAnimation, but the only ones I've find use the Web.UI namespace. How old are these and was the namespace the only difference wrt FadeAnimation? Hi,if you post the code I can help you to convert it to the latest CTP, where the Web namespace has been renamed to Sys (and, for example, the targetElement attribute has been removed). Alessandro Gallo | Blog | My book: ASP.NET AJAX In Action Thanks <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DT...

Web resources about - UI Progress - grc.sqrl


Emery County Progress - Emery County, Utah
Emery County Progress, Serving Emery County, Utah news since 1900

The Progress
Boro: Paving bid could be good news Friday, June 19, 2015 By Jeff Corcino Staff Writer Clearfield Borough received some potentially good news ...

March of Progress (album) - Wikipedia, the free encyclopedia
March of Progress is the ninth studio album (and sixteenth overall) by progressive metal band Threshold . It is the first studio album on which ...

WA bushfires: Esperance bushfire warning downgraded as firefighters make progress
A deadly bushfire burning in areas north of Esperance on WA's south coast is downgraded back to a watch and act.

Put your nose to your phone in the puzzler Progress to 100
If you are looking for a brand new puzzle game concept, then Progress to 100 is it. This innovative game will put you closer to your iPhone than ...

2017 Lincoln MKZ shows the new face of progress
Filed under: Design/Style , 2015 LA Auto Show , Lincoln , Sedan , Luxury Lincoln makes a plethora of upgrades to the refreshed 2017 MKZ including ...

Progress report on Jeanne Gang's notable projects
The current projects of Chicago architect Jeanne Gang span the gamut from skyscrapers to cultural centers to museums. Here is a Gang sampler. ...

Pfizer-Allergan talks progress: Sources
Deal talks between Pfizer and Allergan have progressed and an agreement may come as early as next week, sources told CNBC.

Rainbow Six Siege beta progress won't carry forward
Plus, Ubisoft confirms people who were in the closed beta will get to play 24 hours early.

Resources last updated: 11/25/2015 5:06:00 PM