How many bits?

Gang...

So we are encrypting SQRL's master Identity Unlock Key (IUK) 
with a system-chosen, maximum-entropy, Emergency Code (EC)
which is salted as it runs through an adaptive EnScryption so 
that its first generation requires a few seconds to complete...

How much entropy do we need that EC to carry?

Keep in mind that:

1. Making the EnScrypt iteration count adaptive future-proofs 
the system against surprising increases in processing power.

2. Longer codes, while more secure, are user-hostile and more 
prone to entry error.

3. Allowing the encrypted IUK to remain in the SQRL clients 
means that we really DO need to keep them well protected... 
which longer codes do better.

4. The user will almost never need to enter these codes. They 
truly are "emergency codes". (This argues, I think, for longer 
and more secure codes.)

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

Consider these:

gwiv whuk devy = 56.405 bits (9.5x10^16)

3684 6024 6268 3012 5835 = 66.438 bits (10^20)

duxw korn yqxy lops ehwu = 94 bits (2x10^28)

3735 2747 2594 2740 4712 5832 3892 = 93 bits (10^28)

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

I think that grouping in sets of four is clearly the right thing 
to do.

And Terry's argument favoring simple numeric digits is 
interesting.  I am gravitating toward the inherent simplicity
of smaller character sets. First it was favoring simple 
lowercase alpha over mixed case alphanumeric. But now I'm 
looking at simple digits. Consider that second line:

3684 6024 6268 3012 5835 = 66.438 bits (10^20)

.... is both a lot of security, and VERY easy on the eyes.

And if we were to stay with digits, but add ONE more group:

4649 7294 0572 6382 1739 6453 = 79.726 bits (10^24)

Your thoughts??

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

59 Replies
442 Views

Similar Articles

[PageSpeed] 19

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

Hi,

Am 12.02.2014 19:15, schrieb Steve Gibson:
> Consider that second line:
>=20
> 3684 6024 6268 3012 5835 =3D 66.438 bits (10^20)
>=20
> ... is both a lot of security, and VERY easy on the eyes.

somehow I'm not convinced that 66 bits are appropriate in this day and
age. Remember the DES folks were laughed at a key space of 64 bits even
back in the day. Granted, EnScrypt slows things down CONSIDERABLY, but
my gut feeling still tells me to increase this as much as reasonable
possible.

> Your thoughts??

Personally, I kind of like Crockford's Base32 scheme (and/or similar
ones). It is case insensitive (good for mobile devices) and doesn't
contain any problematic (i, l, o) characters while still providing a
character set of 32. At least Mark Cross and I agreed upon the fact that
case insensitivity makes a lot of sense [1].

In regards to the length and/or grouping: Google for instance uses 4
groups of 4 (all lowercase) when generating application specific
passwords. This is quite convenient to the user, and is probably good
enough for any sort of online attack.

SQRL on the other hand (or at least the aspect we are talking about here
right now) needs to withstand offline attacks (slowed down by EnScrypt).
Therefore I would like to propose a string with a grouping of 5x5. The
appropriate key space would then be 125 bits wide, which is good enough
in my perception.

Furthermore, as we are talking about the emergency code here: By its
very definition it is not used very often. I don't think its a problem
for the user to enter a more lengthy string in these rare cases. It is
not meant to be memorized so whether I'm typing out 12, 16, 20 or 25
characters doesn't make any difference - at least to me.

Best regards,
Karol Babioch

[1]: https://www.grc.com/groups/sqrl:5083


--9ahApBQG2NWF0MNpn6X3rukhfirxanajl
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+92hAAoJEHSaZc1HnzIVkm4P/3+P9/VK7Jbqj9R3kwbaIyPB
GaA0aJhQuMZaQUAcr+oU+kqdEesYVcI5bvJnBsKruTFhue7EG9IR0c6+iHxVbVY4
sl/shetQTdMMMYrAjzsfj1IJ/DLzgExjQBFP0HTBFrXucFDgYEqXoTYShZm9NJdq
BzMORPsrnv8rtsXeolDFo7OuONjJphzyxxG7yspI5DAdX6eEw/kwlevcjEscPTe6
gO6J4Xt0r7/hXrzUQJ1wJ/NsPxPgI+jpTVx5A3JsTAWgZgcPCj34mOLPES2Bshur
V5iopMGj88HpKJ19fvvN0ZCknZKlh6PLqS1HW/zVuCeOcGBNt2sgi8ySKSvAJRJU
gbLaGOoW4vEX6ccyldkDNKaGzpYQdVAvO/LZJFaC3fRrjm1FADk8s27CzOcA4zhn
oVT7SYunzyf/aKMD6tCm+u2JAzOzWWkznDa4Dyo4saoeZ5SotO7sOjUvIFHJpSpv
EgpF+7LUTuRzhbovJ7E1ACm8BiEaEtWy0N/L2BNS9Lc+fLBPBOWq89LYYVYZHUrq
8+ZdbWTxfcNNMSbqmkYCyAfn01kZidPxBYLMtyDPvL5DbFi3yEOXpMjt13qCWWPS
2uKnZjSgRnUJxSxqFo6zWaWZ7BaUv4ldfDzMQD5X/9sYef0bOZVuHNdL76+FodRX
jxUMb6iBtWitF//1F2Gc
=RJ1B
-----END PGP SIGNATURE-----

--9ahApBQG2NWF0MNpn6X3rukhfirxanajl--
0
Karol
2/12/2014 8:46:25 PM
On 2/12/2014 1:15 PM, Steve Gibson wrote:
> How much entropy do we need that EC to carry?
> 
> Keep in mind that:
> 
> 1. Making the EnScrypt iteration count adaptive future-proofs 
> the system against surprising increases in processing power.

EnScrypt is a powerful PBKDF, but a "surprising" increase in processing
power may stress systems other than our strengthened EC.  At some point
we're battling the wrong foe.  We should definitely use an adaptive
EnScrypt scheme, but it will likely be of limited use against a dragon
we can't yet imagine.  Swords are no more use here!

> 2. Longer codes, while more secure, are user-hostile and more 
> prone to entry error.

Output error is far more of a problem than entry error, so I think we
still need the user to confirm the EC during setup.  But if we cannot
force an entire backup, what good is the EC?

> 3. Allowing the encrypted IUK to remain in the SQRL clients 
> means that we really DO need to keep them well protected... 
> which longer codes do better.

And I like this development from a user perspective, but I still don't
feel right about it...  I didn't like the old way of breaking the backup
into asymmetric pieces, but now we're not even forcing the user to
backup their identity.  I don't have a solution; just nagging doubts *g*.

> 4. The user will almost never need to enter these codes. They 
> truly are "emergency codes". (This argues, I think, for longer 
> and more secure codes.)

And I've kept this point in mind while glossing over it in my posts on
the subject, as I tend to fall into the devil's advocate role in these
discussions *g*.  Even if we choose an "overkill" EC bit-size, the
ramifications are not severe and users will simply live with it.  I
can't imagine that someone would go through the process of establishing
a SQRL identity and then abandon the entire concept just because the
Emergency Code contained 4 more letters or numbers than they felt
comfortable with.  This is no reason to abandon reason, however.

duxw korn ygxy lops = 75 bits (4.5x10^22) = 1,440,000 years at 1 Billion
guesses per second (Bg/s)

My personal preference is the above 4x4 string.  I would like S/KEY or
Diceware strings even more, but I don't think the benefit is worth the
cost of implementing such a complex system in the client.  KISS.

We need people with more expertise than I to determine what a realistic
threat might be.  I'm simply making gut assumptions, which aren't truly
helpful.  I think that 1 billion guesses per second is simply
unimaginable even allowing for tremendous Scrypt speed increases.
However, perhaps this is a target that everyone will agree is high enough?

> I think that grouping in sets of four is clearly the right thing 
> to do.

Yes!  Grouping is key to working with short term memory for recording,
entry, and double-checking at a glance.

> And Terry's argument favoring simple numeric digits is 
> interesting.  I am gravitating toward the inherent simplicity
> of smaller character sets. First it was favoring simple 
> lowercase alpha over mixed case alphanumeric. But now I'm 
> looking at simple digits. Consider that second line:
> 
> 3684 6024 6268 3012 5835 = 66.438 bits (10^20)

66.438 bits = 3,533 years at 1Bg/s

My preferred balance between usability and strength lies in this region,
because I feel that more than 4 or 5 groups is cumbersome.  Just as we
can get lost if there are too many non-contextual characters in a row,
we tend to also get lost if there are too many non-contextual character
/groups/ in a row.  It's a scalar function, IMO.

People are quite accustomed to 4x4 credit card numbers and some software
license codes are 4x5, so people can handle these strings relatively well.

> And if we were to stay with digits, but add ONE more group:
> 
> 4649 7294 0572 6382 1739 6453 = 79.726 bits (10^24)

79 bits = 35,300,000 years at 1Bg/s = 353 years at 1 Trillion g/s

It seems to me that anything over 64 bits is strong enough to resist
conceivable attack, but it's not a deal killer if people insist on
increasing that somewhat.  Surely we can agree that anything over 90-ish
bits is just a waste, though.

-- 

 RobAllen
_____________________________________________________
0
RobAllen
2/12/2014 8:59:05 PM
In grc.sqrl, Steve Gibson wrote ...

> And if we were to stay with digits, but add ONE more group:
> 
> 4649 7294 0572 6382 1739 6453 = 79.726 bits (10^24)
> 
> Your thoughts??

I think this one strikes a good balance.  People in this group 
can adapt to about anything, but mainstream users like familiar 
things.  As noted, that looks like an extended credit card 
number.

-- 
Terry //
0
Terry
2/12/2014 11:27:09 PM
On 2014-02-12 10:15, Steve Gibson wrote:
[...]
> And if we were to stay with digits, but add ONE more group:
>
> 4649 7294 0572 6382 1739 6453 = 79.726 bits (10^24)

I would vote for making the number of digits irrelevant by offering to 
export the "Emergency Code" graphically, as a QR code with the 
digits/letters/words printed below for the odd time where something to 
read QR codes is unavailable.

We are already exporting SQRL identities as QR codes, so the capability 
to both export and import said codes must already be a given. Entering 
manually is just a fall-back option.

That said, a slowdown via Scrypt to ~1 second of calculation (on today's 
CPU's) is only going to be a factor of 10-12 or so compared SHA-1/MD5 
brute-forcing. We could also try to compare to naked key brute-forcing, 
for which we'd need to benchmark OCB's decrypt and verify, as decrypting 
using successive keys is also a valid attack.

Rather than working *upwards* to "how strong do we want the password to 
be", I think we ought to work backwards from how strong the cipher's key is.

If we benchmark how many decrypt-and-verify OCB cycles can be performed 
in a second and compare this to the time allocated to SCrypt, we should 
get a workable slowdown ratio. Though in that instance we'd need to also 
make sure that what we are encrypting with OCB is utterly non-verifiable 
until decryption is complete, or that verifying via OCB is at least as 
fast as verifying by generating and comparing an exemplar public key.

As an arbitrarily chosen for instance: If the cipher is 128 bits, and 
our use of SCrypt provides a 1:2^20 slowdown ratio to search the 
"emergency code" keyspace compared to searching the cipher's keyspace 
directly, then our emergency code should be ~108 bits. I wouldn't expect 
the ratio of SCrypt's slowdown to change hugely in the future -- if 
someone can speed up SCrypt by 100%, it stands to reason that they can 
probably also speed up their other brute-force strategies by at least as 
much.

If we calculate any other way (eg, how many years of brute force at a 
given speed a given password can withstand), we are saying that the 
choice we have made for cipher strength isn't something that we really 
respect. IMO, all parts of the system should be set to approximately the 
same theoretical strength.

Sure, with those hypotetical numbers, above, we'll still only be using 
108 bits of the cipher's total key-space, but if SCrypt is a secure 
hashing algorithm, those bits will be randomly distributed, and an 
attacker would have to be able to predict SCrypt's possible outputs for 
a given set of inputs to reduce their key-space.

Using less key-space does allow a time-memory tradeoff, so we do want to 
be careful about making our SCrypt slowdown ratio so high that we are 
tempted to make the space used for the passwords small enough that it 
could conceivably be compiled into a rainbow table. If we get into that 
territory, salting is a must, IMO.

Regards,
Sam
0
Sam
2/12/2014 11:28:07 PM
Steve Gibson wrote:
>
> 4. The user will almost never need to enter these codes. They
> truly are "emergency codes". (This argues, I think, for longer
> and more secure codes.)
>

The frequency of use is probably similar to the number of times that one 
installs Windows. MS seem happy with 5 x 5, albeit reduced alpha numeric, 
and no-one complains. Indeed, if you have to resort to activation by phone, 
you get 8 x 6 numeric.

If we are only talking of once every 2-3 years, why not keep it long.

AlanD

0
AlanD
2/13/2014 12:15:00 AM
On 2014-02-12 12:46, Karol Babioch wrote:
> Am 12.02.2014 19:15, schrieb Steve Gibson:
>> Consider that second line:
>>
>> 3684 6024 6268 3012 5835 = 66.438 bits (10^20)
>>
>> ... is both a lot of security, and VERY easy on the eyes.
>
> somehow I'm not convinced that 66 bits are appropriate in this day and
> age. Remember the DES folks were laughed at a key space of 64 bits even
> back in the day. Granted, EnScrypt slows things down CONSIDERABLY, but
> my gut feeling still tells me to increase this as much as reasonable
> possible.
>
>> Your thoughts??
>
> Personally, I kind of like Crockford's Base32 scheme (and/or similar
> ones). It is case insensitive (good for mobile devices) and doesn't
> contain any problematic (i, l, o) characters while still providing a
> character set of 32. At least Mark Cross and I agreed upon the fact that
> case insensitivity makes a lot of sense [1].

Once you go all lower case, most problem letters disappear, too. The 
only ones that can be problematic in lower case are i and j in 
particularly poor fonts. Well, I have seen poorly kerned fonts where 
some sequences of r,n,m can be tricky.

There are also fonts that are better for this kind of thing.

I think for convenience of entry, lower case letters is best. On an 
"entropy per key-press", the shift-key is only worth a single bit at best.

Whether we use a word-based scheme of some sort (diceware, S/KEY) or not 
isn't a big worry for me. Words only really help when a predictive 
keyboard is involved -- and even those usually don't try to autocorrect 
inside "password" fields.

