Anyone who is already well-versed in standard crypto will be familiar with the meaning of the terms in the first section of this glossary. However, those who do not spend their days working to foil the plans of bad guys may appreciate a quick refresher on the meaning of these standard terms:
AEAD Cipher – “Authenticated Encryption with Associated Data” – most encryption modes do not also verify that the message has not been altered. An AEAD cipher performs encryption while simultaneously verifying that the message has not been changed. The “with Associated Data” feature allows in-the-clear plaintext to be included within the authenticated block so that it, too, is protected.
AES-GCM – “Advanced Encryption Standard Galois/Counter Mode” – AES-GCM is an authenticated encryption with associated data (AEAD) cipher. It employs Rijndael/AES encryption in counter mode to produce a pseudo random stream which is XORed with the plaintext or with the ciphertext to produce the other. It simultaneously provides authentication of the entire message with additional non-encrypted data.
ASIC – “Application Specific Integrated Circuit” – Unlike a CPU which is general purpose and programmable with software, an ASIC is designed for a specific purpose. In the context of cryptography, this is usually a chip used to dramatically increase the performance of a fixed “number crunching” task such as hashing input data. Because they are purpose-designed, they are typically the fastest solution, though also the most expensive.
Authentication – The terms “identification” and “authentication” are technically distinct. The first identifies, and the second, often separately, authenticates the possibly-inaccurate identification. As we’ll see, SQRL securely and inseparably identifies and authenticates. Therefore, this text will use “Authentication” to describe both processes.
FPGA – “Field Programmable Gate Array” – An FPGA falls in between a software programmable CPU and a fixed-purpose ASIC. It is firmware-programmable hardware. It can be reprogrammed as needed and it will dramatically outperform a general-purpose CPU, but its “generality” makes it larger (and therefore more expensive) and also slower than ASICs.
Multifactor – If a single factor is insufficiently specific or reliable for identifying an individual, multiple differing factors may be used to increase the overall identification reliability and assurance.
Nonce – Short for “number used once” – In cryptography, there are many places where the reuse of some critical data must never be allowed to occur. For example, when eavesdropping could occur, the answer to a question might be overheard. So, if the same question were ever asked again, it might be correctly answered, not by someone who actually knew the answer, but by someone who overheard the question and its answer the first time. Secure cryptographic systems use “nonces” so that they never ask the same question twice.
PBKDF – “Password Based Key Derivation Function” – Any mathematical process that takes a variable-length password string and returns a fixed-length key. The function must have the property that whenever it is given the same password it will return the same key. Any cryptographic hash function meets this requirement. However, modern PBKDF functions typically incorporate “salt” to create per-user versions of the PBKDF and add complexity to deliberately slow down their operation or to add other features, such as ASIC and FPGA acceleration resistance.
SALT – Cryptographic systems use the slang term “salt” to refer to any data added to a hash or other cryptographic function which provides additional randomization to, or customization of, an otherwise uniform and standard function.
QR Code – “Quick Response Code” – A square, computer-readable graphical barcode which has been widely standardized and adopted for the visual communication of small pieces of textual or binary information.
SCRYPT – Scrypt (pronounced “ess-crypt”) is a “memory hard” PBKDF (see above) which was deliberately designed by Colin Perceval to thwart the acceleration capabilities of ASIC and FPGA devices by requiring that a large block of RAM memory be committed to each PBKDF operation. Large blocks of RAM memory is not something that any custom hardware devices have in the required quantity, nor are likely to anytime soon.
URL – “Universal Resource Locator” – Since it would be possible for someone not to know that a URL is that funky string of characters we type into our web browsers to access web pages and to download files, and since SQRL is all about URLs and has them coming and going, it seemed useful, if only in the interest of completeness, to make sure that no one would confuse URLs for the Urals, that famous mountain range running longitudinally through Western Russia. We just wanted to be sure.
The development of SQRL required the invention of new ideas and several bits of technology. They needed naming so they could be described and discussed. You might find that scanning though these SQRL-specific definitions will be useful as an introduction to the descriptions on the pages that follow.
Alt-ID – Alternate Identity – SQRL automatically provides a single unique “native” user identity to every website. But there may be an occasion when a SQRL user wishes to be appear as someone else. SQRL’s built-in Alt-ID facility allows any number of named alternate identities to be used.
Ask – Provides a means for a website to present its SQRL user with any high-security question and to receive their SQRL-signed authenticated reply, completely bypassing the hack/attack-prone web browser interface.
CPS – Client Provided Session – When the SQRL client resides in the same machine as the browser being signed into, SQRL provides the authenticated session received from the webserver over SQRL’s secure channel directly to the web browser. This has the highly desirable effect of making the system utterly immune to all forms of spoofing and man-in-the-middle attack.
Cross-Device Sign-in – SQRL sign-in webpages display QR code versions of their authentication URLs. This allows a SQRL client in a smartphone (for example) outside of the computer being signed into to scan the QR code and perform the authentication. This is termed “cross-device” sign-in as opposed to “same-device” sign in.
EnHash – Hash functions take a variable-length input and produce a fixed-size output. They are designed with a “security margin” which reflects a tradeoff of security vs performance. Previous cryptographic hashes are fallen to time as analytical and computational resources have improved. SQRL’s use of hashing is not time sensitive but it is extremely security sensitive. SQRL uses a compound iterative hash function for extreme security margin.
EnScrypt – The use of SQRL clients is protected by their SQRL password which is used to decrypt their stored SQRL identity file. Being a local password exposes it to brute force attacks. To harden SQRL clients against such attacks, SQRL iterates the memory-hard acceleration-resistant Scrypt PBKDF function to significantly further slow down its operation so that a single password decryption attempt requires many seconds.
Identity Lock – To prevent identity abuse, SQRL’s identity lock prevents a website account’s SQRL identity from being changed once it has been set. Only a higher level of authentication, provided by the identity’s “Rescue Code”, provides the information required to unlock a website’s SQRL identity for removal or replacement.
IMK – The “Identity Master Key”, derived from the IUK, is always stored encrypted and is briefly decrypted, when needed, by the user’s SQRL password. When decrypted, it keys the HMAC256 which hashes the authentication domain (from the website’s URL) to produce the per-site public/private key pair.
IUK – The “Identity Unlock Key” is obtained randomly when the user’s SQRL identity is created. It is always stored encrypted and is decrypted by the identity’s Rescue Code. In SQRL’s key hierarchy, it is the antecedent of the identity’s IMK and has a number of highly-privileged roles including password reset and identity unlock.
MSA – “Managed Shared Access” – SQRL defines, and the SSP API fully supports, the management of multiple SQRL identities which can be used to access a single website. Since SQRL identities are not readily shared, this provides a well-managed solution which is normally solved by unmanaged “credential sharing.”
NUT – In homage to its namesake “squirrel”, the SQRL system uses the term “nut” for its cryptographic nonces.
QuickPass – SQRL users should use a long and strong local password to unlock their encrypted identity. But that becomes harassment if they’re required to constantly reenter that password every time they reauthenticate to another website. SQRL uses a “QuickPass” to allow just the first ‘n’ characters (by default, 4) to be quickly reentered after their whole password has been used once. “Guessing” is not allowed, and a mistakenly entered QuickPass will then require a full password reentry.
ReKeying – SQRL strongly protects the secrecy of its user’s master key. But accidents happen. So SQRL also provides a built-in “rekeying” facility to allow its users to replace a stolen or believed-compromised key when necessary. It is meant to never be needed, but it’s there if needed.
Rescue Code – SQRL’s Rescue Code is a randomly-obtained 24-digit value used to encrypt the user’s most privileged key. It is never needed during normal use of SQRL, but it can be used to reset a forgotten SQRL password or rekey a user’s identity which is believed to have become compromised.
S4 – “SQRL Secure Storage System” – To support the features needed, and to enable seamless indentity sharing among SQRL client, the SQRL specification fully defines the binary format and content of the binary object which holds the user’s preference settings and operational keys.
Same-Device Sign-in – When the user has a SQRL client or web browser extension installed in their machine, they click “Sign in with SQRL” to trigger authentication. Since they are signing into the browser which is running in the same machine as their SQRL client, this is referred to as “same-device” sign in.
Secure Single-Factor – Since SQRL both identifies its user to the web server, and robustly verifies its user’s identity with strong cryptographic assurance, it functions as a secure single-factor identity solution with nothing, no additional identification assurance “factors,” required.
SQRL Identity – For the sake of convenience, the term “SQRL Identity” is used interchangeably to refer to both the single master identity the user creates for themselves just once, and to the per-site identity which descends from that master identity. The user works with their master SQRL identity, whereas website receive a “per-site” SQRL identity which is unique to for each user and each website. The specific sense of SQRL identity being referred to should always be clear from its context.
SQRL Password – The user’s master SQRL identity is always encrypted. Therefore, their password is required to decrypt their identity to RAM memory for use. Keeping the SQRL identity encrypted protects it from theft and abuse, and requiring the password before SQRL’s first use prevents someone other than its proper user from coming along and logging in with someone else’s SQRL identity.
SSP API – The “SQRL Service Provider Application Programming Interface” completely abstracts away all aspects of the SQRL protocol management, placing it behind the SSP API. The SSP API exposes a simple, private, HTTP query/response interface to dramatically reduce the work required to add SQRL support to any new web server.