Support for the SQRL protocol generally imposes minimal requirements and burdens upon web servers. When signature verification is performed by compiled code, many hundreds of thousands of verifications can be performed per second per core on any contemporary processor. The elliptic curve public key cryptography chosen for use with SQRL (Bernstein's Ed25519) has been optimized for high performance, and is far less burdensome than traditional RSA-style “products of primes” cryptography. Elliptic curve crypto is faster because it uses much shorter keys which, in turn, are as safe or safer than longer RSA keys because the discrete logarithm problem employed by elliptic curve crypto is believed to be much more difficult to solve, for a given key length, than the RSA prime factorization problem. Thus, faster-to-use shorter ECC keys deliver the same strength as longer slower-to-use RSA keys.

Although SQRL's cryptosystem design is believed to be unassailable, various man-in-the-middle spoofing-style attacks are possible if simple precautions and checks are not performed by the web server. The guidelines below will assist the developer in implementing an SQRL system to deliver the strongest web server authentication available.

Mitigating “phishing” man-in-the-middle (MITM) attacks:
Although the SQRL identity authentication login system does not promote itself as an anti-phishing solution, observers have hoped that, in addition to everything else it does, it might also be able to provide some relief from this classic Internet problem. As it turns out, the SQRL authentication architecture does present a significant opportunity for thwarting phishing attacks when SQRL is used in its “same-machine” login mode. Please see the Anti-phishing countermeasures page for a full examination of SQRL's anti-phishing countermeasure capabilities.

The value of SSL/TLS encrypted & authenticated SQRL link URLs:
Imagine for a moment the scenario of a SQRL-equipped web server that always posts exactly the same SQRL code to every login page. It just shows the one code over and over to every visitor who logs in. Although individual users would be uniquely identified as themselves, the same SQRL link URL would always generate the same SQRL ID query to identify its user. Therefore, if a malicious third-party were ever to obtain one of those queries, they could readily impersonate the compromised user at any time in the future simply by replaying the previously obtained query. That's not good.

This method of compromise is well known as a “replay attack” and it is something that cryptographic protocol designers are always careful to consider and guard against. The SQRL system actively prevents replay attack exploitation by (a) keeping bad guys from snooping and (b) never using the same SQRL link URL twice.

The SQRL protocol strongly recommends that all SQRL client login queries be performed over SSL connections which offer both privacy through strong encryption, and authentication of the destination web server. As with standard SSL login using a username and password, SSL provides very strong protection against an eavesdropper obtaining a SQRL login query. However, SQRL stops short of making SSL a hard requirement so that websites having lower security requirements, and lacking the ability to receive SSL connections, may still utilize SQRL login. (Note that such sites don't provide their visitors any login security and protection even without SQRL.)

Unpredictability of the server's “nut”:
In addition to preventing eavesdropping on the user's SQRL login query, the web server can render eavesdropping replay attacks less effective by generating unique SQRL link URLs that never repeat. These will, in turn, generate unique SQRL client login queries that also never repeat. And not only should SQRL link URL's by non-repeating, they should also be highly unpredictable to prevent a highly sophisticated attacker from guessing (or calculating) any future value of the link. (Even though it's not completely clear what such a hypothetical attacker would do with that knowledge. It's comforting to know they can't determine what it would be.)

The sample strategies provided below achieve these goals easily, cleanly, and securely:

Before a web server displays a visitor login page containing an SQRL QR code and link, it may establish some pre-login state information which is retained for some length of time (until the login page ages and expires), or it might not establish any pre-login state until a user submits their login form data or uses the SQRL code to identify and authenticate themselves. SQRL is adaptable to either scheme.

As was mentioned briefly above, SQRL QR code and link data is inherently exposed on the web site's login page. To protect itself from login-state-guess attacks, and to guarantee that SQRL clients have unique SQRL links to sign, SQRL-login websites must provide a cryptographic-strength unpredictable and never-repeating “nut” to assure that every link is unique. Depending upon whether the server's logic is stateless or stateful, the nut's value may be derived from a one-way cryptographic hash function such as SHA-1, or from a two-way reversible cryptographic cipher such as AES.

A server that creates some pre-login state when the user asks for a login page and an accompanying SQRL link URL is generated might simply obtain some random noise from the local system, hash it through SHA-1 to destroy any structure it might have. This 160-bit token would then be stored in the server's pre-login state and perhaps added to a list or otherwise made indexable so that it can be located when the matching SQRL query arrives. Since SQRL web servers must compare the initial login request IP to the authenticating IP, when both connections are over SSL, the pre-login state must also save the login requesting IP. That 160-bit data would then be passed through a base64url function to convert the resulting 160-bits into URL-friendly ASCII. (Remember to remove any trailing (“=”) equal signs padding the end of the string.) This ASCII would then form the server's “nut” added to the SQRL link URL after the “?” in order to render a unique link.

A server that does NOT create pre-login state will likely wish to encrypt some necessary connection IP and sanity-checking parameters into the server's nut:

• Connection IP: To help prevent the most common phishing and man-in-the-middle (MITM) attacks, the web server must compare the IP to which the SQRL QR code and link is sent with the IP of the machine that submits the identity authenticating query. Since this is a stateless login, the initial user IP must be enclosed in the server's nut. Since ISP caching proxies may mask their customer's true IP addresses, the IP address should only be stored if the login page and SQRL link are sent over a cache-bypassing SSL connection. Hopefully, login page content will be delivered over SSL connections. An IP address of 0.0.0.0 can be used to indicate that the user's login requesting IP address is unknown when the web server is not using SSL to display the login page contents.
  
  IPv4 and IPv6: Although this 128-bit total nut size only provides 32 bits for an IPv4 IP address, our purpose is only to perform a match/no-match comparison to detect same-device phishing attacks. Therefore, any 128-bit IPv6 addresses can be safely “compressed” to 32 bits by hashing the full IPv6 IP with a secret salt and retaining the least significant 32 bits of the hash result. The hash's salt can be the same AES key being used to encrypt and decrypt the nut.
• UNIX-time Timestamp: Including the readily available one-increment-per-second UNIX time both provides a steadily changing value and creates a simple timestamp that can be used to “sanity-check” the returning query. A very stale authentication query can be rejected, with the user asked to refresh their login page. And any alteration of the encrypted nut's value, when decrypted, will almost certainly result in impossible times in the future or far in the past which can be easily detected and discarded.
• Up Counter: A simple 32-bit up-counter that can be allowed to wrap, and/or can restart at zero after a reboot, is a low-cost means for guaranteeing that even if multiple login pages are requested and delivered in rapid succession, each will have a differing count value. This value can also be used as a quick sanity-check since returning decrypted values should never be greater than the counter, nor should they be too much smaller that the counter's current value. Anything hacking attack that alters any of the encrypted nut's 128-bits would likely result in a wildly incorrect count value after decryption, this quickly failing any sanity checking.
• Some Pseudo-Random Noise Since the previous three components are somewhat predictable, and could be at least partially under an attacker's control, something unpredictable and completely uncontrollable, such as entropy generated by the local machine, should also be added to the pre-encrypted nut. Although it cannot be verified after decryption, its presence within the nut renders any sort of attack on the nut's encryption (which was already far beyond unlikely) virtually impossible.
• A 1-bit source flag: It might be useful for the server to know whether any incoming SQRL “nut” was originally obtained from an optical scan of a QR code or from a clicked link. Since this is readily spoofable it cannot be relied upon for security-related decisions. But it is simple to include and might be handy.

The parameters described above are intended to serve as suggestions and guidelines only. They are certainly not hard and fast rules. Anything a web application might need can be accommodated by altering or expanding upon the concepts above.

Once a 128-bit block of parameters have been assembled, a 128-bit block cipher, such as AES (Rijndael), can be used to reversibly encrypt the block to yield the SQRL link's directly related, but indecipherable, 128-bit nut. The AES key could be made static or it could be chosen at random after each server boot, but it should remain secret and internal to the web server. (Note that this same secret key can be used to salt the IPv6-to-IPv4 converter hash function.) The 128-bit binary nut should then be converted to ASCII using a base64url encoder, and the two trailing (“==”) equal signs should be removed before it is added to the SQRL link URL. Those two trailing (“==”) equal signs should be later appended before the returned nut is decoded back into binary by a base64url decoder.

Once the ASCIIized value for the link's nut is generated, the need for the optional path-extending “|” vertical bar character should be determined, and a SQRL login link can be created. The link URL could be fed into a QR code generator to create a PNG or GIF (not JPG) format QR code image. That image should be wrapped in a standard HTML clickable <a href="url">qrcode.png</a> HREF tag so that smartphones can optically scan the QR code for cross-device authenticated login, while users of smartphones, tablets, laptops and desktops can tap or click on the image to perform the same function.

</////  Still working on this part . . .  /////>