Regards,
Sam
0
Sam
2/13/2014 1:31:35 AM
[for the unabridged version, see Sam Schinke's post above]

> Once you go all lower case, most problem letters disappear,
> too. The only ones that can be problematic in lower case are
> i and j in particularly poor fonts. Well, I have seen poorly
> kerned fonts where some sequences of r,n,m can be tricky.

Yeah... when 'r' butts up against 'n' it can easily look like
an 'm'.  Definitely seen that.


> There are also fonts that are better for this kind of thing.

Yep. FWIW, I expect to specify and use the classic "courier" 
font which is very clear and legible.


> I think for convenience of entry, lower case letters is best.

Right. It was fun to  hear Leo loudly interrupt me yesterday 
when I mentioned that intent on the podcast.  He said "Thank 
You!" before I even had the sentence out.  <g>


> On an "entropy per key-press", the shift-key is only worth
> a single bit at best.

Yes, I think that's a brilliant and relevant way of phrasing
and thinking about it.


> Whether we use a word-based scheme of some sort (diceware,
> S/KEY) or not isn't a big worry for me. Words only really
> help when a predictive keyboard is involved -- and even those
> usually don't try to autocorrect inside "password" fields.

.... and my own problem with it is that there's really not much 
entropy in the solution.  The math makes it clear that for any 
number of letters, restricting them to well known words discards 
the huge majority of combinations that are not words.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/13/2014 2:34:54 AM
On 2/12/2014 1:15 PM, Steve Gibson wrote:
> How much entropy do we need that EC to carry?
>
> Your thoughts??

Here is how I see this playing out for myself. I install the SQRL app on
my computer and go through its normal setup. At the end, it tells me to
write down a super secret code. I do what I always do and add it to my
KeePass database.

I also help my grandma with her computer and here is how I see that
playing out. I help her install the SQRL app on her computer. It the
end, it tells me to write down a super secret code. I write it down and
tell my grandma to keep it safe. In a year or 2 when something happens
that makes us need the password it is buried and gone. I end up figuring
out how to manually re-gain access to her accounts, etc.

I don't want to be too much of a downer, but in both of these cases, the
bits of entropy simply didn't matter. People very rarely treat anything
password related as super special. Everyone has gotten conditioned that
they can reset password if they call the right person and ask really
nicely that even the biggest scariest dialog box won't convince them
otherwise. As a techie, I acknowledge that new technologies such as SQRL
and Bitcoin require the end user to take complete responsibility for
their digital identity, but I'm not sure if the world is ready.

Back to the original question. I want a password to be able to withstand
the following attack.
Average computer guesses per second
*10000 (Efficiency gained by specialized hardware)
*1000000 (Devices I assume that an NSA level attacker can make)
*10 (NSA level attacker optimized guessing algorithm)
*60 (sec per min)
*60 (min per hour)
*24 (hour per day)
*365 (day per year)
*1000 (years I want an attack to take)
=3.15*10^21 (Guesses I want an attacker to have to take)

These numbers are all just rough and pulled out of the air. My whole
idea is the the number of bits doesn't matter because it scale with the
number "Average computer guesses per second". If we were just using
SHA-256, I would want a lot more bits because it is so much faster than
EcScrypt.
0
PRabahy
2/13/2014 4:42:14 AM
On 2014-02-12 10:15, Steve Gibson wrote:
[...]
> 1. Making the EnScrypt iteration count adaptive future-proofs
> the system against surprising increases in processing power.

Being adaptive today won't help today's SQRL identity blocks against 
tomorrow's attackers. It *will* help tomorrow's SQRL identity blocks 
against tomorrow's attackers, however.

I think it is a distinction worth making. As such, we should probably be 
considering some minimum iteration count -- sufficiently slow 
last-generation hardware might have to tolerate a few seconds delay to 
attain a reasonable degree of protection.

I *think* calibrating the minimum additional delay to the speed 
achievable for AES/OCB on a given piece of hardware may be reasonable 
(IE, SCrypt iterations equal to 10^10 times the time needed to OCB 
decrypt). Though perhaps not -- AES is now relatively commonly 
accelerated in hardware, which might lead to un-necessarily weak use of 
SCrypt. Thoughts?

Regards,
Sam
0
Sam
2/13/2014 5:11:24 AM
On 2014-02-12 18:34, Steve Gibson wrote:
[...]
>> Whether we use a word-based scheme of some sort (diceware,
>> S/KEY) or not isn't a big worry for me. Words only really
>> help when a predictive keyboard is involved -- and even those
>> usually don't try to autocorrect inside "password" fields.
>
> .... and my own problem with it is that there's really not much
> entropy in the solution.  The math makes it clear that for any
> number of letters, restricting them to well known words discards
> the huge majority of combinations that are not words.

Right, but the entropy is still precisely calculable. And "not much" is 
relative -- the entropy in a 5-word diceware phrase is very close to the 
5-word decimal phrase you proposed (64 vs 66).

Diceware, using the default dictionary, provides exactly 12.9 bits of 
entropy per word, for instance, and S/KEY provides 64 bits per 6-word 
phrase.

The lengths of the words in both S/KEY and diceware are quite short.

I think that given that memorability is specifically *not* a concern or 
goal for the emergency code that ease of entry for a given length is the 
only variable worth worrying about. If words are sufficiently easier to 
enter than randomish alphabetic strings, they'd get my vote.

Regards,
Sam
0
Sam
2/13/2014 5:18:27 AM
In grc.sqrl, Sam Schinke wrote ...

> The lengths of the words in both S/KEY and diceware are quite short.
> 
> I think that given that memorability is specifically *not* a concern or 
> goal for the emergency code that ease of entry for a given length is the 
> only variable worth worrying about. If words are sufficiently easier to 
> enter than randomish alphabetic strings, they'd get my vote.

Words would only be potentially easier if the user is familiar 
with the language.

For alphabetic strings the user would need at least some 
familiarity with the alphabet, the most popular alphabet is 
Latin.

For numerical strings the user would need some familiarity with 
the decimal digits 0 through 9, which is almost universal across 
languages.

I'm torn between the simplicity of both lowercase alphabet and 
numbers.

I like lowercase for the higher bits-per-character and the 
secretiveness of the random letter combinations.

I like numbers for the universality and latent power.

I'm glad I don't have to decide.  <g>

-- 
Terry //
0
Terry
2/13/2014 7:17:43 AM
On 2014-02-12 23:17, Terry L. Webb wrote:
[...]
> I like lowercase for the higher bits-per-character and the
> secretiveness of the random letter combinations.
>
> I like numbers for the universality and latent power.

Right, though some mobile keyboards aren't fantastic for entering 
numbers unless asked to enter a special number-entry mode.

> I'm glad I don't have to decide.  <g>

One possibility would be if the access code format we agree on is 
actually an encoding of some binary value would be to just let the user 
choose between a couple representations of exactly the same binary 
value. Whatever the user prefers would work fine. This isn't an approach 
I am really a fan of though -- hashing/stretching ascii input values is 
a time-honored and *very* simple approach (though perhaps someone more 
familiar with unicode could weigh in with a countervailing opinion here)

Or alternately, let the user choose the format and *then* generate the 
code and encrypt the IUK.

Using different alphabets for internationalization might be worth 
considering, but folks much more familiar with how those alphabets work 
would have to be deeply involved there. Actually, on that front, going 
for a pure QR-code output of the emergency code seems like a better idea 
-- there isn't much ambiguity possible in re-scanning a QR code.

Regards,
Sam
0
Sam
2/13/2014 9:09:47 AM
In article <ldh01p$fqs$1@news.grc.com>, sschinke@gmail.com says...
> 
NIP
> I would vote for making the number of digits irrelevant by offering to 
> export the "Emergency Code" graphically, as a QR code with the 
> digits/letters/words printed below for the odd time where something to 
> read QR codes is unavailable.

> We are already exporting SQRL identities as QR codes, so the capability 
> to both export and import said codes must already be a given. Entering 
> manually is just a fall-back option.

SNIP

You appear to be forgetting the users who will be using dektops without 
the ability to read QR codes.

I VOTE AGAINST this degradation to mobile devices only SQRL must be 
usable on all devices or it will never get acceptance.

-- 
Alan Cameron
0
Alan
2/13/2014 2:57:03 PM
[for the unabridged version, see Sam Schinke's post above]

> > 4649 7294 0572 6382 1739 6453 = 79.726 bits (10^24)

> I would vote for making the number of digits irrelevant by
> offering to export the "Emergency Code" graphically, as a
> QR code with the digits/letters/words printed below for the
> odd time where something to read QR codes is unavailable.
> 
> We are already exporting SQRL identities as QR codes, so the
> capability to both export and import said codes must already
> be a given. Entering manually is just a fall-back option.

We went around and around about this, triggered on Feb 4th by 
John Milburn who posed the question of exporting these secrets 
from his mobile device -- where plenty of entropy was available 
thanks to its plethora of I/O hardware.

John's question/suggestion was to use an out-of-band secret to 
protect a real-time network interaction. That seemed like a less 
universal solution to me, but it triggered revisiting the issue. 

I suggested the same thing you have, above, and also examined 
the whole secret-splitting question - not using Shamir, but just 
simple XOR chains.

Then Paul reminded us/me that if everything was in-band we'd 
have a problem. Paul noted that he was anxious to use SQRL on 
his tablet, but that it lacked a camera.

What's universal on all of these devices that might use SQRL is 
that they have a display and a keyboard, which makes an optical, 
inherently out-of-band, human-link a universal solution.


> That said, a slowdown via Scrypt to ~1 second of calculation
> (on today's CPU's) is only going to be a factor of 10-12 or
> so compared SHA-1/MD5 brute-forcing.

What???  You can't even BEGIN to compare an iterated EnScrypt 
using a 16 megabyte hard-memory Scrypt function to SHA1 or MD5.  
10 to 12???  How about 10 to 12 million!!!  (Unless I totally 
misunderstand what you're saying?)


> We could also try to compare to naked key brute-forcing, for
> which we'd need to benchmark OCB's decrypt and verify, as
> decrypting using successive keys is also a valid attack.

Well... "valid", yes.  But then we're searching the full 256-bit 
keyspace.  Good luck to you, sir.

OCB doesn't give us much slowdown itself, since AES has a pretty 
fast key schedule and OCB only introduces a single additional 
block cipher function of overhead.


> Rather than working *upwards* to "how strong do we want the
> password to be", I think we ought to work backwards from how
> strong the cipher's key is.
> 
> If we benchmark how many decrypt-and-verify OCB cycles can be
> performed in a second and compare this to the time allocated
> to SCrypt, we should get a workable slowdown ratio. Though in
> that instance we'd need to also make sure that what we are
> encrypting with OCB is utterly non-verifiable until decryption
> is complete, or that verifying via OCB is at least as fast as
> verifying by generating and comparing an exemplar public key.

I think I see now that you're just thinking out loud, Sam, and 
brainstorming.  My thoughts have taken a similar course while 
working through this logic.

One thing to consider about ANY "through-EnScrypt" or "direct" 
brute forcing is that the only means for an attacker to 
"verify" their guess is to THEN pass the test-decrypted IUK 
through the Ed25519 elliptic curve "make public" function in 
order to derive a test ILK... and then compare those.

So we add to BOTH brute-forcing overheads the EC MakePublic 
function overhead... per guess.


> As an arbitrarily chosen for instance: If the cipher is 128
> bits, and our use of SCrypt provides a 1:2^20 slowdown ratio
> to search the "emergency code" keyspace compared to searching
> the cipher's keyspace directly, then our emergency code should
> be ~108 bits.

I see your thinking there, Sam.  But that also presupposes that 
our requirement is not to have the use of a "code" + PBKDF 
result in any strength reduction over using the raw cipher key. 
It might well be that we have so much security margin already 
that we can easily afford to lose plenty without security 
suffering.

<<some snippage>>

> Using less key-space does allow a time-memory tradeoff, so we
> do want to be careful about making our SCrypt slowdown ratio
> so high that we are tempted to make the space used for the
> passwords small enough that it could conceivably be compiled
> into a rainbow table. If we get into that territory, salting
> is a must, IMO.

I think that 128-bits of salting is a very small price to pay 
for the benefit of terminating the "precomputation" concern.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/13/2014 4:40:40 PM
[for the unabridged version, see Alan Cameron's post above]

> You appear to be forgetting the users who will be using
> desktops without the ability to read QR codes.
> 
> I VOTE AGAINST this degradation to mobile devices only SQRL
> must be usable on all devices or it will never get acceptance.

I think that's why a complex and secure low-usage manual code 
makes so much sense.

From a UI standpoint, people understand it. My grasp of the 
importance of that is will growing.

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

> > 4. The user will almost never need to enter these codes. They
> > truly are "emergency codes". (This argues, I think, for longer
> > and more secure codes.)

> The frequency of use is probably similar to the number of
> times that one installs Windows. MS seem happy with 5 x 5,
> albeit reduced alpha numeric, and no-one complains. Indeed,
> if you have to resort to activation by phone, you get 8 x 6
> numeric.
> 
> If we are only talking of once every 2-3 years, why not keep
> it long.

Yep.  We want its security to be without question, and it
almost never -- maybe really never -- needs to be used.

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

> Being adaptive today won't help today's SQRL identity blocks
> against tomorrow's attackers. It *will* help tomorrow's SQRL
> identity blocks against tomorrow's attackers, however.

Right. The "attack leverage" factor is reflected in the AGE of 
the Rescue Code... The amount of processing power increase from 
from the time the code is synthesized to the time the attackers 
are attacking it.


> I think it is a distinction worth making. As such, we should
> probably be considering some minimum iteration count --
> sufficiently slow last-generation hardware might have to
> tolerate a few seconds delay to attain a reasonable degree of
> protection.

Yes.  That's in the spec.  Definitely.  And exactly with that 
rationale.


> I *think* calibrating the minimum additional delay to the speed 
> achievable for AES/OCB on a given piece of hardware may be
> reasonable (IE, SCrypt iterations equal to 10^10 times the
> time needed to OCB decrypt). Though perhaps not -- AES is now
> relatively commonly accelerated in hardware, which might lead
> to un-necessarily weak use of SCrypt. Thoughts?

Don't forget that an attacker will need to also run EVERY guess 
through the Ed25519 Make-Public function. The only way to verify 
a guess will be to see whether the resulting candidate test 
decrypted IUK synthesizes the proper ILK.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/13/2014 4:58:11 PM
With claims the NSA and Snowden have made in recent years, and quantium 
computers advancing quickly, I could not even begin to trust anything under 
512 bits.

I say remove all doubt and go 8192 bit.


0
Renee
2/13/2014 7:53:11 PM
Steve Gibson was heard to say :

> So we are encrypting SQRL's master Identity Unlock Key (IUK)
> with a system-chosen, maximum-entropy, Emergency Code (EC)
> which is salted as it runs through an adaptive EnScryption so
> that its first generation requires a few seconds to complete...
> 
> How much entropy do we need that EC to carry?

It depends. It depends on:

1.- How is the code being stored (kept) for several years before ever using 
it again. Memory? Printed? KeePass? ZIP Encrypted with a personal password?

2.- How long is it going to be, so the number of symbols to encode the value 
must be defined as well.

3.- To accomplish which goal? A 256 bit equivalent?

4.- In what user-pleasing format? groups of 4 symbols?
 
> Keep in mind that:
> 
> 1. Making the EnScrypt iteration count adaptive future-proofs
> the system against surprising increases in processing power.

Well, that is not correct, Steve. Once the number of iterations for an 
encrypted IdUK is defined and used, it could not be changed till the printed 
copy is also changed. Yes, the number of iterations could be made to fit the 
processing power of the instant in which the printed copy is made, but until 
the printed copy is changed, that amount of iterations is FIXED. We could 
recommend to change the printed copy every year, but users are as they are, 
its up to them to follow the recommendation or NOT.

> 2. Longer codes, while more secure, are user-hostile and more
> prone to entry error.

Sure, if the user has to enter them. Copy and paste, KeePass stored or QR 
reading makes "entry error" almost irrelevant.
 
> 3. Allowing the encrypted IUK to remain in the SQRL clients
> means that we really DO need to keep them well protected...
> which longer codes do better.

Ah, so the encrypted IdUK is to remain in the application, thus the "never 
stored" part is no longer true. Hmmm, I kind of lost the memo, but OK, I 
understand the idea. But the code could still be printed or stored in 
KeePass or QR encoded and the image stored in KeePass, or ZIP AES encrypted 
and stored in a private pen-drive, right?

Or is the code a hand written value in a paper slip in the wallet?

> 4. The user will almost never need to enter these codes. They
> truly are "emergency codes". (This argues, I think, for longer
> and more secure codes.)

Be careful, Steve, whatever "emergency code" scheme you may think of, will 
NOT work if there is no encrypted IdUK to decrypt with the "Emergency code".

Once the original IdUK or its Encrypted blob are lost, there is no force on 
earth that could bring it back to life.

So, whichever the "emergency code" may end being, it needs the 
printed/stored/written/recorded/whatever encrypted IdUK to work.
 
>>---------------------------------------------------------------
> 
> Consider these:

[...]
 
> I think that grouping in sets of four is clearly the right thing
> to do.

You are mixing both length and presentation here, those should be separate 
aspects. I'll write a specific post on those issues.
 
>>---------------------------------------------------------------
 
> And Terry's argument favoring simple numeric digits is
> interesting.  I am gravitating toward the inherent simplicity
> of smaller character sets.

Of course it is interesting, and a lot more user-pleasing than random full 
ASCII strings, that is one step forward.
 
> And if we were to stay with digits, but add ONE more group:
> 
> 4649 7294 0572 6382 1739 6453 = 79.726 bits (10^24)

> Your thoughts??

Many, I'll post the specifics as fast as I can make them into posts.

-- 
Mark Cross @ 02/13/2014 4:21 p.m.
I don't need you to remind me of my age. I have a bladder to do that for me. 
— Stephen Fry

0
Mark
2/13/2014 8:51:08 PM
Sam Schinke was heard to say :

[...]
> I think for convenience of entry, lower case letters is best. On an
> "entropy per key-press", the shift-key is only worth a single bit at best.

Yep, "a single bit", but "a single bit" per letter. Thus a 10 letter code 
has 10 bits more if the shift-key is relevant, Duh!.
 
> Words only really help when a predictive
> keyboard is involved -- and even those usually don't try to autocorrect
> inside "password" fields.

Then, "words" is pretty much an empty proposal, it carry no intrinsic value.

Thus: lets forget about them.

-- 
Mark Cross @ 02/13/2014 5:08 p.m.
A man on a date wonders if he'll get lucky. The woman already knows.

0
Mark
2/13/2014 9:13:03 PM
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--6PmPvEDM9m59HDLQoaQfg2WulrleVSJQ2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Am 13.02.2014 20:53, schrieb Renee Keller:
> and quantium=20
> computers advancing quickly, I could not even begin to trust anything u=
nder=20
> 512 bits.
>=20
> I say remove all doubt and go 8192 bit.

I'm certainly not an expert on quantum computing, but simply increasing
the number of bits probably doesn't buy you anything. Furthermore SQRL
will be based upon elliptic curve crypto, which is vulnerable to quantum
computer attacks anyway [1]. Therefore it makes no sense to mitigate
against quantum computing attacks at this end, while everything else
will be susceptible.

Additionally the bit numbers you mentioned seem odd anyway. Do you want
to push the key length of symmetrical ciphers that high? What about
asymmetrical schemes then? Usually they are significantly higher, even
with ECC they are at least twice as long as their "symmetrical" counterpa=
rt.

If quantum computing turns out to actually work (in a way that matters
to reality) we probably will have much bigger issues than SQRL anyway ;).=


Best regards,
Karol Babioch

[1]:
https://en.wikipedia.org/wiki/Elliptic_curve_cryptography#Quantum_computi=
ng_attacks


--6PmPvEDM9m59HDLQoaQfg2WulrleVSJQ2
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/Ta2AAoJEHSaZc1HnzIVfMAP/AipXM4OBbEMO5bowou0ko8p
DO2l107AmWqgsjOnOHxup8asbzeBu37DTLcnim9eOetmCdP0PGN7333QuITzRRqb
mP/W3XOQBdipV9zcKtvR9F2UxdUYhpttjSy57fJ0gCKdX3zpfH3ZVBdBoYacNpJ2
SymRESaJZu8aDAk2L2JS24ZAsBPEULSrdAZHw0I+9udnA1KluY5ggV97sCiVSE0A
GnsL97DejzKuAW9kstMBLqbpcidpt1/pfkar9fath+eJG8cXt7vBBB+QxfvsVN5d
YG41ypZ7v/LlCclzPPqFweyAgW+b40BDv05xPENegt+62zx4z14yNJgV+ZAdtb9R
t+1y0U8hjz8kMNoxR2yoCpaUysfY8TBjmjPYm6rbbwpZ/xkW70JBSklQORhogH+w
mWCi3M04BqQKcFOU1IGD/gdgRnbBaCS6ez0/DiJfVq+JbG29lRVDIm37CKSrM2Hw
FV0Lg1UVmdNklv4VF9GxzLZXpJ0kn4at5NOVpynJi6t0m8rQdfkkS6KOE7VIR98a
1l1zIMsX3LP2fv8MIp2lhOjHzDHsJtnHMoMhrguTQDHUWH7AunT39S04m8aYMXd8
vibxHCIjZkqoH2fSLPGwR3b0wGzG9KUKibnG6ow6g4w5HhJybKSBXiVxjFwXi3O5
/nvAeqsM9ih/ikAxiUkz
=kJN4
-----END PGP SIGNATURE-----

--6PmPvEDM9m59HDLQoaQfg2WulrleVSJQ2--
0
Karol
2/13/2014 9:18:45 PM
Steve Gibson was heard to say :

[...]
> ... and my own problem with it is that there's really not much
> entropy in the solution.  The math makes it clear that for any
> number of letters, restricting them to well known words discards
> the huge majority of combinations that are not words.

Oh sure, Steve. Words are a small sample of all possible letter 
combinations, that is the way to convey "redundancy" in the code. Sure the 
entropy of such words is less than random letters.

But a "binary digit", as used in computers, could only be 0 or 1, nothing 
less entropic than that could exist, that is as low as entropy could fall, 
just 1 bit. But computers stack a bunch of those "binary digits" to reach 
"mind blowing" strengths as high as 128 or 256 entropy bits.

Thus, it is irrelevant that the solution "has not much intrinsic entropy", 
just stack enough of them to reach any entropy level you need.

-- 
Mark Cross @ 02/13/2014 5:14 p.m.
Friends are nothing but a known enemy. — Kurt Cobain

0
Mark
2/13/2014 9:22:49 PM
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--MCq4MetgMmsmQHcAA6WcK4WCOEPclNmCD
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Am 13.02.2014 22:22, schrieb Mark Cross:
> Thus, it is irrelevant that the solution "has not much intrinsic entrop=
y",=20
> just stack enough of them to reach any entropy level you need.

which makes it impracticable once humans are involved. Entering more
characters means an increased probability that the user will make
mistakes. Sure grouping them makes it easier, but at some point it gets
really uncomfortable.

Best regards,
Karol Babioch


--MCq4MetgMmsmQHcAA6WcK4WCOEPclNmCD
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/TmeAAoJEHSaZc1HnzIV6YAP/129QdRULwVCAUCmpP3DgbvH
8ntEAUccdIr97O3aZKc09Xm5rE7MBU/inuuq0X0APeEoU7DP4GwdmTmPVl1VS22Q
Pah7NIGNYZEnhddDDw8GVwGTDCdjh5MnGxKHIw6TX05fKuqqqJ+9Yeb3d0pC/fpc
MPz2V7tSTVetK6/L/DcT4DQU2gFdGZW+Fgz0TNncno+h4JqyfQJZZ1hr5L+faEze
T/JbB7Uy/kydpS1xzwAbROwQO9WzDx/19R8R+av10ZrQTj9Dv8Mfa2J13rhvcp4p
EbgGCDLmuunFLpcFot8lo5kbm6xpgdhXPWCiSphDP48oHNwMFkHWvY7Q8q+vhxKC
nDF1nz3W4aqbDb9AjTGFoAzovkfn87yrnvfwLB/XWFBtGJCfN1cZ3235QuSMi6+4
pkouc3DEDd9LAKdE3d0/9nhu74gE2IcHHtsyG5VllzkqRII8eBUDrvO+MdvDW54i
rRSr8ph3GqpjzjxabIlHe7Fdul0fmhTPi0yxzeO98m6a1x7GGd8tbEv/gpdP1qW6
6z6uybC/fTftZkbcI4KiGUqDhvZWeP5Ee8EcVyhVsewDk7b4ntfRQgk9CuLgpZn6
nLNY9lt83sPSn0IyYxmy15x5Lb6nBdI/Gg2w5/LgQDL7oO8Cv04QARiUH1OUCAg0
iNQQlfuUh82rU7y204v7
=pFAq
-----END PGP SIGNATURE-----

--MCq4MetgMmsmQHcAA6WcK4WCOEPclNmCD--
0
Karol
2/13/2014 9:31:10 PM
Sam Schinke was heard to say :

[...]
> Using different alphabets for internationalization might be worth
> considering, but folks much more familiar with how those alphabets work
> would have to be deeply involved there.

That opens up a big and nasty "cam of worms", think about it:
A Chinese alphabet?   诶比西迪伊艾弗吉艾尺艾杰 ....
    http://www.chinese-tools.com/characters/alphabet.html
A Cyrillic alphabet?   АБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЬЮЯ
    http://en.wikipedia.org/wiki/Cyrillic_alphabet
An Arabic alphabet?  غظضذخثتشرقصفعسنملكيطحزوهدجبا
    http://en.wikipedia.org/wiki/Arabic_alphabet
A Korean alphabet?     ᄀᄁᄂᄃᄄᄅᄆᄇᄈᄉᄊᄋᄌᄍᄎᄏᄐᄑᄒ
    http://en.wikipedia.org/wiki/Hangul
A Bengali alphabet       কখগঘঙচছজঝঞট  ....
    http://en.wikipedia.org/wiki/Bengali_alphabet

A very simple (Hahaha!!) language with just 14 basic vowels:
    अआइईउऊऋॠऌॡएऐओऔ
    http://en.wikipedia.org/wiki/Devanagari

If we are going to have a vote, 1400 Millions in china would probably tilt 
the balance scale to whatever they like. I am not so fond of learning 
Chinese, sorry folks, I just have some other more interesting to me chores 
to do.

But the web, mail, NNTP, twitter alphabet is the simple just 26 letters 
Latin Alphabet. I think keeping in its vicinity would be wise.

Sure Latin numbers are somewhat easier to process by everybody in almost all 
countries in this world, except by "bart simpsons" I guess :-).

> Actually, on that front, going
> for a pure QR-code output of the emergency code seems like a better idea
> -- there isn't much ambiguity possible in re-scanning a QR code.

Just that QR codes usually imply paper and camera.

-- 
Mark Cross @ 02/13/2014 5:25 p.m.
You can observe a lot just by watching.

0
Mark
2/13/2014 10:23:01 PM
On 2014-02-13 6:57, Alan Cameron wrote:
> In article <ldh01p$fqs$1@news.grc.com>, sschinke@gmail.com says...
>>
> NIP
>> I would vote for making the number of digits irrelevant by offering to
>> export the "Emergency Code" graphically, as a QR code with the
>> digits/letters/words printed below for the odd time where something to
>> read QR codes is unavailable.
>
>> We are already exporting SQRL identities as QR codes, so the capability
>> to both export and import said codes must already be a given. Entering
>> manually is just a fall-back option.
>
> SNIP
>
> You appear to be forgetting the users who will be using dektops without
> the ability to read QR codes.

You saw where I said "fallback option", right?

To get a file onto a desktop that does not have the ability to read a QR 
code necessitates some kind of binary file. FWIW, transfering a jpeg of 
the QR code onto the desktop is actually a perfectly functional way to 
do this.

Any system that can parse a jpeg file can parse it for embedded QR codes.

That said, the idea behind storage as QR codes is to avoid the SQRL data 
being in a format that may become spontaneously mobile, as it were. 
Storing SQRL credentials on a USB drive is reasonably similar, but you 
have to make sure you aren't using that USB drive for other unsafe things.

> I VOTE AGAINST this degradation to mobile devices only SQRL must be
> usable on all devices or it will never get acceptance.

How high a percentage of desktops do you suppose don't have a webcam? 
Just curious.

Regards,
Sam
0
Sam
2/13/2014 11:02:39 PM
Sam Schinke was heard to say :

> On 2014-02-12 10:15, Steve Gibson wrote:
> [...]
>> 4649 7294 0572 6382 1739 6453 = 79.726 bits (10^24)
[snip]
> As an arbitrarily chosen for instance: If the cipher is 128 bits, and
> our use of SCrypt provides a 1:2^20 slowdown ratio to search the
> "emergency code" keyspace compared to searching the cipher's keyspace
> directly, then our emergency code should be ~108 bits.

A really dislike that statement. That is a saying that we must, absolutelly 
use 128 bits, that users must "remember" a 27 lower character string or a 38 
decimal digits long number, something like:
    35519003919453628479685532412055777387
    07439909810682395974888282577631703021
    44786230148328875175156503825959148940
    94883328780688295806870616503533595840
    93827657765252258224992381722523646038
Do you expect user to keep in memory for several years any of those lines?

Do NOT start an argument that such number is not going to be remembered, but 
printed, that is an issue of a diferent post, discuss such point there.

And:
Some world facts:
1.- Summing the joint power of all the 500 fastest in the world we get a 
number like: 250,080,467.17 Gflops (250E15 flops), just see the image:
    http://www.top500.org/statistics/perfdevel/

2.- That to perform a "code trial" many computer cycles are needed, needed 
to run the algorithm steps, one by one, every time.

3.- If all 500 fastest computers join together to break a 128 bit code, and 
we assume 1 trial per flop, it will take them about 1E14 years (one full 
universe age from the big bang) to break it. Make your calc or use:
     http://www.grc.com/groups/sqrl:5103

Really? Do you believe such level of protection is required?

I have no problem to use 128 bit, 256 bit or as RSA demands: 1k, 2k or 4k 
keys, that is NOT my point. As long as it is computers, networks and 
transistors doing the hard work I have no issue with such long numbers. 
Common computers: do your job, work for me !!

But as sson as you cross the line to "wetware" (humans) the burden falls 
into direct, clean, simple "human hands". And it is in such hands that long 
passwords are a burden and not a help, it is there where a 39 digit long 
number is just maddness, not reasonable paranoia protection.

Average human memory could not cope with such numbers, don't try to explain 
or justify that, there is no possible description to try that.

Average humans should be confronted with no more than about 10 - 20 chars 
long passwords. If your system fails to do so, then choose to print, store 
in a file, insert in a image to be scaned later on,or any other user helper 
to remember the code.

Because, in the end, if users can't use the system, then there will be no 
users to serve.

> I wouldn't expect
> the ratio of SCrypt's slowdown to change hugely in the future -- if
> someone can speed up SCrypt by 100%, it stands to reason that they can
> probably also speed up their other brute-force strategies by at least as
> much.

It very well may, Sam. Scrypt is limited by memory access speed. OCB is 
limited by AES speed, which in turn is limited by computer core CPU 
processing speed. Those are related but not follow the same speed increase 
tendency.

> Using less key-space does allow a time-memory tradeoff, so we do want to
> be careful about making our SCrypt slowdown ratio so high that we are
> tempted to make the space used for the passwords small enough that it
> could conceivably be compiled into a rainbow table. If we get into that
> territory, salting is a must, IMO.

In most cases: salting is a must, yes.

-- 
Mark Cross @ 02/13/2014 7:07 p.m.
The ability to quote is a serviceable substitute for wit.

0
Mark
2/13/2014 11:07:57 PM
Steve Gibson was heard to say :


> I think that 128-bits of salting is a very small price to pay
> for the benefit of terminating the "precomputation" concern.

Yes, indeed. 

-- 
Mark Cross @ 02/13/2014 7:10 p.m.
I've been called worse things by better people. — Pierre Trudeau

0
Mark
2/13/2014 11:12:04 PM
On 2014-02-13 8:40, Steve Gibson wrote:
> [for the unabridged version, see Sam Schinke's post above]
>>> 4649 7294 0572 6382 1739 6453 = 79.726 bits (10^24)
>
>> I would vote for making the number of digits irrelevant by
>> offering to export the "Emergency Code" graphically, as a
>> QR code with the digits/letters/words printed below for the
>> odd time where something to read QR codes is unavailable.
>>
>> We are already exporting SQRL identities as QR codes, so the
>> capability to both export and import said codes must already
>> be a given. Entering manually is just a fall-back option.
>
> We went around and around about this, triggered on Feb 4th by
> John Milburn who posed the question of exporting these secrets
> from his mobile device -- where plenty of entropy was available
> thanks to its plethora of I/O hardware.
>
> John's question/suggestion was to use an out-of-band secret to
> protect a real-time network interaction. That seemed like a less
> universal solution to me, but it triggered revisiting the issue.
>
> I suggested the same thing you have, above, and also examined
> the whole secret-splitting question - not using Shamir, but just
> simple XOR chains.
>
> Then Paul reminded us/me that if everything was in-band we'd
> have a problem. Paul noted that he was anxious to use SQRL on
> his tablet, but that it lacked a camera.
>
> What's universal on all of these devices that might use SQRL is
> that they have a display and a keyboard, which makes an optical,
> inherently out-of-band, human-link a universal solution.

Well, entering the entire SQRL identity, of some hundreds or possibly 
low thousands of bits will certainly be a chore if we want to cater to 
that use-case.

I mean, someone might have a tablet that doesn't have wifi, too.

I'm not saying make the access/emergency code *solely* a QR code, but 
make the QR code the primary interface, with the exact same value 
contained in the QR code printed below the code for human entry. A 
less-convenient fallback.

>> That said, a slowdown via Scrypt to ~1 second of calculation
>> (on today's CPU's) is only going to be a factor of 10-12 or
>> so compared SHA-1/MD5 brute-forcing.
>
> What???  You can't even BEGIN to compare an iterated EnScrypt
> using a 16 megabyte hard-memory Scrypt function to SHA1 or MD5.
> 10 to 12???  How about 10 to 12 million!!!  (Unless I totally
> misunderstand what you're saying?)

Sorry, the number I included was meant to be the *power* of the factor 
-- eg 10^10-10^12.

>> We could also try to compare to naked key brute-forcing, for
>> which we'd need to benchmark OCB's decrypt and verify, as
>> decrypting using successive keys is also a valid attack.
>
> Well... "valid", yes.  But then we're searching the full 256-bit
> keyspace.  Good luck to you, sir.

Exactly so. If we calibrate the emergency code + scrypt slowdown to the 
brute-force difficulty of 256-bit AES then what we have *not* done is 
introduced a more-optimal-than-brute-forcing-the-cipher attack against SQRL.

> OCB doesn't give us much slowdown itself, since AES has a pretty
> fast key schedule and OCB only introduces a single additional
> block cipher function of overhead.

Right, so we might see a brute-force attacker capable of testing 1 
billion (or trillion) AES keys, compared to testing a single EnScrypted 
password. For an attack against a 256-bit key, a slowdown of 10^10-10^12 
would make it optimal for the attacker to try emergency codes up to a 
complexity of up to around 216 bits before attacking the AES key 
directly becomes the better strategy.

Put that way, the SCrypt slowdown just isn't that huge when considering 
attacks against truly strong keys, I guess.

>> Rather than working *upwards* to "how strong do we want the
>> password to be", I think we ought to work backwards from how
>> strong the cipher's key is.
>>
>> If we benchmark how many decrypt-and-verify OCB cycles can be
>> performed in a second and compare this to the time allocated
>> to SCrypt, we should get a workable slowdown ratio. Though in
>> that instance we'd need to also make sure that what we are
>> encrypting with OCB is utterly non-verifiable until decryption
>> is complete, or that verifying via OCB is at least as fast as
>> verifying by generating and comparing an exemplar public key.
>
> I think I see now that you're just thinking out loud, Sam, and
> brainstorming.  My thoughts have taken a similar course while
> working through this logic.
>
> One thing to consider about ANY "through-EnScrypt" or "direct"
> brute forcing is that the only means for an attacker to
> "verify" their guess is to THEN pass the test-decrypted IUK
> through the Ed25519 elliptic curve "make public" function in
> order to derive a test ILK... and then compare those.

Right, or to verify the OCB tag.

> So we add to BOTH brute-forcing overheads the EC MakePublic
> function overhead... per guess.

Well, running MakePublic would only make sense in cases where the OCB 
tag comes back as valid, and a valid tag with invalid decrypted data has 
immensely low odds. Unless MakePublic is less expensive than verifying 
the OCB tag (consisting of a single cycle of AES).

>> As an arbitrarily chosen for instance: If the cipher is 128
>> bits, and our use of SCrypt provides a 1:2^20 slowdown ratio
>> to search the "emergency code" keyspace compared to searching
>> the cipher's keyspace directly, then our emergency code should
>> be ~108 bits.
>
> I see your thinking there, Sam.  But that also presupposes that
> our requirement is not to have the use of a "code" + PBKDF
> result in any strength reduction over using the raw cipher key.
> It might well be that we have so much security margin already
> that we can easily afford to lose plenty without security
> suffering.

Hmm, right. But if we are choosing ED25519 for its theorized ~140 bits 
of strength, and choosing AES256 to be at least as strong as ED25519, 
and so on, we are shooting ourselves in the foot if we choose a code 
securing all of the above that is only worth 80-bits of strength, even 
accounting for SCrypt slowdown, etc.

The reason the ~140-bit cipher strength is desirable is precisely this 
security margin.

> <<some snippage>>
>
>> Using less key-space does allow a time-memory tradeoff, so we
>> do want to be careful about making our SCrypt slowdown ratio
>> so high that we are tempted to make the space used for the
>> passwords small enough that it could conceivably be compiled
>> into a rainbow table. If we get into that territory, salting
>> is a must, IMO.
>
> I think that 128-bits of salting is a very small price to pay
> for the benefit of terminating the "precomputation" concern.

Right, and salting would probably deal with any theoretical ways to 
predict the output distribution of a hash to reduce direct brute-force 
search space as well. At least in theory, every unique salt will have a 
unique distribution of possible outputs.

Regards,
Sam
0
Sam
2/13/2014 11:22:44 PM
On 2014-02-13 8:58, Steve Gibson wrote:
> [for the unabridged version, see Sam Schinke's post above]
[...]
>> I *think* calibrating the minimum additional delay to the speed
>> achievable for AES/OCB on a given piece of hardware may be
>> reasonable (IE, SCrypt iterations equal to 10^10 times the
>> time needed to OCB decrypt). Though perhaps not -- AES is now
>> relatively commonly accelerated in hardware, which might lead
>> to un-necessarily weak use of SCrypt. Thoughts?
>
> Don't forget that an attacker will need to also run EVERY guess
> through the Ed25519 Make-Public function. The only way to verify
> a guess will be to see whether the resulting candidate test
> decrypted IUK synthesizes the proper ILK.

Not for guesses that fail validation with OCB's tag. They can be 
discarded, and OCB's tag *should* only false-positive at a rate of ~1 in 
every 2^256.

If OCB's tag does not match, you *know* the plaintext you have extracted 
is not the same as what you encrypted. Hoping that enough bits are the 
same to create the proper ILK would be wishful thinking.

Or are we talking about encrypting the IUK with "naked" AES rather than 
OCB? That wouldn't be a bad idea on the face of it.

Regards,
Sam
0
Sam
2/13/2014 11:29:55 PM
On 2014-02-13 11:53, Renee Keller wrote:
> With claims the NSA and Snowden have made in recent years, and quantium
> computers advancing quickly, I could not even begin to trust anything under
> 512 bits.
>
> I say remove all doubt and go 8192 bit.

You are confusing symmetric and asymmetric cipher lengths. The longest 
symmetric cipher key-length in common use is 256-bits (eg, AES-256).

SQRL is proposing to use ECC crypto for the asymmetric bits, too, which 
results in much shorter key lengths.

Regards,
Sam

0
Sam
2/13/2014 11:31:17 PM
On 2014-02-13 14:23, Mark Cross wrote:
> Sam Schinke was heard to say :
> [...]
>> Using different alphabets for internationalization might be worth
>> considering, but folks much more familiar with how those alphabets work
>> would have to be deeply involved there.
[...]
> A very simple (Hahaha!!) language with just 14 basic vowels:
>      अआइईउऊऋॠऌॡएऐओऔ
>      http://en.wikipedia.org/wiki/Devanagari
>
> If we are going to have a vote, 1400 Millions in china would probably tilt
> the balance scale to whatever they like. I am not so fond of learning
> Chinese, sorry folks, I just have some other more interesting to me chores
> to do.

Right. The idea wasn't to choose a single alphabet for all SQRL uses, 
but to contemplate that SQRL users in different languages may wish for 
SQRL-generated codes in their native alphabet.

I am reasonably certain, for example, that computer users in China don't 
exclusively enter their passwords using the Latin alphabet. I could be 
wrong, though. Based on looking at "chinese" keyboards, they all seem to 
be optimized for typing in Latin, with Chinese entry being a secondary 
feature.

I just don't know enough about unicode and all that to say whether 
computer-generated passwords in non-ascii alphabets can be reliably 
reproduced by keyboard entry. Chinese, with its thousands of characters, 
in particular, seems fraught to me. Someone familiar with each language 
and keyboard/mobile entry in that language would probably have to be 
involved.

Diceware and S/KEY, OTOH, are approaches that seems extremely 
translatable. When an app is undergoing internationalization, 
translators could provide a word list that is substituted for diceware's 
or S/KEY's current English word list.

> But the web, mail, NNTP, twitter alphabet is the simple just 26 letters
> Latin Alphabet. I think keeping in its vicinity would be wise.
>
> Sure Latin numbers are somewhat easier to process by everybody in almost all
> countries in this world, except by "bart simpsons" I guess :-).

Yeah, I think it is reasonably safe to assume that even foreign language 
keyboards can input Latin numbers. But then I'm not an 
internationalization guru either.

>> Actually, on that front, going
>> for a pure QR-code output of the emergency code seems like a better idea
>> -- there isn't much ambiguity possible in re-scanning a QR code.
>
> Just that QR codes usually imply paper and camera.

Or .jpeg files and digital storage.

Regards,
Sam
0
Sam
2/13/2014 11:52:10 PM
On 2014-02-13 13:31, Karol Babioch wrote:
> Hi,
>
> Am 13.02.2014 22:22, schrieb Mark Cross:
>> Thus, it is irrelevant that the solution "has not much intrinsic entropy",
>> just stack enough of them to reach any entropy level you need.
>
> which makes it impracticable once humans are involved. Entering more
> characters means an increased probability that the user will make
> mistakes. Sure grouping them makes it easier, but at some point it gets
> really uncomfortable.

Having a checksum on each block of letters/digits seems like a good way 
around this. Microsoft's product keys use this approach, and it saves 
you from getting to the end of 20 digits to face an error at some 
unspecified position within the string.

Regards,
Sam
0
Sam
2/13/2014 11:54:02 PM
Sam Schinke was heard to say :

[...] 
>> But the web, mail, NNTP, twitter alphabet is the simple just 26 letters
>> Latin Alphabet. I think keeping in its vicinity would be wise.
>>
>> Sure Latin numbers are somewhat easier to process by everybody in almost
>> all countries in this world, except by "bart simpsons" I guess :-).

> Yeah, I think it is reasonably safe to assume that even foreign language
> keyboards can input Latin numbers. But then I'm not an
> internationalization guru either.

Dam, Sam, you do are extremely stubborn. I am NOT assuming as you do 
sometimes, I DO know that most Asian keyboards include Latin letters and I 
am also sure that almost universally Latin numbers are included, Latin 
numbers are used everyday, read in newspapers by regular people and the sole 
way to specify a phone number. Would you listen?

-- 
Mark Cross @ 02/13/2014 8:22 p.m.
The worst time to have a heart attack is during a game of charades. — 
Demetri Martin

0
Mark
2/14/2014 12:29:14 AM
On 2014-02-13 16:29, Mark Cross wrote:
> Sam Schinke was heard to say :
>
> [...]
>>> But the web, mail, NNTP, twitter alphabet is the simple just 26 letters
>>> Latin Alphabet. I think keeping in its vicinity would be wise.
>>>
>>> Sure Latin numbers are somewhat easier to process by everybody in almost
>>> all countries in this world, except by "bart simpsons" I guess :-).
>
>> Yeah, I think it is reasonably safe to assume that even foreign language
>> keyboards can input Latin numbers. But then I'm not an
>> internationalization guru either.
>
> Dam, Sam, you do are extremely stubborn. I am NOT assuming as you do
> sometimes, I DO know that most Asian keyboards include Latin letters and I
> am also sure that almost universally Latin numbers are included, Latin
> numbers are used everyday, read in newspapers by regular people and the sole
> way to specify a phone number. Would you listen?

Fair enough. All you had to say was that your comment was from direct 
experience or knowledge.

Regards,
Sam

0
Sam
2/14/2014 12:41:11 AM
Sam Schinke was heard to say :

[...]
> Yeah, I think it is reasonably safe to assume that even foreign language
> keyboards can input Latin numbers. But then I'm not an
> internationalization guru either.

Dam, do not assume:
   just look at a typical Devanagari Typewriter, for example
       http://en.wikipedia.org/wiki/Devanagari#Typewriter

They do have and use everyday Latin numbers !!!

I am not a guru nor pretend to be one in any sense.
I also believe that anyone here should NOT patch such tag to himself, but I 
do really know some small stuff, and also that as Plato liked to say:
   I do know that in "good knowledge" I know nothing.

Probably you don't even understand that.

-- 
Mark Cross @ 02/13/2014 8:33 p.m.
Failure teaches success.

0
Mark
2/14/2014 12:43:30 AM
Steve Gibson was heard to say :

> How much entropy do we need that EC to carry?
[...]
> Your thoughts??

There are several ways to store the code (be it called emergency or rescue):
In order of simplicity/capacity:
1.- In a disk file.
2.- In a network file (think dropbox).
3.- As a string in a text file.
4.- As a string in the user wallet.
5.- As a string/number in user memory.

A disk file is very easy to create, very easy to move around to web 
connected computers, and in this days of sharing images, videos, messages, I 
find very easy to share with phones (at least in android phones, I do).

A disk file could store big keys, no problem, 4096 keys (if desired) would 
be very easy to carry.

A file in a shared dropbox directory is the next reasonable step 
(iteration), and provided the device where you want the key has a Dropbox 
app, the file will be available, no problem.

Of course, at this point the file for the key should be, in turn, encrypted, 
so it does not fall in bad hands, and that is the kink in the file sharing 
armor. Because the encoding key for such file is probably NOT going to be 
128 bits long. So, we fall down to the user encryption key length for the 
"key file" if you follow me.

Of course, the whole key, could be encoded as lowercase letters or simple 
numbers as a string, long as that may be. That could be included in any text 
file, sent as a text message, read letter by letter to someone, etc.

The string could be up to any length (bit strength) like 128 or 256 even 1k 
if the need exist. And still, sharing it in "Instant messaging" apps is 
quite easy (security aside) (Of course OTR would help to keep it safe).

Leaving the hardware/software world and entering the wetware (human) world, 
it could be hand written in a piece of paper and entered back into a 
computer field. One reasonable place to keep such string is the wallet.

But asking a user to remember a number in two years time without ever using 
it in the interim is just crazy beyond any reasonable point of view. I hope 
we could agree in this basic point at least !!!

++++++++++++++++
Bad assumptions:
It is a very bad assumption that the encrypted IdUK will NOT be printed. It 
must be printed, it could be encoded as a text string also and stored in 
text files. But if anything happens to the phone, all the IdUK gets lost, no 
possible recover.

It is almost utopic that the "code" is NOT going to be written down in a 
paper, and there is the very clear risk that users will write the code in 
the same piece of paper that holds the QR code for the IdUK.

If that is the intended way to keep it (in the wallet) then the request that 
is being made to the user is to keep two secrets (the encrypted IdUK QR and 
the code) in two different places. An idea for which I had been flamed 
recently. Is that it?

Then why not just print the whole 256 bit IdUK (unencrypted) and ask the 
user to put it in his wallet ? Too risky? then just add a very easy and 
simple encoding key, PLEASE?

-- 
Mark Cross @ 02/13/2014 7:14 p.m.
I'm not a vegetarian because I love animals. I'm a vegetarian because I hate 
plants. — A. Whitney Brown
0
Mark
2/14/2014 1:07:48 AM
Steve Gibson was heard to say :

[...] [ the quoted lines have been explicitly EDITED/MODIFIED]
>>---------------------------------------------------------------
> Consider these:
> gwiv whuk devy
> 3684 6024 6268
>>---------------------------------------------------------------

I believe that it is an almost universal agreement that we should:
1.- Avoid symbols, either too difficult to type in phones or just not 
available in some language keyboards.
    Want to convince yourself?  Type:   æđÅßñ   (Also Try in you phone).

2.- Stay in ONE grouping, either lowercase Latin letters or numbers.
    Just remember to allow for +(). symbols in numbers (telephone numbers).

3.- Provide some "rhythm" (more on format).
    Like 4 letters grouping.  Like "duxw korn yqxy"
    But intermixing may be interesting also: Like "duxw 542 korn 873"
    Or make it similar to something already known:
        +36 (846) 246.26.83    sure looks like a phone number.



In short, about symbology:
       I agree to either use lowercase letters or numbers

-- 
Mark Cross @ 02/13/2014 7:15 p.m.
Most of us have far more courage than we ever dreamed possible. — Dale 
Carnegie
0
Mark
2/14/2014 1:24:20 AM
[for the unabridged version, see Sam Schinke's post above]

> > Don't forget that an attacker will need to also run EVERY guess
> > through the Ed25519 Make-Public function. The only way to verify
> > a guess will be to see whether the resulting candidate test
> > decrypted IUK synthesizes the proper ILK.

> Not for guesses that fail validation with OCB's tag. They can
> be discarded, and OCB's tag *should* only false-positive at a
> rate of ~1 in every 2^256.

Sorry, Sam... I haven't had the chance to catch documentation up 
with our rapid forward progress.  There IS no OCB-authentication 
tag for the "Rescue Code" enciphering... only for the User 
Password enciphering.


> Or are we talking about encrypting the IUK with "naked" AES
> rather than OCB? That wouldn't be a bad idea on the face of it.

Since we want to encrypt keys which are double the AES block 
width it makes sense to use a block cipher mode.  And since we 
do want password-entry validation that means we'll have OCB. And 
since we already have OCB we might as well use it for all of our 
key encipherment.

We simply won't record OCB's auth tag for the Rescue Code (IUK)
encryption.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/14/2014 1:26:02 AM
On 2014-02-13 17:26, Steve Gibson wrote:
> [for the unabridged version, see Sam Schinke's post above]
>
>>> Don't forget that an attacker will need to also run EVERY guess
>>> through the Ed25519 Make-Public function. The only way to verify
>>> a guess will be to see whether the resulting candidate test
>>> decrypted IUK synthesizes the proper ILK.
>
>> Not for guesses that fail validation with OCB's tag. They can
>> be discarded, and OCB's tag *should* only false-positive at a
>> rate of ~1 in every 2^256.
>
> Sorry, Sam... I haven't had the chance to catch documentation up
> with our rapid forward progress.  There IS no OCB-authentication
> tag for the "Rescue Code" enciphering... only for the User
> Password enciphering.

Ah, alright.

It may be worth benchmarking either way.

>> Or are we talking about encrypting the IUK with "naked" AES
>> rather than OCB? That wouldn't be a bad idea on the face of it.
>
> Since we want to encrypt keys which are double the AES block
> width it makes sense to use a block cipher mode.  And since we
> do want password-entry validation that means we'll have OCB. And
> since we already have OCB we might as well use it for all of our
> key encipherment.
>
> We simply won't record OCB's auth tag for the Rescue Code (IUK)
> encryption.

I hope that doesn't mean re-writing all of the various OCB 
implementations to allow decryption without a tag. The last time I had a 
look, the tag was pretty central to the API's.

Regards,
Sam

0
Sam
2/14/2014 1:42:41 AM
--nextPart2380152.vYc0GPUKhN
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8Bit

[...]
> How much entropy do we need that EC to carry?

Now we get to the core of the question in your title: bits.

If, as explained in the "storage" post, the "code" is computer bound, that 
is, copied, moved, scanned by computers, then make it 256 bits long if you 
want, I have no problem, nor most of users I believe. Even "simple" users.

If the code is going to be exchanged by hand, but stored in print, it is 
annoying when it is long, but not a huge problem to write or type even 40 
chars, so that would be my guessed(?) longest allowed string.

But if memory is involved in any way or you want to reduce the annoy factor, 
keep it not longer than 20 chars nor shorter than 10. Why? well, using:
    http://www.12078.com/groups/sqrl:5103

we get, for 1 second delay:
    Attached Image1

and for all the 500 fastest computers join together to break the code:
    Attached Image2

Conclusion:
Image1:  Do not go below 10ish
Image2:  No need to go above 20ish (much).

-- 
Mark Cross @ 02/13/2014 7:16 p.m.
Veni, Vidi, Velcro – I came, I saw, I stuck around.
--nextPart2380152.vYc0GPUKhN
Content-Type: image/png; name="KeyLength1.png"
Content-Disposition: attachment; filename="KeyLength1.png"
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAsQAAACIAQMAAADanm/+AAAABlBMVEX///8AAABVwtN+AAAACXBI
WXMAAA7EAAAOxAGVKw4bAAAJd0lEQVRo3u2a32/bxh3ASUuj3IGw1WTIaFgzlTjQ9qhMgOuijuQB
Q/dSYK8b+lBmdu0W8BJ6TlsPcSU2MZyXIM3T4MHY/C8EG7BiyJbQyxAjmGNh60uNBhFTZ9PLaitx
MdOVIo73ve9JuhNluWk2NJv4cuKP++h0/N6H3ztKkp7RbdQUj7ADsv1luBnbBpC8a9EDHiX7hc3I
sTlaluh+76/p7mwJitAqramM0MMnsFbOtpNA3qmTk0iW8Jo0JcsCuYLkbVpzAL9/x6HlK0iWfoY/
4pcSHNiRJIux30byX5F8kV65NgxFVxXJZ3mymilk4Ew6s1slpfbuNiF/lv20XCk8hqveoR0f2qTk
rytYlTZJ2qaFMkvLFB5W0x9S8siZ1OdArt4kpyrVqfKaNwWsHG1z6BG2eYFWHWFk7Oc5gTycv0Fv
U7Y8AOSt/FVC3pr6OI3kTIySr1OyvE6r9mAM3aGHldMi2fsAvjOWY+QCIX+2NVXIIjmiUvIN2oPy
XSSP0t1LSJ4QyeU/UvL0tUO0Nz4m5J3s1Pppl5InKEp2KaLPo1XzLhSRKpLxDqbwDmZOeh7eQQ+i
KTvnkRpeNvcg51UhsOYqXNTptPukx0im9SW9gmHrsLGidtFSs+mPjr5Cg8gIJ8MS/GAtyQ0uvF6K
sqGKZTeW7UZuz9Nxh+496Xaj4TP0Sm/tU2cTt1jDZ0/tYc7DLWRJH5H4tKTQed+d/l0hvux1pFCe
xBC7Kg9FVgo1RgdPpsLJiWTdBmP4EThA4i3ikz/175TKYm+eVrN88mgg+bBEyTOSVSfDRbakXgby
EUJWklLXG83kGdJen9y7enZk8151roEcrfwLBp75brX4K2BGLhbIaIvlT675HZX81uYvDvt6U1J5
0yDkXnPbBXKO1Jtez+Tu+WTF+8ML18tnKo3ku0NXYEiPL19/E8jhPz+C3vjLDzO/8ckTG4nnhxwp
8smHt1cIue93G28QcuU2aa5Zzh//G5CvZiqpM3cbyWu0zWfHl67/lLZ59Sohx1bPPX5EyBUgKyfu
ufeJHPo+WDagzXvkatO7eXy9BflOjTzwOlVOsQTk1zIV8pD8SZaSv5l3Zwg5uoxkUCEhVwm5ktQv
pfjeuDMEApr22zxJD52i5Fd11SefmMhOAPnI6q0sIf94eZGSVwh52r15/JFPjuTdk7vVarWBPLft
QZu97N7uLRoUOY98dabgFf14zqUTY/eLfgQWPW/bZ+n553pLEM858ozJ6TmPeDRyXtK+p0pxbtxY
BqY4P8AHXigMRTj5J3BqYnRllTRSTcJtUGR84lLXhqOgU2Xfoal8o8UJWWk7rHv3J8eenNzZ/mtb
qOFRe8qP09+WIvk02fm9Vcbne4TlpHj/Snj78XAWQXj1mBNAvp+wpcPRhdtvk50l6wLGeRhPfxfJ
VzALQM1+H0GYjG3WRkcDeTDt+H6+vFeEEWFdkHgyph0yEzeWKk8eTLYgp+KX93bJzrBVxFNfQwQm
9bITTDYOQL5ByTqbsGCdFJIXA3Ojtm3u98kXaW/oyX3JIT4Li7Qhy/1+Py9AfWsJrwl/efLRhO2T
F26fhvrzS+a+ZIW/sTVyPCi4V8gvlxVohcGAtWBgMRIPHhnWAXPR+vP+6W/dHUE9G1s9SLTpTUva
LYUW4PlXMqZtfjUCpy6yy1t0mL8qbjdbdHiDWnR9iOwtOmykKIJFo7xFce4awfDftJvb3FegFv3H
O/ALmshJYbrGkxVTaLNI9l1HyS86Swb/TBkJJk/xo7sleadYpeQZo8XTio1uZtG5A5L7WZv1h8us
N+KckZhUmeu2+OWnVmRiUSDLy1+UbLQmaxvUoreGwJWv18i8RVkNhScrIjlUqpHTe0Vb3sWsQHbH
WT+zwBwIJs/xd6PsdCza2Q5sUSXGLAr37qH9ULBohrdoROIsGsZysNmiPSSeSZa7rpHda841wRsC
udfi4lnFcsxobvMksyi0ud/UBYsKi14q1sQlxzCuBMbjLcjEokB+yWBk1maRbHGjuy2ZWBTIM05G
IAs5Um8LstG2zeYLgpEEssrPJmrk0WAyWLQbLGquChZVeV0yssqTB61mcoJZlJLfKht8mzW+BiOv
IXkcyU6TRXXeouW/ixYVyKyfMQh1jLpyqXnMaHGa5eJvnpeEqY443xMe6VrHov+rFpV7ahYdofPB
Mp6KOJzrJCfYolori4b0mkUhzXrRYiNFINfWCgSLDgsWrZEjfQmW5SbI/jnrvOCLY/x8kLnun7hs
i2+XPmlyndxXZEYCIf/Icti3j3IWZasQbHRv8b3R7DokE4tCcr9ouQZ/SZjvjRbko/Y+bVYpWRsN
Ji8Grsm0bXM/+ll2Lc3iZ8cqT5b46UuNnGwm1ywKrdDmlx1ePRpPfs7iLYqnjyVFi0YKNYvCGn//
A68UTC7xC5SiRZtzUYW3aG3xoWkzgidG0ldgraCz/UcsevOyYFHDFFwXC7YovlgPzwrZF3OdvFrg
LTpsuAI5HWhR+X1aqjhLNkSLyrc2eIvOOosOb9FUoEVDl2gZw5VXxxF7Y32vyLJchScziwrkbqyJ
77vD2IB4KzKxKHToklEWLJoOtigjq+JKoEAmFu2h5CWBnAq2KCN3tyETi5K7LnsPl0u8RVPBFmVk
9oQtBZMhy508GNniyaZAZhaVi3WLUj+Pu8JyQzrQouw/Jzo+W9ymZVO5btHuYIuqwRYNfeHB2Vkr
+H/fmOtOFesWhdH9kjMWvBLI4jlJSxn9zCxan7VhtfuJukWBfM5kb6DYfFB4b2XSMvS+xFn0mPhM
GUzXLYrkMYknDyIZBfE8jnJ8vcUs2pJMXHeEHHjVmGQLc8F+Fsk4so7Z+5Bh/XnJnBRm9MLKSQty
U8bIyMSiOXCdOZnkyUJ+J5KV/clgUSSPCWRh5UQkvyzkoox8lMYGZLnw7frZMaE3EtgbWDV6pQ2Z
bStiLjpf86sVuFYgCZbVvgK56FOx6JP/O4vfLGC5HWe2zHK16c16lgu6dK0+m9chZrlduN4fNfh4
nhXyOqw2vNFgUbDnBStnBFq05xBa1Am0qJh99RUaLArnLCtrBlq0KxXc5jB3VTOZuO47kAdbr5mB
Fm1FVoWVE5FMslzs52VhxbUNeVh4WolklotK2nuuGWjRVmS0qPiOnpHBot+GVYj3XCPQoq3ILweT
tY0Gi1Ly/IARaNGuQwcjY5YLLW5ccZXKD3Sb72d888j+WT3H/7OarRX83HlGLfpvFAHkyYiqPpEA
AAAASUVORK5CYII=

--nextPart2380152.vYc0GPUKhN
Content-Type: image/png; name="KeyLength2.png"
Content-Disposition: attachment; filename="KeyLength2.png"
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAsgAAACKCAQAAAAdrXSzAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAR
uklEQVR42u1dza7lRhHuOpxsYFAkpCCxRki8VQbCvEJWWbLKkjVRhmfgBXgMJCTEglVWQYqIxCLF
4s7NObaru6vt/vna/r4rZXLuPbbLVdXV1eV2faIaCIIgCADcqAKCIAgGZIIgCIIBmSAIAg/3PpeR
EEIILFdfV6f0AIKoGpDF/K0WDDzpOiBlIaVEJR4bonL6zJ9FG8miRcdqR2nr20ANj8HwDQWa0tb6
EVBtCawV85J1KlmMH4YKFo7PoNPZpZXM5Ig1VeOvf8ZfW0A1KW5p7uXDSowZEnHgqZFVoIWFvD77
ZEbPK4gvQwifDwy3vTLBucIeprQKIpkm8/eZ9HM/Muw0uRyNDaz+Sy9ZBJz1UlVM9b0c0bbUoY6F
tJj3oF1cabtMlUggl81vUtJK9nz9ixsv10OYsAU4HGtGf2Nkkqxd55lQ7/XCx3PQeIQzWR35+L12
N5aaEtvGk+YDQSO/EYcztdPel+HzSDg+GuzQCwVjkoV+K4/6+lEQSa38GEWu0r/c6l1cHRd9Dc/a
TVG6uK496DRT1Hg/bCaV7rXvzw1Zvtho508Z19LdmQJCrV8mrD1eUz/WmnIGSPuA7J+ZMMyZW/7r
U5h+C2JqZHfTqaSNSayV1wbnCn6WfjDWFLrRFspaRwp/f+8ryHPNUQcPP2uxEy95jK9FSTc9La/0
xS4pZ3hkZgdfhZZdAIKfREoYo22JJ1e5J91aCqKu0sbY2T5tulFD8zdAzv3H8KZwyptj4SirgoBM
uN1sbK6OEfZQ5doXPW4jRByrqtKr/61rDfkF/4BwpVdN/RRmourhFQIjyXPqgLOPXjb/CsRkhiaX
7Io7UtZ+c/ssM7VprGZYrKEW31au2OJdmxvNfl9MiodwnblcTfkkm1frobDWb3OfZO8VYSjjvKmX
K+wo5coEZE80EfZD9ihWB19TjN0i/R0rL4NsQoju0mmvSqm1KRNnN7JCjgXK1dKuDMjEqRyeIGYG
228S7hyZD70Ioi3uVMG+5TvvnyAIBuSh4KKdIIh2YMmCIAiCAZkgCIJ4BksWU4G7HQiCAZlhp9ld
LrFtVIoloZ5G7+r+rla3RY1XF6SCxxx/BacPqdNRfbWkeKp9xyxZTAU98dWua0UpDgJ1mtjXfB1b
F/9VKH1ZoXj/mdrpEDZDvtbAlGC/lKyAcqayyNnyZB0w3I5Jk7KJDNHh9lXlPr3ySvWlwXopH3ET
5z0/wLYDLk3WtH19Nva3+PevmCfFgrJECxp9w7blxGq2UNcIRZbd70S7B5H08j/Wg0A76lajUmmH
SVuiUvj9LtUpRDvry0OdMUqH69FwWy+FZLEoWrYofPRPEiOgivl962/rs22/T3jdXQYGsnLpUAja
49KiEPfGpFqOnhZeIBFrPY9OLT6jVi0UlOhrRKrn1eH2e7eU+0lkNrLyZ11lEs+RX41jxZk3XrGI
sdbBZ+Ezd57dxr3WgfT78L0zY7NXUwj2RiYT9UpVn+JJ3KWBdPKk1ab3GvoSY5Ujna4vRd3W77Yy
JXOYOooOspivZNLBMC4we1qZandp8t8Vp9OOzTvRQq6GffVX6TQl60LO2fT1WKXrgPFTosNbyaBM
/V6A+smeqzghBVrvJ1Wd7TkI2/oU0tJaeBftphw10qw6XtxXX9v7GPX8JaWL+/FBo5FFAlELn4UQ
vjqQtdbLkl994Sfho0mzVZukANFf44/CWsmazrbVfHLks2qPvReaWHlrt4m4RIfuDLnkCf7zzS0r
oEc38hCv+CqSHWDVX+0JHGmlFAtvex9Wtc+XfVvznkme9KB28tbTxLiN+cV/mq+M/PpaUjy1X3N5
dPh0hucG9eIMj3ZpXEP6zR3JzGUKvBO3V4jwU2D10JLPRpLN6zAe4IrLs6WDrsWd3VlSpbdCalU5
1ttVlxRdMdbu/BpEO+qrbZQ5okOzsrAOyO/Dp53TeGKf/nC2COZ2l+PvqPFST/W1dEqqtjLGKcQ0
6pPxzW3fho9Dm53zXn2N2vGe1qEp9TZDZvAkehQ46GdXsPrIkDgjbt7hQxAEUYa/UgWl09gjQ+7/
Mi5xpfyYuRKtTrsXBGSCIAhiJNh+kyAIggGZIAiCYEAmCIIAxOLV6Vjh3dqGvtwivkSqLJ3qrly3
Z2orSHIzfsn+0FjX4LQGYi84aNaOde5+eW77WqlW4ApmzZDdUTtaLiTtxXYbY8mFIdV2bObluq2D
wKNrZ/wSsrN/8bojcjC6KwfDCZGGr6w+vbQdFfOz11x7gnis13DbdkOyuVrcXjO8Co/qeTKFvgRG
TnGOkbHyeeRyliyW78s/Qrf1nbRr6WIee2+eAzVDrv/G4bbTsUeHy6O2R2h1VrPysLFuMagR/2gD
3S0/Zjjuq70SfY2XCnnSL9fObevGevD2tcDNPt0xjEaqN7d404qG9GUCe1uEtx0WcwxRBfW4+eRS
6ssVL/Ieej8630iGb29ftjnX5mjd9GYVpx6+qpyJPy+NENqI+6cP3BIGjmQKqCu+5lMX91JHVbcz
L9sx6wkGRe+Q4K+FSdWwXvM+dDN8dQrdI0qGqz22D6vlVXf7cLujZ641oZhU2zRVHNvW8zZLrccC
2n2Y5MilHqQ5z/LTI/YufZG1R6uGorEZw81aGOW2raUuq4cNe6V5U6vsReiVOYnpK7nKokxlEa7T
zpWRCoA0JWPzlj84zZZXQuPinTPmmGs1Oo35jaBRPgFxG/z5agqiD7noNIuw6MXL+q5rt/JU6b42
+5qzQqPFDNnpPgKQ67VaqPUtEujuOn3d2V+mtV9qgiWIGtPoYy3s2YdktN+0B//yNJLJ5UrfMrOI
YbAzFTXuZw8bYV7XJUfF6X1aaCBmvzypE6o9MQKygGovRfFGfeUSz+KAPH++OucsqtWP6knvE/uU
W18R5YNbT+PBlCuUB2SGY+IsYYMg5kBiHzIHFlEOeg1BNAnIBMFgTBA90bAfMrc6EQRBgARk5ksE
QRAgAZm5NkEQxOkCMnNtgiCugEIKp+UrELUonOwzoYThMsqm0RROrXWYJ5DK3x3SBEuqpDr6QqBL
OiGFU8hQOL2e1qZw+kOmxBCjcMJFGWUTAoVTLxdLX10mKTORKumc+kKT10/htHgxRJ6yGY3miMse
Btsj1nOVZo57zrewXqB+bSeqCflT//rmdEuLaR3+LoTw9Y9H6epsGrFaLbf6JnyyuVp8nSDNpaqV
7ePIJonVqELqC0kunLx9Ozbzcu2gcPpL5u+xdozv3N9EQRllEwaFk6939X58Ez4pul/tIlVdLePK
hUWVhGJVLaDNGBs/8nLdym/hbfLb8aP/nP3eLA/vrNku9TmF3zdzojba/GXBAk0Kny9gZKcCJ1Fc
m5ipC7Ef3SicyhzwCga2a811KJykeYDwXk0cDVvxgh+pko74A7FfP1UpnKzQndqNQUPZOxBqUTi1
mEL8V1+SOM2y8gmgUr//sDYlVdIRL8VfQdzy4bgs3uvBQHGV/NjeplPjXC11aFE2pa6mF7Rs26CM
7cco4U9hng9UoHDa7kLuTeGEnT/FKJv2Mk7Ec0ufwUcNCY1efdawS6qkM+bLI/2pfGze1u4omx87
e44/YnjnEHLW/FgKP3vD+z730sV+bmmuQ1ntp9xefe0v5yB3QsDbsH6czvzY56WjY4WYgbkShZNF
XXReCqdyyiYUCiftog/bY3LPEgKsfUmVtEcuBbMjohX9kpHCadKltUJe23qNZr6iBSmJOEJGSZah
cKITEGcIZwQxB26+QUYQPjAcE0STgKwB/+VmYokfBgdjegtBHArIwtz4NPjfHO2tCYKI4K5cfJ4G
nEIJYvIMmSo4C74PH1EJBMGATIzHf719ogiCgAUpnAwJj1A2lbN/lGoxR6LUlr4m92pPzJdQKIhS
/kgKp/36GilZ7zGwX658fCCFkynh41MJZVM5hdPj27UonNrS13jPLl2lqnE/AVguUjiVyYdK4eSR
hxROq/s8Qtk0jsLpn+HXof3rv/I0Za8Jo1Lf2x6HNUxI4XRUXzIdVdJIudRbsnil20nH8XcZMdR9
XElXsx44RtlUl8IpNSS+fjK4hhD+HX7RTUc//Ogf6UGoZmEGKezh+V9eLoWSC4fCKbW6UBC5fP5m
vDqdy5BldXJd5XYaUcj2OPtqKL0aJPibCMVzmj0Zck6Ha5P/Pfy2S3YgH0Lya6VLN2sK29JhcxzW
IlcjKyQMuZAq27ZnC1TvYYGaxKxI4s6QPbUjUjjVmz/FnPys/0/p8Nvwq645ys2wsj1MU8dhghRO
+wsZlKOGXLd8fuztwL/+zuOz8qXa6MSzzWrV0HvKAv8KH3fKBDRi81yLyHkonKy7wZENOezgFHvm
luueD8dl8Z4UTqX3qR92Z+zFz6IbB+vnU1roBVJ4HJFbU+H6MeWoIdc9f/D6t/lGy3YgULBqmN/9
1/VZ7+cjYc8bTMe1vPRKOU++jEkg+uKH34U3nJHgxkB9ue7rw8V5+vj33jmEnGWeiz9e830uCffl
OZKu6vTawcE06yOanbCIcvyc+XEmoryOAZTEb9/YJIVTZLLYR9k0nsKp/S6LlAXFlAF1ZUQKpxpy
KZAVkVbipHC61BJNwxi72a/02i/U63S+RAqnq4wRWLlJ4UScP5wRxBxI7EPmwCLKQa8hiCYBmSAY
jAmiJ9gPmSAIggGZIAiCYEAmCIJgQCYIgiBiIIVTZcqma1E4xa62pR7obdWS+yFV0l59oVIlYcrl
GQUXp3CqS9l0PQqn1NU0ISVSOI55A45cuPpCkxedwikv16UpnGpTNvWicFpOns9HtM2llg3qdfN5
6zFiSokWXkiVdGx1NDoXnYfCKT8KbtsBnLuFPIWTOo9TAEqaMcWKsFOHkin/tM+zfjDCc354Yu5Q
jvufQsmFQ5WEakdPFj9aLmeHm6tTONWjbIqvEkoz5FIKp1iGXFuLawqnsPqsDk9CC86kStovF1rT
qBkonHKjgBROA+fPOhROvfOAW+azPUUhZHjli020qYOYTz9lT1Hu+fzYu2SynySmdmPQgV4foepC
a6kaYlr/bXvmbmvUkpRGjNCm01iHL4LPmOTMIZd6AzIpnPovY45SOC111rbeWEbNpIuQzAaStUsY
SJmfQG3Hw7VbTs7b9uBt5Sr17F7dQRs9U9KoHvZ9PiaJuA0ev5p20tdWf1IgJbMr4mjQw/Qu2eyW
ystJCqfkPD8bhVNbsqQ8NVOcldG3/iKuvW48kqmjUzj5RsGlKZzqUzaNpnBqm/HlKY/s3dB4z71z
9idV0j77jy+d4FI4Occ3KZzOli+1tVq6JrZ+hKsn0y0xi75I4URwcNJjCOIQSOFEVAW9hiCaBGSC
YDAmiJ5gP2SCIAgGZIIgCIIBmSAIggGZIAiCiOGCFE5tKZvOS+GUIu9JvVAR6/uG8QhwBgonHKlm
oXDC8DBSODlU1JKyaRSF07O5W9HXeMl7PKRIOH3/5qBwwqEkmoPCCa+zJCmcorlxS8qm8RROrV5n
tV4R/y6E8CakyWksUiSsbC+26kOjSnofQngbApBcONSrsTEwPkMmhVNGstxidXYKp1b0NZpoNO+7
b8Q9yrNQOOHrC40qSUH0Ve5Vl6NwakfZFF8llGbI5RRO645SLQLLutb/miHHK3cSlRQnRM9A4YQk
WfzZEZ7OkJpYkcIJHrUonPBKAPHl20up4w28bcgXMh9I4WTOkKRwKp14jlI4xciSMJZpj0x6riCH
Ju378FJDxkoo8JIc1OTLK+ctH47L5iFSOJXeZ42G8ghTXspy3z3J9wY8o8HOsJC0ph9+EMsCeOPc
J+eFKZxqUzaNoHBC2ahlb92ba2JlkWJW7Z2Jwum2DqOy+bGz53goeHcghPRWrDT+7J8O9ri9Fv+9
xeDTxa5y2Vj5TXg8/HvOqRgAZ8/cpdDn245hAdpHbsnlk/NSFE7tKZvGUji134dsX8X2nNTbSZiU
RKgUTii7LOJWR5EKSTJSOF0oN9luLusf7iQz8eqUXkRKojNoa+KxTQonok1uQM8hiFKQwoloAnoP
QVQNyATBYEwQPcF+yARBEAzIBEEQBAMyQRAEAzJBEAQRw/8BL3sZo9+y8MIAAAAASUVORK5CYII=

--nextPart2380152.vYc0GPUKhN--

0
Mark
2/14/2014 2:19:32 AM
Steve Gibson was heard to say :

[...]
>>---------------------------------------------------------------
> I think that grouping in sets of four is clearly the right thing
> to do.

> 3684 6024 6268 3012 5835 = 66.438 bits (10^20)
> ... is both a lot of security, and VERY easy on the eyes.

Yes, adding some rhythm to the encoding is the right thing to do.

Simple grouping helps:
    3551 9003 9194 53
    96855 32412 05577
Symbols to break groups may also help visually (a lot):
    074-3990:9810-6823:9597
Mimic some known system (guid):
    48882825-7763-1703-021447862301
Modified GUID:
    4888:2825-7763-1703-0214:4786:2301
Telephone number:
    +51 (565) 382.59.59
    +94 (883) 328.78.06

And we could keep creating rhythms ....

I am fond of the simple phone numbers, but two of them will have space to 
store 24 decimal digits: 10^24 ~ 2^80 or ~80 bits. The point I like is that 
them could be written in any telephone directory for a long time and raise 
no suspicion as to be some sort of keys. Something like:

   Dr. Repair Keyboard   Phone: +51 (565) 382.59.59 and +94 (883) 328.78.06

> And if we were to stay with digits, but add ONE more group:
> 4649 7294 0572 6382 1739 6453 = 79.726 bits (10^24)

> Your thoughts??

That's it. Let's close the issue. :-)

-- 
Mark Cross @ 02/13/2014 7:17 p.m.
A person is just about as big as the things that make them angry.
0
Mark
2/14/2014 4:02:16 AM
On Thu, 13 Feb 2014 15:02:39 -0800, Sam Schinke wrote:

> 
> How high a percentage of desktops do you suppose don't have a webcam?
> Just curious.
> 
> Regards,
> Sam

In my case, 4 desktop machines 0 webcams so 100%.
But there again there is 0 MS Windows, 0 touch screens, 0 wi-fi & 0 cell 
phones so I am a seriously oddball guy.

-- 
dave_k
0
dave_k
2/14/2014 10:09:06 AM
On 2014-02-13 15:07, Mark Cross wrote:
> Sam Schinke was heard to say :
>> On 2014-02-12 10:15, Steve Gibson wrote:
>> [...]
>>> 4649 7294 0572 6382 1739 6453 = 79.726 bits (10^24)
> [snip]
>> As an arbitrarily chosen for instance: If the cipher is 128 bits, and
>> our use of SCrypt provides a 1:2^20 slowdown ratio to search the
>> "emergency code" keyspace compared to searching the cipher's keyspace
>> directly, then our emergency code should be ~108 bits.
>
> A really dislike that statement. That is a saying that we must, absolutelly
> use 128 bits, that users must "remember" a 27 lower character string or a 38
> decimal digits long number, something like:

/remember/store/

FTFY.

>      35519003919453628479685532412055777387
>      07439909810682395974888282577631703021
>      44786230148328875175156503825959148940
>      94883328780688295806870616503533595840
>      93827657765252258224992381722523646038

Or store an 8-9 word diceware phrase, yeah.

> Do you expect user to keep in memory for several years any of those lines?

No. I don't expect a user to "remember", via organic memory, even 
something short like "7FA1952F", having been shown the code once by some 
authentication program a few years previously. Seriously. Do you 
remember the last 2FA code you input for a login?

I am saying that this length is a calculated length for a password/code 
used to derive a key to provide security equivalent to the cipher 
strength. That is all.

Using a passcode equivalent to the cipher strength used to secure the 
IUK is the correct approach, IMO. The IUK is planned to be used very 
infrequently, and will only need to be decrypted to revoke or recover an 
identity. It will be quite impossible for anyone but a savant or someone 
with eidetic memory to memorize even a 50-bit code one day and recall it 
perfectly several years later, having had no reason to use it in the 
intervening time.

And 50 bits, IMO, is not a sufficient security guarantee. The encrypted 
IUK will be travelling along with every non-customized SQRL instance, 
with only the strength of the pre-generated pass-code to protect it.

A shorter passcode for the MK for daily use is an acceptable convenience 
tradeoff, but the encrypted IUK's passcode is intended for long-term, 
secure, storage. The MK cannot do as much as the IUK, and compromise of 
the MK is fixed by using the IUK.

> Do NOT start an argument that such number is not going to be remembered, but
> printed, that is an issue of a diferent post, discuss such point there.

You go argue what you like, where you want to argue it, and I'll argue 
what I like, where I want to argue it. Your habits of telling people 
what to discuss, and where to discuss it is a waste of everyone's time.

We are expressly *not* asking that such codes be remembered, but that 
they be recorded in some permanent fashion.

> And:
> Some world facts:
> 1.- Summing the joint power of all the 500 fastest in the world we get a
> number like: 250,080,467.17 Gflops (250E15 flops), just see the image:
>      http://www.top500.org/statistics/perfdevel/
>
> 2.- That to perform a "code trial" many computer cycles are needed, needed
> to run the algorithm steps, one by one, every time.
>
> 3.- If all 500 fastest computers join together to break a 128 bit code, and
> we assume 1 trial per flop, it will take them about 1E14 years (one full
> universe age from the big bang) to break it. Make your calc or use:
>       http://www.grc.com/groups/sqrl:5103
>
> Really? Do you believe such level of protection is required?

If it isn't, why aren't we still using 64-bit symmetric encryption? Or 
3DES? If we are choosing a cipher with N bits of security, it is trivial 
to obtain that specific level of security by not weakening critical 
parts of the algorithm in question.

> I have no problem to use 128 bit, 256 bit or as RSA demands: 1k, 2k or 4k
> keys, that is NOT my point. As long as it is computers, networks and
> transistors doing the hard work I have no issue with such long numbers.
> Common computers: do your job, work for me !!
>
> But as sson as you cross the line to "wetware" (humans) the burden falls
> into direct, clean, simple "human hands". And it is in such hands that long
> passwords are a burden and not a help, it is there where a 39 digit long
> number is just maddness, not reasonable paranoia protection.
>
> Average human memory could not cope with such numbers, don't try to explain
> or justify that, there is no possible description to try that.

I completely agree. I'm just puzzled where you get the idea that 
"memory" is going to be involved in the emergency access/recovery codes.

> Average humans should be confronted with no more than about 10 - 20 chars
> long passwords. If your system fails to do so, then choose to print, store
> in a file, insert in a image to be scaned later on,or any other user helper
> to remember the code.
>
> Because, in the end, if users can't use the system, then there will be no
> users to serve.

If users can successfully enter Microsoft's product codes every couple 
years, at 25 single-case alphanumerics (with spacing and a checksum for 
each chunk), I am quite confident we'd be able to figure out a way 
they'd be able to enter a 40-digit decimal sequence, or 9 diceware 
words, or a hexadecimal string equivalent to a single IPv6 address, or 
scan a QR code, or pretty much whatever.

>> I wouldn't expect
>> the ratio of SCrypt's slowdown to change hugely in the future -- if
>> someone can speed up SCrypt by 100%, it stands to reason that they can
>> probably also speed up their other brute-force strategies by at least as
>> much.
>
> It very well may, Sam. Scrypt is limited by memory access speed. OCB is
> limited by AES speed, which in turn is limited by computer core CPU
> processing speed. Those are related but not follow the same speed increase
> tendency.

Right -- the tendency in speed increase, AFAICT, is that memory 
increases in speed slower than processing power. Sure, I doubt that is 
some fundamental physical rule or law, but I'd be fairly comfortable 
expecting increases in processing speed to increase as fast as increases 
in memory speed/bandwidth.

Speeding up AES is something that can be done extremely trivially -- all 
of us probably have hardware that perform AES calculations in silicon. 
AES is specifically designed to be easy and cheap to perform in 
hardware, so pumping out massively parallel AES ASIC's would be 
relatively quick and relatively cheap (and also relatively energy 
efficient).

Regards,
Sam
0
Sam
2/14/2014 10:30:58 AM
In article <ldjitu$1tr1$1@news.grc.com>, sschinke@gmail.com says...
> 
> On 2014-02-13 6:57, Alan Cameron wrote:
> > In article <ldh01p$fqs$1@news.grc.com>, sschinke@gmail.com says...
> >>
> > NIP
> >> I would vote for making the number of digits irrelevant by offering to
> >> export the "Emergency Code" graphically, as a QR code with the
> >> digits/letters/words printed below for the odd time where something to
> >> read QR codes is unavailable.
> >
> >> We are already exporting SQRL identities as QR codes, so the capability
> >> to both export and import said codes must already be a given. Entering
> >> manually is just a fall-back option.
> >
> > SNIP
> >
> > You appear to be forgetting the users who will be using dektops without
> > the ability to read QR codes.
> 
> You saw where I said "fallback option", right?

But that is not relevant if it is not possible
 
> To get a file onto a desktop that does not have the ability to read a QR 
> code necessitates some kind of binary file. FWIW, transfering a jpeg of 
> the QR code onto the desktop is actually a perfectly functional way to 
> do this.
> 
> Any system that can parse a jpeg file can parse it for embedded QR codes.

Granted but the key is thst the QR code is an optical method of storage.
If printed it provides a relatively secure storage method. I understood 
the point was to use the exporting of the QR code as a means of re-
entry.

> That said, the idea behind storage as QR codes is to avoid the SQRL data 
> being in a format that may become spontaneously mobile, as it were. 

Do not understand spontaneously mobile.

> Storing SQRL credentials on a USB drive is reasonably similar, but you 
> have to make sure you aren't using that USB drive for unsafe things.

> How high a percentage of desktops do you suppose don't have a webcam? 
> Just curious.

I have no idea but would guess over 70%

Regards

-- 
Alan Cameron
0
Alan
2/14/2014 10:48:51 AM
On 2014-02-13 13:13, Mark Cross wrote:
> Sam Schinke was heard to say :
> [...]
>> I think for convenience of entry, lower case letters is best. On an
>> "entropy per key-press", the shift-key is only worth a single bit at best.
>
> Yep, "a single bit", but "a single bit" per letter. Thus a 10 letter code
> has 10 bits more if the shift-key is relevant, Duh!.

Per-letter is approximately the same meaning as per key-press.

If you type a 10-character, lower-case string, you have done so in 10 
key-presses. eg:
asdfghjkla

If you type a random 10-character, mixed-case string, on average you are 
capitalizing half the characters, so pressing shift 5x:
AsDfGhJkLa

That is 15 keypresses, or 5 extra keypresses for 10 extra bits of 
entropy. So I was being stingy in my estimate, on average, the shift key 
would be worth two bits for each time you press it, as the times you 
*don't* press it are indeed also worth entropy.

But I'm still comfortable with the approximation -- it is a succint 
explanation that gets the idea across, namely that using mixed-case to 
double the input set does not double the entropy.

And "Duh" yourself.

>> Words only really help when a predictive
>> keyboard is involved -- and even those usually don't try to autocorrect
>> inside "password" fields.
>
> Then, "words" is pretty much an empty proposal, it carry no intrinsic value.
>
> Thus: lets forget about them.

I don't know. I think they are worth keeping in consideration. They type 
very easily and smoothly on a real keyboard. Trying to enter random 
globs of letters is slow and tedious, but copying words seems much 
easier/smoother.

Regards,
Sam
0
Sam
2/14/2014 10:51:33 AM
This is a multi-part message in MIME format.
--------------060803040008010506010203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 2014-02-14 2:48, Alan Cameron wrote:
> In article <ldjitu$1tr1$1@news.grc.com>, sschinke@gmail.com says...
>>
>> On 2014-02-13 6:57, Alan Cameron wrote:
>>> In article <ldh01p$fqs$1@news.grc.com>, sschinke@gmail.com says...
>>>>
>>> NIP
>>>> I would vote for making the number of digits irrelevant by offering to
>>>> export the "Emergency Code" graphically, as a QR code with the
>>>> digits/letters/words printed below for the odd time where something to
>>>> read QR codes is unavailable.
>>>
>>>> We are already exporting SQRL identities as QR codes, so the capability
>>>> to both export and import said codes must already be a given. Entering
>>>> manually is just a fall-back option.
>>>
>>> SNIP
>>>
>>> You appear to be forgetting the users who will be using dektops without
>>> the ability to read QR codes.
>>
>> You saw where I said "fallback option", right?
>
> But that is not relevant if it is not possible

I don't think you are understanding what I am saying at all. Anyways, 
I'll re-summarize, but please re-read above. I'm not sure how I've been 
unclear.

What I am suggesting is printing a card (or saving a .jpeg) with two 
representations of the access code. One textual, and the other a QR 
code. The QR code will be useful in situations where keyboard entry is 
non-optimal or difficult (mobile devices) and the text version of the 
access code will be available as a fall-back in situations where the QR 
code cannot be scanned.

I've attached an example as a mock-up. The QR code contains precisely 
the same text that is visible in the attached .png.

>> To get a file onto a desktop that does not have the ability to read a QR
>> code necessitates some kind of binary file. FWIW, transfering a jpeg of
>> the QR code onto the desktop is actually a perfectly functional way to
>> do this.
>>
>> Any system that can parse a jpeg file can parse it for embedded QR codes.
>
> Granted but the key is thst the QR code is an optical method of storage.
> If printed it provides a relatively secure storage method. I understood
> the point was to use the exporting of the QR code as a means of re-
> entry.

Right. And I'm not proposing that a QR code be the *only* medium 
included with a default export of the access code.

Though we will likely have QR codes representing the full backup of a 
SQRL identity, and *these* will almost certainly be too long to enter 
accurately by hand (~1000 bits?).

However, without the access code, it is fairly safe to store those 
backups digitally -- a QR code just has a durability advantage (IMO).

>> That said, the idea behind storage as QR codes is to avoid the SQRL data
>> being in a format that may become spontaneously mobile, as it were.
>
> Do not understand spontaneously mobile.

If the access code is stored digitally, it can be lost or duplicated 
without the owner's awareness. It is harder to do this with a physical 
asset.

>> Storing SQRL credentials on a USB drive is reasonably similar, but you
>> have to make sure you aren't using that USB drive for unsafe things.
>
>> How high a percentage of desktops do you suppose don't have a webcam?
>> Just curious.
>
> I have no idea but would guess over 70%

Hmm, alright. I guess if you count computers in offices that might be a 
reasonable number. Most home users I know have a webcam, though they may 
not use it all the time.

Regards,
Sam

--------------060803040008010506010203
Content-Type: image/png;
 name="1392376574-4709.png"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="1392376574-4709.png"

iVBORw0KGgoAAAANSUhEUgAAAQUAAAEFCAYAAADqlvKRAAAAAXNSR0IArs4c6QAAAARnQU1B
AACxjwv8YQUAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAhfSURBVHhe7d0BVtpKAIbR9C1HWE7R
5QDLKXQ54HZ8kwCSXwum7by8APf2cGpFQxKSjwnOsd/eigbg6J/j3wAdUQCCKABBFIAgCkAQ
BSCIAhBEAQiiAARRAIIoAEEUgCAKQBAFIIgCEEQBCKIABFEAgigAQRSAIApAEAUgiAIQRAEI
ogAEUQCCKABBFIAgCkAQBSCIAhBEAQiiAARRAIIoAOHbW3H8eBK+fft2/OjxDHkqhuyfMZ/S
WuvjeZ8OIwUgiAIQRAEIogAEUQCCKABBFIAgCkC4yclLU5vsMcQtbletCUVDtsvzPh1GCkAQ
BSCIAhBEAQiiAARRAIIoAEEUgHC3k5dqTbwZotb61Hoqam37mIeG5306jBSAIApAEAUgiAIQ
RAEIogAEUQCCKADB5KUKxpzEMuZkmFt8rHt93sdkpAAEUQCCKABBFIAgCkAQBSCIAhBEAQgm
L1Uw5iSWWttV62kfc7se+Xkfk5ECEEQBCKIABFEAgigAQRSAIApAEAUg3O3kpam510k+tZ4L
z/t0GCkAQRSAIApAEAUgiAIQRAEIogAEUQDCTU5euldDnooxJy9NbTn3amKnoJECkEQBCKIA
BFEAgigAQRSAIApAEAUgTG7yEtfVmiw0RK0JRQ6x22KkAARRAIIoAEEUgCAKQBAFIIgCEEQB
CP7buC/4zULX3eu21zrGpnY8D2GkAARRAIIoAEEUgCAKQBAFIIgCEEQBCP7buC/UmpxTazm1
jLk+U3usIaa2PmMyUgCCKABBFIAgCkAQBSCIAhBEAQiiAIS7/c1LYy6nljHXZ2r7cMhyhpja
Oo+57bUYKQBBFIAgCkAQBSCIAhBEAQiiAARRAMLkJi/VMmTSyBBj7p5a61zL1LZ9yPqMuQ/v
9NQxUgCSKABBFIAgCkAQBSCIAhBEAQiiAISbnLw05sSkMSfV3OtyhhjyWEPc634ek5ECEEQB
CKIABFEAgigAQRSAIApAEAUg3O1vXrpXtSYLDVFrcs4QtQ7DW9w/UzsFjRSAIApAEAUgiAIQ
RAEIogAEUQCCKABhcpOXxpx8MjW1JsMMUetpH3NyTq3Hmto+nBojBSCIAhBEAQiiAARRAIIo
AEEUgCAKQLjJyUu3OGnkFrdrzEk+JhRNh5ECEEQBCKIABFEAgigAQRSAIApAEAUg3O3kpVqT
YYaotT5jbtfU1nnIcoa418cak5ECEEQBCKIABFEAgigAQRSAIApAEAUgmLxUQa31qfVUmMBz
3ZjHxhBT2z9GCkAQBSCIAhBEAQiiAARRAIIoAEEUgGDyUgW11mfMp2Jq+6eWe92uMRkpAEEU
gCAKQBAFIIgCEEQBCKIABFEAwt1OXpqaMbfLBJ7rau2fIdt+i8ezkQIQRAEIogAEUQCCKABB
FIAgCkAQBSDc5OSle1VrMkwtYx4aU5vkc6/7eQgjBSCIAhBEAQiiAARRAIIoAEEUgCAKQJjc
5CXg/2WkAARRAIIoAEEUgCAKQBAFIIgCEEQBCKIABFEAgigA4bGisH3ufiHn59tzs+3u/nzf
c3tHz+lrPn7+ZL+ed/fP1/vjZ47isefN+e59s56fH6+79RZ+Wt7p1n/ca+v71bbkcs/rU2Mf
lIU38/4y5uuylQdD1+vT/js6ff+l+/l7jxWFxab7zbn922bRfn7RtH+1Zqvd5/vfbZvtdla+
fFb+/nhGbJvncrC+NMtmNTt+6qQNwvNrs9odl7t5albzQ4hOFpvzY76dHrScXC/bRbM7fn5X
Frx9zu+7tr6X7mtPvHlvuW9vu2bZW+c/3wdFu63zbbM4bWu57Rbb5qV3Ev96+Vf230lZ9vNr
ea4u3U8Vj335UE66dTnAV8s46i8rJ8F2tmiW5etn7cfHTx8smk17Aiyfjv8+27++ljNh0Xw/
HcxdhF6b169e7GbLZrdbNqdvm30vjzvk+67aNutV06x+nJf7W67ug3Jil5f9xeZDZJa7sl++
erTL+++gjKjWZdnLP1xvBnvoKGzL2bFfLOMAvqZ9ZZwtvjez2ffyalVOroFD2NlTOdD3+3I6
9+1LLI4fFudhdf/S4oNSg33z1Dz9zVlRHrR92O3Lefjev1z5ytV90C27BG9gY3/Hfv3SrJ42
H0Yt/BceOArtMLh90c6jbL/qX2v3hurHUcWie7mfNd/LGHa//fl+rXxVuWzZlCF0Ozw+LHfd
vL6f2LNm2R9qt6/iHy4tDg6vlLPV8v1Sp3VxfYtf3teFpazSj+NjlgectcPy3jf+8T44Lvsr
19b5l9rLqNVTs1GEUTxsFPbrdRkGr5qPVw55vbt5PwH3P7fNvncJ0A3l99vm56AqtF04LbO9
LZunC983K8PjRTlN2mD1bZ/nzar8+fFhWHNpfVuX7+uNNrpX/HI+965J/qt9cHJtnT8rMXxZ
NU+br76OWh40Cu119f43rk/3zc9tOfL3q/O76vNy6VH+bH/3jGh11+IXhtndEHxWLjmO/y7a
S4vn11W8v/DHSg3+7H2JAfuge6/kc9D+zmt75RWXV+WpO4w2ej/VoJ6HjEI3Srh0Uv7Kdl0O
xNn5pwfHW/vTgP2qXdbvOLwZd7oMaEcA/cvy7n2O91fjw48rqwWh1Y0MeifycdsOlwRXDNoH
i2bZ/YQkt6n7acfA918+O7wBeX7MXffTiW60UWufkMqOfjCbt3IyvpWD6vjvs3LJevHz7fj/
s8OyDncdPm53af/WLW+3eisHb37uZLOIry9H+9v7vR/vO92O63JpfVvX7vu4Pv1N+7t9cFBC
kevb26bL63Vl/4XdW4nC5W3jr/nFrUB46B9JAp+JAhBEAQiiAARRAIIoAEEUgCAKQBAFIIgC
EEQBCKIABFEAgigAPU3zLwwNkN1kWWh7AAAAAElFTkSuQmCC
--------------060803040008010506010203--
0
Sam
2/14/2014 11:21:37 AM
[for the unabridged version, see Sam Schinke's post above]

> I hope that doesn't mean re-writing all of the various OCB 
> implementations to allow decryption without a tag. The last
> time I had a look, the tag was pretty central to the API's.

The good news is, OCB's auth tag is entirely separate.

We know this because Phil talks about how users can choose to 
use whatever "tag length" they decide they need simply by paying 
attention to n-bits of the computed value.

I haven't yet looked at the APIs of the various implementations, 
but I expect them to easily support zero tag lengths.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/14/2014 4:30:49 PM
In article <ldku7e$2jdi$1@news.grc.com>, sschinke@gmail.com says...
> 
SNIP

> I've attached an example as a mock-up. The QR code contains precisely 
> the same text that is visible in the attached .png.

Not visible in these groups.
 
SNIP

>>> How high a percentage of desktops do you suppose don't have a 
webcam?
>>> Just curious.
>>
>> I have no idea but would guess over 70%

> Hmm, alright. I guess if you count computers in offices that might be 
a 
> reasonable number. Most home users I know have a webcam, though they 
may 
> not use it all the time.

My original estimate may be very wrong in either direction but office 
users of desktops far outnumber home users by a long long way the 
statistics are in the numbers of users of Windows.

I am one of the home users who has not got a webcam on my desk and 
although I have a laptop the camera is disabled permanently by choice.

I do not have a 'smartphone' nor ever will. Even my Kindle Fire HDX's 
camera is permanently disabled as is the location thingy.

I do not fully understand the text at the top of your original post but 
am unable to discuss it seriously so will leave it be.

Regards
-- 
Alan Cameron
0
Alan
2/14/2014 6:36:27 PM
Alan Cameron was heard to say :

> In article <ldku7e$2jdi$1@news.grc.com>, sschinke@gmail.com says...
>> 
> SNIP
> 
>> I've attached an example as a mock-up. The QR code contains precisely
>> the same text that is visible in the attached .png.
> 
> Not visible in these groups.

Go to:

      http://www.12078.com/groups/sqrl:5186

or 

      http://www.grc.com/groups/sqrl:5186

In a browser and download/see/get the attachement !!


> SNIP


-- 
Mark Cross @ 02/14/2014 3:59 p.m.
Age has its advantages. Too bad I can't remember what they are.

0
Mark
2/14/2014 8:00:50 PM
In article <1613097.KWhqMIlY86@rnqqfki.new.org.invalid>, none@127.0.0.1 
says...
> 
> Alan Cameron was heard to say :
> 
> > In article <ldku7e$2jdi$1@news.grc.com>, sschinke@gmail.com says...
> >> 
> > SNIP
> > 
> >> I've attached an example as a mock-up. The QR code contains precisely
> >> the same text that is visible in the attached .png.
> > 
> > Not visible in these groups.
> 
> Go to:
> 
>       http://www.12078.com/groups/sqrl:5186
> 
> or 
> 
>       http://www.grc.com/groups/sqrl:5186
> 
> In a browser and download/see/get the attachement !!
> 
> 
> > SNIP

I did not know these were available. Thanks.

How do you post to them?

-- 
Alan Cameron
0
Alan
2/14/2014 8:25:30 PM
Alan Cameron was heard to say :

> In article <1613097.KWhqMIlY86@rnqqfki.new.org.invalid>, none@127.0.0.1
> says...

>> Go to:
>> 
>>       http://www.12078.com/groups/sqrl:5186
>> 
>> or
>> 
>>       http://www.grc.com/groups/sqrl:5186
>> 
>> In a browser and download/see/get the attachment !!
>> 
>> 
>> > SNIP
> 
> I did not know these were available. Thanks.
> 
> How do you post to them?

They are automatic for ALL posts in this NNTP server, both are front-ends to 
present the posts in HTTP, one was done By SG (the grc.com site) and the 
other was done by an old contributor here, with SG permission and blessing: 
Dutch (the 12078.com site).

Just search for the X-URL header in all posts raw source.

-- 
Mark Cross @ 02/14/2014 4:37 p.m.
A mistake is simply another way of doing things. — Katherine Graham

0
Mark
2/14/2014 8:42:12 PM
Sam Schinke was heard to say :

> On 2014-02-13 13:13, Mark Cross wrote:
>> Sam Schinke was heard to say :
>> [...]
>>> I think for convenience of entry, lower case letters is best. On an
>>> "entropy per key-press", the shift-key is only worth a single bit at
>>> best.
>>
>> Yep, "a single bit", but "a single bit" per letter. Thus a 10 letter code
>> has 10 bits more if the shift-key is relevant, Duh!.

We are "saying" exactly the same. But you are not even understanding what 
you say.

Now you are going to demostrate that the following first sentence is wrong.
You do it all alone witout any help, and yet, at the end, you don't realize 
what you have just done. Truly Amazing:

> Per-letter is approximately the same meaning as per key-press.
> 
> If you type a 10-character, lower-case string, you have done so in 10
> key-presses. eg:
> asdfghjkla
> 
> If you type a random 10-character, mixed-case string, on average you are
> capitalizing half the characters, so pressing shift 5x:
> AsDfGhJkLa
> 
> That is 15 keypresses, or 5 extra keypresses for 10 extra bits of
> entropy. So I was being stingy in my estimate, on average, the shift key
> would be worth two bits for each time you press it, as the times you
> *don't* press it are indeed also worth entropy.

So, it is proven that per-keypress (2 bit of entropy) is exactly diferent 
than per-character (1 bit of entropy). Or is there a new math in which 1 is 
equal to 2?.
 
> But I'm still comfortable with the approximation -- it is a succint
> explanation that gets the idea across, namely that using mixed-case to
> double the input set does not double the entropy.

And yet, you do not understand what you just wrote:
       > If you type a random 10-character
       > ... for 10 extra bits of entropy.

Exactly, perfectly exactly: what I wrote.


Why are we wasting bits, time, and effort in this nothingness .... Amazing.


> And "Duh" yourself.

But of course:

Everytime I find your useless comments, long discussions of "no content", I 
have to Duh myself and just repeat: It is just Sam again, Duh !!!   <sigh>
 
>>> Words only really help when a predictive
>>> keyboard is involved -- and even those usually don't try to autocorrect
>>> inside "password" fields.
>>
>> Then, "words" is pretty much an empty proposal, it carry no intrinsic
>> value.
>>
>> Thus: lets forget about them.
> 
> I don't know. I think they are worth keeping in consideration. They type
> very easily and smoothly on a real keyboard. Trying to enter random
> globs of letters is slow and tedious, but copying words seems much
> easier/smoother.

An aditional useless twist of words. It was YOU who said:
         Words only really help .....

And thus discarding them yourself, Duh!


-- 
Mark Cross @ 02/14/2014 5:01 p.m.
History has shown there are no invincible armies. — Joseph Stalin

0
Mark
2/14/2014 9:02:56 PM
Sam Schinke was heard to say :

[...]
> Fair enough. All you had to say was that your comment was from direct
> experience or knowledge.

All you had to do was: ASK.

-- 
Mark Cross @ 02/14/2014 5:03 p.m.
If we aren't supposed to eat animals, why are they made with meat?

0
Mark
2/14/2014 9:04:25 PM
On 2014-02-14 13:02, Mark Cross wrote:
[...]
> Everytime I find your useless comments, long discussions of "no content", I
> have to Duh myself and just repeat: It is just Sam again, Duh !!!   <sigh>

Sorry, Mark, I'm really not interested in playing your game.

I can see it was a mistake to try (once again) to engage you in 
discussion. Even if I try to confine my comments entirely to the 
technical, it is inevitable that you will decide some thing or another 
that I have written is sufficient excuse for you to resume with whatever 
you want to call the above nonsense.

It is certainly of no value to me, and I doubt it is of value to anyone 
else. Basic civility is absolutely not too much to ask, even, or dare I 
say especially, when intending to correct someone.

Peace out.

Regards,
Sam

0
Sam
2/15/2014 7:49:51 AM
In article <69649527.6NNP8MXeNK@rnqqfki.new.org.invalid>, none@127.0.0.1 
says...
> 
> Alan Cameron was heard to say :
> 
> > In article <1613097.KWhqMIlY86@rnqqfki.new.org.invalid>, none@127.0.0.1
> > says...
 
> >> Go to:
> >> 
> >>       http://www.12078.com/groups/sqrl:5186
> >> 
> >> or
> >> 
> >>       http://www.grc.com/groups/sqrl:5186
> >> 
> >> In a browser and download/see/get the attachment !!
> >> 
> >> 
> >> > SNIP
> > 
> > I did not know these were available. Thanks.
> > 
> > How do you post to them?
 
> They are automatic for ALL posts in this NNTP server, both are front-ends to 
> present the posts in HTTP, one was done By SG (the grc.com site) and the 
> other was done by an old contributor here, with SG permission and blessing: 
> Dutch (the 12078.com site).
 
> Just search for the X-URL header in all posts raw source.

I still am puzzled about attachments are they automatic as well.
I thought attachements to these newsgroups were forbidden by Steve.

-- 
Alan Cameron
0
Alan
2/15/2014 10:54:01 AM
On 2014-02-15 2:54, Alan Cameron wrote:
[...]
> I still am puzzled about attachments are they automatic as well.
> I thought attachements to these newsgroups were forbidden by Steve.

There is a size limit of 20KB on posts, which AFAIK serves the purpose 
of limiting attachments (as well as post size!).

"Attachments" aren't forbidden, but posting executable attachments, or 
active exploits (or file formats known to have serious security 
problems) is most certainly frowned upon.

Regards,
Sam
0
Sam
2/15/2014 12:46:37 PM
In article <ldnniq$12ge$1@news.grc.com>, sschinke@gmail.com says...
> 
> On 2014-02-15 2:54, Alan Cameron wrote:
> [...]
> > I still am puzzled about attachments are they automatic as well.
> > I thought attachements to these newsgroups were forbidden by Steve.
> 
> There is a size limit of 20KB on posts, which AFAIK serves the purpose 
> of limiting attachments (as well as post size!).
> 
> "Attachments" aren't forbidden, but posting executable attachments, or 
> active exploits (or file formats known to have serious security 
> problems) is most certainly frowned upon.
> 
> Regards,
> Sam

See previous posts to which Mark replied on how to see an attachment.
My question was how were they made to the sources that Mark quoted?

-- 
Alan Cameron
0
Alan
2/15/2014 3:57:05 PM
Alan Cameron was heard to say :

> In article <69649527.6NNP8MXeNK@rnqqfki.new.org.invalid>, none@127.0.0.1
> says...

>> Alan Cameron was heard to say :
>> > In article <1613097.KWhqMIlY86@rnqqfki.new.org.invalid>, none@127.0.0.1

>> >>       http://www.12078.com/groups/sqrl:5186
>> >>       http://www.grc.com/groups/sqrl:5186
>> >> 
>> >> In a browser and download/see/get the attachment !!

>> > I did not know these were available. Thanks.

>> > How do you post to them?
  
>> They are automatic for ALL posts in this NNTP server, both are front-ends
>> to present the posts in HTTP, one was done By SG (the grc.com site) and
>> the other was done by an old contributor here, with SG permission and
>> blessing: Dutch (the 12078.com site).
  
>> Just search for the X-URL header in all posts raw source.
 
> I still am puzzled about attachments are they automatic as well.
> I thought attachements to these newsgroups were forbidden by Steve.

Yes, they are automatically presented in the HTTP page.

SG has NOT forbiden attachements, just asked to avoid (where possible) using 
them. The biggest issue is that some news reader apps post images in pieces 
when a big image wants to be posted. There appear 10 or 15 posts for all the 
pieces of the image. That is a no-no action.

-- 
Mark Cross @ 02/15/2014 2:12 p.m.
If crime fighters fight crime and fire fighters fight fire, what do freedom 
fighters fight? — George Carlin
0
Mark
2/15/2014 6:19:32 PM
On 2014-02-15 7:57, Alan Cameron wrote:
> In article <ldnniq$12ge$1@news.grc.com>, sschinke@gmail.com says...
>> On 2014-02-15 2:54, Alan Cameron wrote:
>> [...]
>>> I still am puzzled about attachments are they automatic as well.
>>> I thought attachements to these newsgroups were forbidden by Steve.
>>
>> There is a size limit of 20KB on posts, which AFAIK serves the purpose
>> of limiting attachments (as well as post size!).
>>
>> "Attachments" aren't forbidden, but posting executable attachments, or
>> active exploits (or file formats known to have serious security
>> problems) is most certainly frowned upon.
>>
>> Regards,
>> Sam
>
> See previous posts to which Mark replied on how to see an attachment.
> My question was how were they made to the sources that Mark quoted?

I saw two questions/uncertainties there, but only answered one.

The answer to the other one is the same as for anything on the grc.com 
domain: Steve has a computer configured to perform those tasks.

"news.exe" is some old news gateway program that Steve runs so that 
newsgroup postings can be browsed on https://www.grc.com. Those links to 
individual can also be seen in some places in this format:
https://www.grc.com/x/news.exe?cmd=article&group=grc.sqrl&item=5197&utag=

In particular, via the Services->Newsgroup Discussions menu on most of 
the pages at https://www.grc.com.

eg: https://www.grc.com/groups/sqrl

Regards,
Sam
0
Sam
2/17/2014 8:11:07 AM
Reply:

Similar Artilces:

Many, many, many thanks ! ! !
Name: Marco Email: margiu42atyahoodotit Product: Firefox Summary: Many, many, many thanks ! ! ! Comments: I use Mozilla Firefox from many yars: it's very easy and usefull. Many, many, many thanks. Marco Browser Details: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 From URL: http://hendrix.mozilla.org/ Note to readers: Hendrix gives no expectation of a response to this feedback but if you wish to provide one you must BCC (not CC) the sender for them to see it. ...

many many many crashes
Name: Pete Email: messagedeskatcomcastdotnet Product: Firefox Summary: many many many crashes Comments: I'm sure you already know this, but I'm about to quit Firefox, which I previously loved. It is crashing multiple times a day on two very very different computers. I have a desktop with winXPpro and a laptop with vista home prem. I use different firefox profiles for each computer for different uses. On both computers firefox is crashing on an almost hourly basis. It is very aggravating and reduces my productivity. I keep hoping your next fix will stop ...

many many many bugs!
Name: Don Van Dyke Email: dvandykeatncdotrrdotcom Product: Firefox Summary: many many many bugs! Comments: 1. Memory leaks - - I shut it down but it still runs 128 MB of memory and I can't re-start it till I kill the process in task manager 2. Pop-up blocker exception list does not work. I made exception but it still blocks the excepted site 3. Asks stupid question "Do you really want to navigate awayfrom this site" when I have clicked a link. OF COURSE I WANT TO NAVIGATE AWAY THAT IS WHY I CLICKED THE LINK! 4. Ignores mouse clicks for no apparent ...

One to many to many to many...
Hi all, I have an issue which i come up against on a regular basis and never solve it the same way twice... The issue is related to "one to many" table relationships and extracting data from multiple tables (more than 2)  As an example, say i had the following tables: WebsitesPagesFormsControls where a website has many pages, each page has many forms, and each form has many controls. Assuming I have a business object library with a class for each table, and a property in each representing the collection (and therefore the one to many relationship). My question is simply...

One-to-many and many-to-many mappings
I tried some examples of many to many relation tables, but it doesn't work - i expected some kind of check box field or something similar for connecting  fields of two table. Also I encountered some difficulties with one-to-many relation.Best way to describe my problem is to write down my db shema:Table Continents:ContinetIDNameTable TripsTripIDContinentIDNameDescriptionTable PricesPriceIDTripIDDescriptionPriceSo, trip is connected with one continent, and can have many prices. When I try to run this db with dynamic data web I have empty Prices table, without ability to add new price...

many many many crashes recently
Name: Kevin Gregg, Network Security Analyst, Infination Technology Research Email: kevinatinfinationdotcom Product: Firefox Summary: many many many crashes recently Comments: Hello to whom it may concern: I have had firefox crash on me very often the past couple of months and I have a relatively secure small network and am also rather knowledgeable as I have been in the IT/Security arena for a decade and a half. I ask that you please advise me regarding the multiple times that I have had Firefox crash on me on multiple boxes (the windows ones primarily, of course w/ UNI...

Many-to-many table
How do you call the table that connects two entity tables, so they form a many-to-many relationship? PivotTable?Johan TheunissenMCPD, MCSE, MCTS BizTalk 2006==============================Please mark the most helpful reply/replies as "Answer". http://en.wikipedia.org/wiki/Junction_tableSteve Wellens My blog...

Many to Many form?
I'm trying to copy a number of rows of several columns from one table to a separate table. Basically, I'm trying to archive data from one year from an active table to an archive table. I have about 4000 rows a year to archive. I there any way I can do this in Infomaker forms, or do I have to learn Powerbuilder?...... The data pipeline is your best bet. You need to create two database profiles, one pointing to the source database and one to the destination database. If both tables are in the same database, you only need one db profile. Just step through the dialog boxes...

Many-to-Many in CDM
Hi Group In a CDM adding a many-to-many relationship creates a table to resolve the many-to-many. This behavior presents a problem for early stage diagrams, e.g. a Key Entity model. How can I get PD to show a many-to-many relationshp relationship symbol? TIA Randy, I'm not clear on the question you ask, as you mention CDM and table (a PDM concept) in the same sentence. Is your issue for a CDM or the resulting PDM after transformation? BTW, I'm also not clear what a "Key-Entity: model is; is this a PDM (where keys are defined) or CDM (where entities are d...

Many to Many relationship
Hi, I have 2 tables a solution set table and a solution subset table. Each solution set can have multiple subsets and each subset can belong to multiple solutions sets. Eg.   Solution Set - NAC Sub sets are   Firewall                      Emailsecurity  Solution Set - Content Security Sub sets are Proxy                     Email Security   I have a 3rd table wh...

Many to Many Listboxes
Hi  My Problem is i need to select from one listbox and update the other listbox i.e  Listbox1 = Available users and Listbox2 already selected users, to add or remove users from a particular role / group. on submit i want to then update an sql server table with the values from Listbox2   Many thanks Dave davemills: Hi  My Problem is i need to select from one listbox and update the other listbox i.e  Listbox1 = Available users and Listbox2 already selected users, to add or remove users from a particular role / group. on submit i want to then update an...

Many to many replication
Hi, Having an issue replicating a many to many relationship. All tables in the relationship are in the publication. Extraction and Synchronisation give me exactly the result sets in the remote databases that I am after, but if I start replicating transactions the parent tables aren't getting replicated. tbl1 --< tbl2 >-- tbl3 where tbl1 data is subscribed to by a a tbl3 value. Insert into tbl1 and then into tbl2 with an existing value in tbl3 as a single transaction. Run dbremote at consolidated, then run dbremote at replicates and only the insert into tbl2 ...

How many threads is too many?
We're currently in the process of stress testing an application (that has been working fine up till now) under a heavy load. The maximum number of threads is set to 2000. However, long before it reaches this (at about 400, I think) it produces an error "java.lang.OutOfMemoryError at java.lang.Thread.start(Native Method)..." and the component (a service component which was pulling queries off a queue and firing off threads to deal with them) dies. Is there anything else in the jaguar server configuration we should be looking at to solve this, or is it unreasonable to ex...

many to many relationships
I'm pretty new to reporting software and databases... I need to one report pulling from 3 tables, all of them having a SSN field. 2 of the tables have multple entries for SSN b/c they keep track of transactions. The other table is an employee table. I know that i cannot really use the two tables with multple SSN's because it'll give me a lot of useless information, and so I tried to join them with the employee table, which has unique SSN's. But that joins the other two tables to one another through the employee table, and so it gives me a bunch of redundant numbers to...

Web resources about - How many bits? - grc.sqrl

Bits of Freedom - Wikipedia, the free encyclopedia
Bits Of Freedom is an independent Dutch digital rights foundation, which focus on privacy and communications freedom in the digital age. The ...

Technology - Bits Blog - NYTimes.com
The Bits blog from the New York Times reports on the technology industry, including start-ups, the Internet, enterprise and gadgets

NYT Bits Blog (@nytimesbits) on Twitter
Sign in Sign up You are on Twitter Mobile because you are using an old version of Internet Explorer. Learn more here NYT Bits Blog @ nytimesbits ...

BITS 2014 on the App Store on iTunes
Get BITS 2014 on the App Store. See screenshots and ratings, and read customer reviews.

Little Bits
jurvetson posted a photo: TED Fellow Ayah Bdeir introduces littleBits, a set of simple, interchangeable blocks that make programming a craft, ...

Interpreters and Compilers (Bits and Bytes, Episode 6) - YouTube
This animation explains the difference between interpreters and compilers. It is from Episode 6 of the classic 1983 television series, Bits and ...

Bits of black bear found in Chinese medicine
Some Chinese medicines contain potentially poisonous plants, unlabelled ingredients and bits of endangered animals, a study has found, prompting ...

Where Hollywood Sees Art, Silicon Valley Sees 'Bits & Bytes'; Who's Winning?
... in the past, AllThingsD&#39;s Kara Swisher tells TheWrap&#39;s Sharon Waxman at TheGrill Where Hollywood sees art, Silicon Valley sees bits, ...

Gen Z's Data Obsession: Bits and Bytes Are the New Commodity
... is not expensive, the real cost of entry into the mobile market can be attributed to data. In a hyper-connected mobile-everything world, bits ...

Mobile Game Roundup: Unkilled, Fishy Bits and More
Mobile Game Roundup: Unkilled, Fishy Bits and More

Resources last updated: 12/12/2015 4:06:59 AM