100x100 SQRL Logo   Secure Quick Reliable Login
A highly secure, comprehensive, easy-to-use replacement
for usernames, passwords, reminders, one-time-code
authenticators . . . and everything else.
SQRL Secure Storage System (S4)
Secure Storage?
“Secure Storage” in this context means that data can be optionally encrypted for privacy, but whether or not encrypted, any alteration of stored data can be reliably detected. In cryptographic terms, this provides authenticated encryption with associated data (AEAD).

SQRL clients require both offline and online storage security:

AES-GCM: “AES/Rijndael - Galois/Counter Mode”
SQRL v1 obtains both robust data encryption and decryption verification (wrong password, error and tamper detection) through its use of the industry standard AES-GCM “authenticated encryption” (AE). Unlike earlier authenticated encryption schemes which either applied a MAC (message authentication code) to the encrypted data, or applied encryption to data that already had a MAC authentication, the AES-GCM performs both operations at once and does not require the use of separate keys for each aspect of the operation.

AES-GCM has been adopted by NIST (National Institute of Standards and Technology). It is present in the IPsec (IP Security) specification and participates in the TLSv1.2 security suites, where it is supported by Firefox and Chrome and recent releases of OpenSSL.

Because all of SQRL's other cryptography is in the public domain, GRC has produced and provides a reference implementation of AES-GCM whose source code is released without any usage restrictions of any kind into the public domain. It was written in platform-neutral 'C' and should be easily compiled for use with SQRL. Included in the source distribution are NIST's six files of algorithm validation test vectors, a PERL utility to compile them into a single binary, and a test harness (gcmtest.c) which validates GRC's implementation against NIST's 47,250 individual test vectors.

Note: After this work was finished the reference LibSodium cryptographic library has added AES-GCM to its suite of security tools. Since SQRL uses LibSodium for several other functions, using the AES-GCM functions from LibSodium now makes the most sense.

Consequently, the individual blocks contained within SQRL's secure storage system are encrypted and authenticated with AES-GCM using a 256-bit key derived from SQRL's EnScrypt algorithm.

SQRL's S4 system uses NULL initialization vectors (IV) for its type 2 and type 3 blocks. AES-GCM, like many block cipher modes using a keyed symmetric cipher, employs an initialization vector nonce. To provide guaranteed privacy, this nonce does not need to be secret, nor even random, but it does need to never repeat under the same key. For its type 2 and type 3 blocks, SQRL's S4 storage system meets this requirement using an implied and fixed initialization vector of all zeros (NULL) because those blocks' AES-GCM encryption keys are never reused when the block is changed and re-encrypted. As detailed below, The type 1 and 2 blocks are keyed by SQRL's Scrypt-based EnScrypt function, which has its own 16-byte random salt. This results in the use of a unique encryption key every time the block is encrypted. The type 3 block is keyed by the identity master key (IMK) which is also derived from a random process and is never reused. The type 1 block does use a randomly obtained IV to allow re-encryption under a new IV after user-interface plaintext settings have been changed and a new matching authentication tag must be created.

Efficient, compact, binary-friendly, future-proof SQRL client storage
The trend, exemplified by XML and JSON data structure description languages, reduces information storage density and efficiency in favor of embedding structural descriptive flexibility. Bundling an application's data description metadata into the data can simplify dissimilar system inter-operation by allowing the data to effectively describe itself. And in today's world of terabyte storage and gigabit communications, the cost of embedding inter-operation metadata is offset by interconnection robustness.

But an excess of metadata makes little sense for SQRL's offline static data storage where long term storage robustness and retrievability are the overriding priority. SQRL exports long-term statically encrypted secrets in future-proof printed paper form,so fewer bits means that each bit can be larger. Fewer characters means that each character can be larger. Few bits means there's more room for stronger error correction with its larger overhead, etc.

However, notwithstanding the previous, today's storage format must also provide for future change and expansion. The following format, while simple and minimal, addresses and meets all of these needs.

SQRL's Secure Storage System (S4) Encrypted Key Sample
{scrypt random salt} – update for password change16 bytes
{scrypt log(n-factor)} – memory consumption factor1 byte 
{scrypt iteration count} – time consumption factor4 bytes
{option flags} – 16 binary flags2 bytes
{hint length} – number of chars in hint1 byte 
{pw verify sec} – seconds to run PW EnScrypt1 byte 
{idle timeout min} – idle minutes before wiping PW2 bytes
{encrypted identity master key (IMK)}32 bytes
{encrypted identity lock key (ILK)}32 bytes
{verification tag} – 16 bytes
{length = 73}2 bytes
{type = 2} – rescue code data2 bytes
{scrypt random salt}16 bytes
{scrypt log(n-factor)}1 byte 
{scrypt iteration count}4 bytes
{encrypted identity unlock key (IUK)}32 bytes
{verification tag} – 16 bytes
{length = 54, 86, 118 or 150}2 bytes
{edition >= 1} – count of all previous keys2 bytes
{encrypted previous IUK}32 bytes
{encrypted next older IUK (if present)}32 bytes
{encrypted next older IUK (if present)}32 bytes
{encrypted oldest previous IUK (if present)}32 bytes
{verification tag} – 16 bytes

SQRL's Secure Storage System (S4) incorporates the following features:

Backward compatibility and forward growth
The final version of this page will specify the v1 design of GRC's S4 for its reference SQRL client. All SQRL clients wishing to interchange SQRL identities must fully comply with this simple and straightforward specification. Though this specification is not complex, the following easily enforced characteristics provide significant future growth and backward compatibility:

S4 Database header
SQRL's eight-byte ‘sqrldata’ file signature indicates that S4 format blocks follow and the alphabetic case of the signature indicates whether the balance of the file is straight binary or 6-bit base64url encoded. The eight-byte header stands alone and does not participate in the authenticated encryption of the blocks that follow.

S4 Block types
To enhance interoperability between SQRL clients by different authors on different platforms, SQRL standardizes the following three block types which are understood by GRC's reference client:

  • Type 1: Password PBKDF spec., plaintext data and encrypted identity keys.
  • Type 2: RescueCode PBKDF spec. and encrypted identity unlock key.
  • Type 3: Encrypted previous identity unlock keys.
SQRL keeps two classes of secrets—user access password and emergency RescueCode—so we define one data structure to contain the data required by each secret class:
Since no identity should logically contain more than one instance of each block type, no client should ever generate an identity having more than one Type 1, 2 and 3 block. Any client encountering an identity containing more than one of either type should reject the entire identity as suspicious and invalid. Clients wishing to tolerate aberrant identities may choose which one of the duplicated block types to honor.
Expounding on expansion
• Some observers have suggested that peripheral features of the underlying SQRL protocol, such as the use of GRC's proposed EnScrypt PBKDF should remain separate. This S4 database format provides for the addition of any other type of password authentication by leaving all other block types open and available. And the compact representation of this database leaves ample room for future parallel authentication or alternatives.

• If SQRL should evolve in the direction of a form-fill application, that private and probably encrypted data could occupy currently undefined block types without duplicating any of SQRL's existing data. A future encrypted and authenticate block could implicitly infer the use of, for example, the encryption parameters obtained from the existing type 1 block.

Changes & Updates

Secure QR Login (SQRL) Documentation:

Jump to top of page
Gibson Research Corporation is owned and operated by Steve Gibson.  The contents
of this page are Copyright (c) 2016 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy.
Jump to top of page

Last Edit: May 31, 2017 at 15:10 (28.02 days ago)Viewed 10 times per day