Cyber Security Techniques for Web Sites

Overview

Digital information security is multi-faceted, from data protection with encryption for safe transmission between locations, to client and server physical security, encrypted databases, and the use of VPNs. The human factor is critical as users may download malware or ransomware from USB devices, or click on email links to fake Phishing sites that steal personal information, and infect visitors with malware.

Multi-factor authentication can be used to mitigate human error, such as requiring an extra mode of identification when logging in. This may be accomplished by sending an email or a text message to a phone, where those end-points have been previously set up by the user.

A single weak link compromises the entire system. Wired LAN cables can be tapped into, WiFi is subject to eavesdropping, and on the Internet, Man-In-The-Middle (MITM) attacks can hijack traffic. Rogue sites may infect clients with malware such as Denial of Service bots, and Screen-scrapers and Keystroke loggers can record personal, credit card, and health data.

The focus in this article is on avoiding over-the-wire security issues that can be addressed in web pages. But computer security is absolutely necessary on the Internet, so computers must employ Anti-Virus software like the free AVG software from http://free.avg.com/us-en/free-antivirus-download, shown in this screenshot:

Browsers are the standard way to access the internet, and JavaScript is the de facto browser programming language. So, contrary to some assertions Internet security must include JavaScript, and in fact the W3C has been working on a web cryptographic API.

First, determine the security level needed, as well as the secrecy of your information. This can range from a minimum of using unsecured 3^rd party computers and Internet connections at Internet Cafes and copy shops, to using Virtual Private Networks (VPNs), and employing secure, physically protected hardware that’s only accessible in areas protected with biometric safeguards such as iris scanners or keycards.

On the Internet, client-side browser-based encryption of transmitted information improves security, without depending on the security of servers, connections, or Certificate Authorities (CAs ), all of which are increasingly being compromised. The use of certificates to make malware appear as legitimate software has grown 700% in the period 2012 to 2015, according to the November 2014 McAfee Labs Threats Report.

To protect user names and passwords from keystroke logger-snooping in browsers, mouse activated, on-screen graphical keyboards can be used, but with these take precautions against mouse event, and position, trackers. And on servers, storage of password related data and Personally Identifiable Information should be encrypted.

Historically, basic over-the-wire security has been achieved with Secure Sockets Layer (SSL) software, running on top of the TCP/IP protocol used to transport and route data over networks. A symmetric key algorithm - DES (Data Encryption Standard) - was used to encrypt data. SSL works below higher-level protocols like HTTP and IMAP, and encrypts and decrypts data sent over http. But this ‘https’ protocol using SSL over http is no longer secure, as readily available software can decode https traffic.

SSL has now been replaced by Transport Layer Security (TLS). And by the late 1990s, DES was also no longer secure, and a competition was held by the National Institute of Standards and Technology (NIST) to find a replacement for DES. As a result, the Rijndael symmetric-block cipher algorithm was chosen as the new Advanced Encryption Standard (AES).

Protecting Data Transmission

Data breaches have resulted in tens of millions of records being compromised. More than 20 million records with PII (Personally Identifiable Information) were stolen from the U.S. Government Office of Personnel Management (OPM), records at health providers Premera and Anthem (11 million and 80 million) were compromised, and the IRS was hacked. And before that, massive data breaches at Albertson’s and Target stores also showed the vulnerability of unprotected PII on the Internet.

These attacks emphasis the need for organizations to encrypt the data they are entrusted with, as the OPM, Target, and Anthem breaches were all traced back to credentials compromised by human error. But security technology vendors are also subject to attack, such as the hack at anti-malware security company Kaspersky Labs, which had similarities to the Stuxnet attacks on Iran that destroyed centrifuges used to enrich Uranium.

There are various aspects to computer security, including using secure hardware-based log-ins with technologies like iris scanning, and avoiding the use of vulnerable software such as Adobe Flash. And dual-mode authentication should also be employed, in which extra information is used to confirm users identities after the user name and password have been entered. For example, requesting users’ ‘Mother’s Maiden Name’, but that particular piece of information isn’t secure as it may be freely available.

Separate connection channels can be used for dual-mode authentication of logins. A web server can call a smart phone and deliver a code, a question to be answered, or data to be entered, or additional hardware-based login methods can be employed, such as biometric iris scans or fingerprints.

In the past, secure client-server Internet connections used the SSL https protocol to call web pages. But this is no longer secure as SSL uses legacy encryption that’s vulnerable to attack, and has been replaced by Transport Layer Security (TLS ). NIST describes TLS like this at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf in Special Publication 800-52 Rev. 1 of 05/2014:

“While SSL 3.0 is the most secure of the SSL protocol versions, it is not approved for use in the protection of Federal information because it relies in part on the use of cryptographic algorithms that are not approved. TLS versions 1.1 and 1.2 are approved for the protection of Federal information, when properly configured. TLS version 1.0 is approved only when it is required for interoperability with non-government systems and is configured according to these guidelines.”

And web pages called via https that access http pages aren’t secure - see http://en.wikibooks.org/wiki/Web_Application_Security_Guide/Insecure_data_transfer. The focus here is on encrypting data before Internet transmission (and for storage), rather than on human security factors. So don’t put your password on a sticky-note stuck on your computer screen!

There are several requirements at the core of secure data transactions:

1. Confidentiality - Encrypt text to make it unreadable
2. Integrity - Ensure text is tamper-proof - use Message Authentication Code (MAC)
3. Authentication - Content comes from trusted sources and the sender really sent the message
4. Perfect Forward Secrecy - Avoid future compromise with temporary, ephemeral encryption keys
5. Availability - Ensure timely and reliable access

The degree to which these features are implemented may vary due to performance considerations, and regulatory requirements. For example, Perfect Forward Secrecy (PFS) that ensures that if a secret key is compromised, it can’t be used to break either previously transmitted text blocks, or blocks transmitted in the future, has a performance penalty of, perhaps 15 - 27 % - see the tests at http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html.

Security feature implementation varies from one Internet security application and vendor to another. Available features also depend on the server and browser (and the versions) being used, and whether data is subject to Federal Information Processing Standards (FIPS).

There are three main types of cryptography:

1. Secret Key that uses the same key for both encryption and decryption,
2. Public Key where the freely available public key (which is exchanged via the Internet) is used to encrypt information and a Private key decrypts it, and
3. Hashing functions that irreversibly encrypt data, which is used to check message validity.
4. The Stanford JavaScript Crypto Library (SJCL) covered here, was written by Emily Stark, Mike Hamburg and Dan Boneh at Stanford University. And the Elliptical Curve Diffie Hellman (ECDH) key agreement protocol code described here is by Tom Wu from his work at Stanford University.

In practice, the shared-secret key encryption methods used in the SJCL example that follows, can be used by including the JavaScript library file, ‘sjcl-min.js’, in web pages. This file is in www.web2ria.com/widgets.zip.

Client-side JavaScript code employing the SJCL library in web pages, such as a login page, may then look something like the following:

From sender - sjcl.encrypt(‘secretSharedKey’, ‘plainTextToEncrypt’)

AND

To receiver - sjcl.decrypt(‘secretSharedKey’, ‘cipherTextToDecrypt’)

This requires both the sender and the receiver to securely store the ‘secretShared Key’, which can and should be different from a user’s password. A secret value may be exchanged with zero-knowledge methods such as Elliptical Curve Diffie Hellman (ECDH) for encryption keys, or the Secure Remote Password (SRP) protocol for passwords.

In the more general case, a TLS secure communications sessions between a sender and receiver, or client and server, might proceed as follows:

• Client opens session and checks server’s identity, e.g., X.509 public key certificate
• Server checks client’s identity
• Establish most secure mutually supported encryption suite
• Exchange asymmetrically encoded cryptographic set-up information encoded with server’s public key, including setup information for temporary, ephemeral symmetric encoding
• Switch to symmetric encryption on completion of asymmetrically encrypted set-up information exchange, and then send the message body
• After message is sent, discard ephemeral keys and close session
• Server checks integrity and decrypts message

The parties exchanging information employ Asymmetrical encryption for the initial handshake using the server’s public and private keys. This allows authentication of the client, the server, and exchange of encryption parameters.

But Asymmetrical encryption is several orders of magnitude slower than Symmetric encryption. So after the initial Asymmetric handshake, the actual message is encrypted and decrypted Symmetrically.

To encrypt the plain-text message, it’s split into equal length blocks, and with some encryption methods the last block is padded if needed to make it the standard length. PKCS7 padding is in whole bytes, and the value of each padding byte is the number of bytes added, e.g. a 3-byte pad would consist of 03 03 03. So for example, in a last message block needing a 4 byte pad, the last block might look as follows:

... | DD DD DD DD DD DD DD DD | DD DD DD DD 04 04 04 04 |

If the last message block is a full block long and no padding is needed for it, a dummy ‘padding’ block is added with each byte set to the full block length, so that the decryption software doesn’t remove part of the last block of the actual message, thinking it’s padding.

The SJCL library supports this type of encryption and several other types, such as ECC (Elliptical Curve Cryptography), and SRP that authenticates user passwords without sending them over the Internet when users log-in. The client and the server may be just two devices, such as a computer and a smart phone, a browser and a web server, or they may be peer-to-peer messaging applications. One party requests, and the other accepts, the session, and with SRP users’ passwords aren’t at risk by being transmitted. Once a password has been verified, an ephemeral, single-use encryption key is derived and a hash of this is used to encrypt and decrypt content. The mutually supported encryption suites are agreed on between the two devices / parties, for a particular browser / client and server.

Each line in the screenshot below shows an available supported cipher suite in the browser being used, in order of preference from the most secure to the least. The report shown in the screenshot shows lines consisting of the following items:

Key Exchange - Bulk Encryption & Key size - MAC & Key size

where MAC is the Message Authentication Code tag that’s appended to the end of messages. MACs are also used to ensure integrity of file systems.

The first line in the screenshot, ‘DHE-RSA-AES256-SHA256’, describes the TLS 1.2 cipher suite with PFS, that uses the DHE (Diffie-Hellman Ephemeral) key exchange algorithm, RSA authentication, AES256 message encryption with a 256-bit key, and the SHA256 (Secure Hash Algorithm) Pseudo-Random Function (PRF) hashing function with 256-bit long MAC, that’s seeded (or salted) from a shorter random number.

The DHE key exchange protocol allows two parties to establish a shared secret ephemeral key on unsecured public channels, for the exchange of cryptographic set-up information, thus ensuring PFS. It isn’t feasible for third parties to discover the secret, as the key can’t be computed in a reasonable amount of time with current technologies (as of 2018 ).

AES uses the Rijndael symmetric-block cipher algorithm with keys of 128, 192, or 256 bits, and fixed data block sizes of 128 bits for both input and output text. Elliptical Curve Diffie-Hellman (ECDH) uses elliptical curves to compute shorter, more secure keys than RSA - a 512-bit ECDH key is roughly equivalent to a 15,360-bit RSA key.

Elliptic curves have the property that adding two points on the curve, P and Q, yields a third point on the curve, R. The two communicating parties agree on a public elliptic curve C, from the list of curves defined by NIST, and a public point Q on C. The point Q is calculated as a multiple of the starting point, P, and Q = nP. An attacker might know P and Q but finding the integer, n, is a difficult problem to solve. Q (i.e., nP) is the public key and n is the private key.

With ECDH, points on the elliptical curve are used instead of the large random Prime numbers (N ), that are used with standard Diffie-Hellman. So the mod(N) calculations are replaced with Elliptical Curves values.

Diffie-Hellman Key Exchange

In the Diffie-Hellman key exchange, the two parties each use different secret random numbers (private keys ), x and y, and each party transmits the value of the public key (P) raised to the power of the private key, x or y. So the publicly revealed data is limited to the values of P^x and P^y. A sender generates a random 48-byte pre-master secret key, encrypts it with the receiver’s public key, and sends the encrypted pre-master secret to the receiver. The receiver decrypts this with its private key, and creates a shared master-secret with it.

The random number generator used must have sufficient ‘entropy’, or random variability, to provide enough randomness for secure cryptography, which the JavaScript Math.random() function does NOT provide. Physical processes such as users’ random mouse movements can be used to produce random x and y values, with a long enough time frame, of say 30 seconds.

A web service can provide random numbers, such as the one at http://www.unit-conversion.info/texttools/random-string-generator/, which generates downloadable random numbers and strings as needed. Another site, at www.fusionbox.com/mouseware/, uses mouse movements to randomize. And the SJCL library has random number generators.

Thus one party knows x and the value of P^y, and the other party knows y and the value of P^x, so both parties can calculate the shared key, P^(x*y), as both (P^y)^x = P^(x*y) and (P^x)^y = P^(x*y). So, as long as x and y remain secret, an eavesdropper can only know the values of P^x and P^y, and can’t compute the shared key. And, provided both x and y are temporary, ephemeral values, the shared key is also temporary and ephemeral.

Diffie-Hellman is used to send an Asymmetrically encrypted shared secret key, and a message is then sent that’s Symmetrically encrypted with the hash of the shared secret key. Passwords are hashed and compared to stored hash values, and they may be concatenated with a random, non-secret salt value before being hashed, and / or a user name. For example, Hash(Salt + Password + UserName), or better, Hash(Salt + Hash(Password + User Name )). Hashed Message Authentication Codes (HMACs) use a shared secret appended to the data being hashed, and are used in TLS.

Unique salts are concatenated with passwords to be hashed for different messages, so pre-computed hash tables of password values can’t be stored and used to crack password hashes. Whatever combination of values are hashed, the combination used must be agreed to by both parties initially.

So if a password, P, is ‘abc’, or hexadecimal 61 62 63, and an 8-byte salt S, ‘78 57 8E 5A 5D 63 CB 06’, is randomly chosen, the concatenated value P+S, written as P | S, is ‘61 62 63 78 57 8E 5A 5D 63 CB 06’. This is strengthened, or stretched, by repeatedly hashing it 1000s of times over with Password-Based Key Derivation Function 2 (PBKDF2) methods.

The Stanford SRP demo uses Hash(salt | Hash(UserName | ‘:’ | Password)) with 1000s of repeated hashes to increase the time taken to run brute force attacks. The colon (:) between User Name and Password makes each pair unique, and avoids hashing user name ‘timSmith’ and password ‘oldman’ the same as ‘timSmit’ and ‘holdman’. With no ‘:’, the string for both is timSmitholdman, vs timeSmith:oldman and timSmit:holdman with a ‘:’.

Two parties using Diffie-Hellman agree on a large prime number, ‘N’, and a smaller number ‘g’ that’s primitive with respect to N. g being primitive to N means that integers, ‘k’, can be found where (k = gⁱ mod N) for all the values of i from 1 to N-1. So g is primitive to N if the distinct values of k are also equal to all the integers from 1 to N-1.

The modulo ‘A mod B’, is the remainder of the first value A, divided by the second one B. The resulting set of k values for the formula (gⁱ mod N) with values N = 7 and g = 2, for i = 1 to i = (N-1), that is i = 1 to i = 6, is:

i            N    k

2¹ mod 7 = 2 { 2 / 7 = 0 + 2

2² mod 7 = 4 { 4 / 7 = 0 + 4)

2³ mod 7 = 1 { 8 / 7 = (1 x 7) + 1

2⁴ mod 7 = 2 { 16 / 7 = (2 x 7) + 2

2⁵ mod 7 = 4 { 32 / 7 = (4 x 7) + 4

2⁶ mod 7 = 1 { 64 / 7 = (9 x 7) + 1

This set of k values, 2,4,1,2,4, and 1, doesn’t include all the integers from 1 to 6. So g = 2 is not primitive to N = 7. But if N = 7 and g = 3, the k values for i = 1 to i = 6 are:

i            N    k

3¹ mod 7 = 3 { 3 / 7 = 0 + 3

3² mod 7 = 2 { 9 / 7 = (1 x 7) + 2

3³ mod 7 = 6 { 27 / 7 = (3 x 7) + 6

3⁴ mod 7 = 4 { 81 / 7 = (11 x 7 )+ 4

3⁵ mod 7 = 5 { 243 / 7 = (34 x 7) + 5

3⁶ mod 7 = 1 { 729 / 7 = (104 x 7) + 1

This time, all the integers of N from 1 to (N-1), computed from (gⁱ mod N), for i = 1 to i = (N-1), 3,2,6,4,5, and 1 match, so 3 is primitive to 7. In practical use, N is a large prime number, and either party can choose N and g, and then tell the other party what the chosen values are via normal unencrypted channels such as the Internet, as they aren’t secret.

Hash functions are one-way so it’s extremely difficult to derive the original string from the hash. A known and expected hash value for an encrypted message is compared to a newly computed hash value, to ensure validity, that it hasn’t been tampered with, and that it comes from a trusted source.

So if users pick passwords from the roughly 100,000 words in the English language, to crack a hashed password up to 100,000 hashes would have to be tried. But by taking the password and adding a 32-bit salt, the number of possible passwords are multiplied by the number of salts, as follows:

Password Possibilities          = 100,000

Salt Possibilities                   = 2³² (32-bit )

Hash calculations required  = Password Possibilities * Salt Possibilities

Hash calculations required  = 100,000 * 2³²

Hash calculations required  = 429,496,729,600,000

Seeded / salted strings are strengthened in this way to resist attacks that use pre-computed ‘Rainbow’ tables for reversing cryptographic hash function.

In CBC (Cipher Block Chaining ), each encoded text block depends for its content on the previous source text blocks. So identical individual blocks of plaintext never encrypt the same, and as there’s no data before the first block, a random Initialization Vector (IV) is needed to encode it. IVs should never be reused - new IVs randomly generated each time a message is sent ensure that even an identical message will encode differently.

Integrity checks are run on the tag that’s attached to the end of the message to ensure that it hasn’t been tampered with. And a shared secret key is required, as integrity checks do not ensure confidentiality.

Compression should not be applied since it’s vulnerable to being hacked, because compression replaces repeating character strings with smaller tokens. This allows attackers to guess content by looking at how compressed message lengths change, or do not change, when intercepted messages have different characters inserted into them.

A more extensive explanation of Cryptography can be found at www.garykessler.net/library/crypto.html#dhmath.

Using the SJCL Web Page

The Stanford JavaScript Crypto Library (SJCL) can be found on the web at http://bitwiseshiftleft.github.io/sjcl/demo/, and at www.web2ria.com by clicking the ‘Cyber Security’ tab, ‘SJCL Web Page’ submenu item. It demonstrates the functionality described in this chapter - see the following screenshot.

To use SJCL, you can use the default Plaintext, or enter text in the ‘Plaintext’ box in the middle column, and a password in the ‘Password’ box in the left column. By default, the CCM cipher mode is used (CCM is Counter with CBC-MAC, and CBC-MAC is Cipher Block Chaining-Message Authentication Code ), with a default 128-bit key size, and 1000 for the strengthening factor for each new password entered. By default, a new random IV is used each time a message is sent.

Encrypted messages are sent by clicking the red ‘encrypt’ down arrow. And then the plaintext message is deleted from its box and the encrypted message is put in the ‘CipherText’ box.

With the default settings, header fields are put in the CipherText box, which isn’t needed if the receiver has this data. Clicking on the blue ‘decrypt’ up arrow reverses the process.

With the defaults, resending the same message with the same password generates a new IV each time, so the CipherText is unique even for identical messages. Password strengthening slows down calculation, and a range of, say, 500 to 2500 produces acceptable results with minimal delays.

With the default settings, when a password changes a new random salt and key are generated when each message is sent, as well as a new random IV being generated for each message that’s sent. The key is computed from the password, salt, and strengthening factor, and its size can be 128, 192, or 256 bits, or a key can be typed in.

In the demo, the Cipher mode selected can be CCM or OCB2 (Offset Codebook Mode). OCB2 is more compact than CCM and a bit faster, but as it’s patented, its use is more restricted than CCM, and both cipher modes use AES encryption. As well as the fixed-length encrypted authentication tag that’s put in the message, optional ‘adata’ (Authentication Data) can be added to the headers. The text block returned then may look as follows:

{

"iv":"36+jK53EnbPbHssuWa1JCw==",

"v":1,

"iter":1000,

"ks":256,

"ts":128,

"mode":"ccm",

"adata":" Authentication%20Text",

"cipher":"aes",

"salt":"9+Va5voDXEA=",

"ct":"4h1AT/ZCbs9Y9ahmnquGtumvXT/1EJmQnFuh8AYleU4zscriK5AzgQjfypSmgOgw2DrM3Q=="

}

Here, ‘iv’ is the Initialization Vector, ‘v’ is the version number, ‘iter’ is the password strengthening factor, ‘ks’ is the Key Size in bits, ‘ts’ is the authentication Tag Size in bits, ‘mode’ is the Cipher Mode, ‘adata’ is the Authentication Data string (for example, perhaps a timestamp to limit repeated log-in attempts ), ‘cipher’ is the Encryption Algorithm used, ‘salt’ is the password Salt, and ‘ct’ is the CipherText.

To use the SJCL application in real-world encrypted information exchange, for example sending and receiving email, or file encryption, select the required parameters on the page. Then enter a shared secret password or key, enter the email message or copy the file contents to the ‘Plaintext’ box, and click the ‘encrypt’ arrow.

To avoid problems with mail systems that automatically save copies of unencrypted messages as you type, compose messages in a plain text editor rather than the email message-box. Then copy and paste all the encrypted text, including the initialization vector, and opening and closing curly brackets, and email the encrypted message to the recipient, or save it to a file.

At the receiving end, copy the encrypted message or file contents to the ‘Ciphertext’ box and decrypt it with the shared password or key. For example, the contents of the ‘vitalSigns.csv’ file at www.web2ria.com are shown below. Column titles on the first line of the unencrypted file are folded here for readability:

Age,

Record&nbsp;Date<br>mm/dd/yyyy,

Blood&nbsp;Pressure<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

    &nbsp;&nbsp;mmMg,

Cholesterol<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mg/dL,BMI<br>,

Height<br>&nbsp;Ft-ins,

Weight<br>&nbsp;&nbsp;&nbsp;&nbsp;lbs,

Temp&nbsp;<br>&nbsp;&nbsp;&nbsp;&#176; F,

Pulse<br>&nbsp;bpm,

Respiration<br>breaths/min,Blood<br>&nbsp;&nbsp;&nbsp;  

    O<sub>2</sub><br>&nbsp;&nbsp;&nbsp;&nbsp;%,

Blood&nbsp;Sugar<br>&nbsp;&nbsp;&nbsp;&nbsp;mg/dL

  4,09-24-1936,120 / 80,190,25.7,3-2, 50, 98.6, 90, 16, 97, 60

 42,09-24-1974,120 / 80,190,25.7,6-2,200, 98.6, 70, 16, 97, 70

 43,12-25-1975,130 / 85,200,25.7,6-2,200, 98.3, 75, 15, 96, 80

 44,10-20-1976,140 / 90,210,25.7,6-2,200, 97.8, 80, 14, 96, 90

 45,12-10-1977,145 / 95,220,25.7,6-2,200, 98.2, 85, 13, 95,100

 46,11-07-1978,150 / 98,230,25.7,6-2,200, 99.1, 90, 12, 95,110

 47,10-04-1979,155 /100,240,25.7,6-2,200,101.6, 95, 11, 94,120

 48,08-22-1980,160 /105,250,25.7,6-2,200, 99.3,100, 10, 94,130

 49,05-20-1981,165 /107,260,25.7,6-2,200, 98.6,105,  9, 93,140

 50,03-12-1982,170 /110,270,25.7,6-2,200, 97.4,110, 10, 93,150

 51,11-02-1983,175 /112,280,25.7,6-2,200, 96.3,120, 11, 92,160

 52,07-28-1984,178 /115,290,25.7,6-2,200, 97.9,130, 12, 90,170

 53,07-16-1985,174 /110,300,25.7,6-2,200, 98.1,140, 13, 89,180

 54,10-03-1986,170 /105,280,25.7,6-2,200, 98.3,150, 14, 88,160

 55,08-02-1987,160 /100,260,25.7,6-2,200, 99.0,160, 15, 87,140

 56,06-05-1988,150 / 95,240,25.7,6-2,200, 98.8,170, 16, 88,120

 57,03-01-1989,140 / 90,220,25.7,6-2,200, 98.7,150, 17, 89,100

 58,02-26-1990,120 / 80,200,25.7,6-2,200, 98.6,130, 18, 90, 80

109,12-25-2010,140 /100,190,25.7,5-1,170,101.3,110,100,100,100

When the sender encrypted using the password ‘http://www.web2ria.com’, the result using the SJCL default settings was as follows below, with the single line of cipher text (ct) split into multiple lines here for readability:

{

"iv":"HV9Xro6SvCgq17ReXAsn4Q==",

"v":1,

"iter":1000,

"ks":128,

"ts":64,

"mode":"ccm",

"adata":"",

"cipher":"aes",

"salt":"ObpiMz7YLFw=",

"ct":"p5/DJ8yRQPHOrnEUu6d4o1Q9JTKSNzrWgy8KO6MGIDy

NJeruOIfa+YKTQzs/V+7wI1wVRitXZDdUCSM6OT5n0wReKgBS

pRTv7hoVLSSZxQEokzEO1pthY6Ly1DUBz8Zc13gigws0KNQG8

ir22sUDy/3WD49K640koH6T07DMfqNi4mB0vX5qgTTeczVVVv

bdW/noSzZqe9h83FxNsA8F+lOlcEuNvoYhgBGob7xGsIU35A7

IWEKf75wKH+AAP23agFqFbjynNF2tZKfCeI1TrdO72LroM18K

vOBorDJyUHq80y7/srGYFRu2Vyq7gterKr8JYlaIfHVErTfCu

h6R+WEZmGnh1Rxi5WEh/iPUKApZD4MDPrvrtGrWs+QYr/5Lnn

bLgfc8xISN6c18Spe83+WXieTlw14L2X5WhQO1p9pGdfuihOo

ivtMkP7Ehyb0r6ztGuf6pd7xuB+gwwJmZ+6WztUzxrhRSfudN

1/RMQPDWRKmZmC8c9MWiEYUQUbSz5uoelLdF6q9FkTzqQz5VV

Jth1v9eTE686FOJV89hgF/xw5SMf9bLIYLoZGLjZJsSa/ieSw

J8cA3vYAFSqYg3aOgpH0PFV818vO086lpQp1pFSJwtIJ3x9B3

25hIlPo9selv2BqFdSsZtdj7pfrmAA0Mto6RjPTsguOXyfLux

40mgOK7A6mN3Iaz5pkDsIjecQSKIb7vtS49UfGGyYJ44mDw91

Vv+OQbMPIxocJ+g4ly9sRLCE1woDxf92tYPwVhsO30/z7E9Mv

mjAW2DPNN7kQwIXhSRCMNjQ0MtyymGxUTptDFu3e7Q+9EyNX3

DmGzL3ynPJwpoLkqT4GaW9gkpPGFY5GjoBiiuzGCQ1BI1451q

0KzosO69wEHITgaPejBoseDDnrF6v/9f8I1R9fg6ZpQ+Lb93H

E/MIjKVbfKVS4zAe+WeWx48nBtlJF3N+Otib2PZPM6pwm2sHu

tswiFptPQuVrXqVI8IRLLF7tQeI/+771aFqX6Trv6ysezzeHu

ma5m6HYpje08IJK6v94/CQ+GolODrNx2YM2koGMVrolfnBN3Z

dw7RleuEsBeQ9yuva7Dt5ajKlEp3ExCqL4nwLxynt1RFktrbM

CPazlA0HUru3S704jB5JufNGsRfqHeg894mbgGvU29OesPLtb

E5jYRUKyQJNZylPZ1I+L7N2jiYskJezzI74bvkeuqInJev3yZ

xCOBtc1xPi/ZkfOM/zHJvZKXwFQPRoxCm0gZwrRwmr7Ncd0Cz

gAXynhZQ5PTEzwm8XU8aiOFJbAJ9JtYSu70jp0BfXDOk3gi4L

t2lQnwbJDFL/hFCcX2h/Nfx5Wu3Qm0iWaeX6ROg+xYhZ21n1i

NeZ3rVgX82A9zOlVBDnylCqu5B2enNXydeu0/yibhMRMY0E31

eTBnj3MCtsING6p9xVM2fvu7ZdCgK0V0iLVbKPIYOsxAljH+X

7H0P+Pag50PHaFd8Tzra/DiktRaltFyT7DCCqb/7GRM0WrHco

YDuOQIHvu+EYkt3BNwLwApbDSrRX/xPOX1nFiTIBDdo0YYWKr

lPa04ET4I/rGpvJLxavbVzcaIJS70EGIUo5s/0mc0ciM9ECmN

kXrkvZAKZ5G3cpdPYM+8gyP+XjhIwEH0BQPppopdmvUPCJAc1

FV4NvWvKJR2+Mr8D5IdIOSI0G09juGNWnEOn8npW1Y1eAsujd

o26cTG+IICbod7Bx1JVX6FplpX7ecuwb+gW6wGLAJGrV79vEX

OBN45phFU00dLWAhcgB69+J8UeKkGRKkodyuc+g5zbCikyI68

W/kPs3C2qBskqBhRZtmSbzb4HwIF96s3CNbV82lS5H+ulub5n

mIlk7vymfk+NzVm8Yyek1ZgQL6U/4qqaLCyRFOCC1BB8tYzc6

TI7jNYlKzYIvnpVeG2ZQBagnnJ8uPN3/TsHnDIy2wLMxtFomq

fv2fQt2PUcmB0sq3xyI/nFVOmZzGnBIvDUuCI/jy7nWR1GgrI

Gt1qOvIslsXH/WESAh4EXGnwceudPxKjtmxoZQJsWEUynDhXm

OGvVrTkxk+fD30TAl6BPIe93c9zPm69b2g+1tTzRWZsNueDQs

Bj458tvifLMVPkZKft4THPjsnfDlonyqAbXPhTpGMHW5YxxR2

8FYjr1taZu/usOZt0d6bSAXYdOqScJ65wN5O2GHK4c" }

This text block, which can be the contents of the encrypted file, may then be inserted by the receiver into the ‘Ciphertext’ box, the password entered, and the light blue ‘decrypt’ up arrow clicked to obtain the original plain text.

The original text file is at www.web2ria.com/vitalSigns.csv and the encrypted file is at http://www.web2ria.com/vitalSigns.txt.

Of course, this may be a bit cumbersome for some users, and various software is available to ease the burden of encryption, from encrypted Windows file systems and email programs, to online, web-based encrypted email such as HushMail at www.hushmail.com/signup.

The files that make up the SJCL core are shown in this screenshot:

The ‘sjcl-min.js’ minified JavaScript file that’s used in the SJCL demonstration page at ‘www.web2ria.com‘ -> ‘Cyber Security’ tab -> ‘SJCL Web Page’ submenu item, consists of a concatenation of files from the ‘core’ subdirectory shown in the screenshot above, that are then minified. This minified file along with the unminified core files are in the widgets.zip file that can be downloaded from www.web2ria.com/widgets.zip.

The last file shown in this screenshot is the srp.js Secure Remote Password implementation for key exchanges, and other files enable, for example, Elliptic Curve Cryptology (ecc.js).

Elliptical Curve Diffie-Hellman (ECDH )

The Elliptical Curve Diffie-Hellman (ECDH) web page can be seen and tried at http://www.web2ria.com, ‘Cyber Security’ tab, ‘ECDH’ submenu item, and appears as in the next screenshot.

In ECDH, elliptical Curve points are used to provide the Public and Private encryption key pair used to encrypt content, instead of the integers used in standard Diffie-Hellman, and the predefined parameters include N and g, for any agreed to elliptical curve. The two parties generate their private and public-keys and exchange public keys, and each multiplies their private key by the other’s public key to arrive at a common shared secret-key.

The X coordinate of the derived point on the curve is used as the shared secret key, if both parties have agreed to this in advance (known as ‘Compact Representation‘ - see RFC 6090 section 4.2 ). To try ECDH, go to the ‘ECDH’ submenu item of the ‘Cyber Security’ tab and then copy and paste the computed shared secret key from the ‘X’ (upper secret key) field to the ‘Key’ field of the ‘SJCL Web Page’ submenu item, and click the ‘encrypt’ down arrow. In practice, this key would be hashed before using it.

Secure Remote Password (SRP)

When the SRP page loads, the ‘Status’ equals ‘Authentication failed .. ‘, as no password has been entered for the client Authentication Password, so neither the Passwords or the shared secrets, ‘S’, match. Try out the SRP page by entering a matching password in the ‘Password client’ field of the ‘Authentication Protocol’ area, and click any ‘randomize’ button. The Status field then indicates ‘Authentication succeeded’. The example needs Java to be installed in the browser as it’s used to acquire random numbers.

The shared secrets ‘S’ match, and can be copied and pasted into the ‘SJCL Web Page’ menu item, ‘Key’ field, and the down ‘encrypt’ arrow clicked.

SRP-6a works as follows:

N        Large safe prime (N = 2q+1, where q is a random prime )       { Shared

g        Generator modulo N                                            { Shared

k        Multiplier, k = H(N | g)

s        User / Client's random salt, and different Host / Server’s one

I        Username                                                      { Shared

P        Cleartext Password

H()      One-way hash function

u        Random scrambling parameter

a, b     Secret ephemeral values

A,B      Public ephemeral values                                       { Shared

x        Private key (derived from P and s)

v        Password verifier = g<sup>H(s | P)</sup>

A numerical SRP proof follows with simple math, using the known values from the earlier ‘Diffie-Hellman Key Exchange’ section, N=7 and g=3:

1. User:

   a  = 4                          { in practice a large secret random #
   
   A = g<sup>a</sup> mod N                    { A is public and sent to the Host
   
     = 3<sup>4</sup> mod 7
   
     = 81 mod 7                    {  7 x 11 = 77
   
   A = 4                           {  81 – 77 = 4                                   

2. Host:

   b = 2                           { in practice a large secret random #
   
   B = g<sup>b</sup> mod N                    { B is public and sent to the User
   
     = 3<sup>2</sup> mod 7            
   
     = 9 mod 7                     {  7 x 1 = 7
   
   B  = 2                          {  9 – 7 = 2

3. User:

   S = B<sup>a</sup> mod N                    { shared secret key, S
   
     =  2<sup>4</sup> mod 7
   
     = 16 mod 7                    {  7 x 2 = 14
   
   Shared Secret    = 2            {  16 – 14 = 2

4. Host:

   S = A<sup>b</sup> mod N                    { shared secret key, S
   
      = 4<sup>2</sup> mod 7
   
      = 16 mod 7                   {  7 x 2 = 14
   
   Shared Secret    = 2            {  16 – 14 = 2

When the user sets up an account, the host keeps the Username, I, random salt, s, and Verifier, v in its password database. Then, in the event that the host database is breached, actual passwords are not compromised:

x = H(s | P)                     (salt ‘s’ is chosen randomly )

v = g<sup>x</sup>                           (compute & store password Verifier )

Additional methods are used to authenticate in practice, as follows:

User -> Host:  I, A = g<sup>a   </sup>         ( identify User: send I, A = random # )

Host -> User:  s, B = kv + g<sup>b        </sup>( send salt & B = random # )

Both:  u = H(A | B)                (hash concatenation of A & B )

User:  x = H(s | P)                (User hashes salt & Password )

User:  S = (B - kg<sup>x</sup>)<sup> (a + ux)</sup>        (User computes session key )

User:  K = H(S)                    (User hashes Session key )

Host:  S = (Av<sup>u</sup>)  b                (Host computes Session key )

Host:  K = H(S)                    (Host hashes Session key )

Both parties now have a shared, strong session key K, and they authenticate by showing that their keys match. To verify that the User knows the password, simplified Message Authentication Codes (MACs ), M₁ and M₂, based on one-way hashes are used, and the 2-step procedure is as follows:

• 1^st User -> Host: M₁ = H(A | B | K_User) Host computes and verifies M₁
• 2^nd Host -> User: M₂ = H(A | M₁ | K_Host) User computes and verifies M₂

The two parties also employ the following safeguards:

• User aborts if he receives B == 0 (mod N) or u == 0.
• Host aborts if it detects that A == 0 (mod N).
• User shows proof of K first - step 1 above. Host aborts without showing its own proof of K in step 2, if User’s proof is invalid.

In practice, the large safe prime, N, is much larger than the single digit used in the simple mathematical proof shown previously, e.g., a 78-digit long random number such as used in SRP figure above for N in section 1, ‘Parameters’:

125617018995153554710546479714086468244499594888726646874671447258204721048803

Public values such as A and B can be exchanged in any way, e.g. email. But as they are ephemeral, the means should be fast and easily reusable.

RSA

RSA Public Key encryption (Asymmetric) can be used to encrypt text blocks up to the chosen key (e.g. 1024, 2048, or 4096 bits), but generating a 4096-bit RSA public and private key pair can take 1/2 an hour. So RSA is used to encrypt passwords / keys for symmetrically encrypted messages, that are then pre-pended to the symmetrically encrypted message block.

The RSA page can be seen and tried at www.web2ria.com, ‘Cyber Security’ tab, ‘RSA’ submenu item, and looks as follows in the screenshot below. The encryption strength is selected with the radio buttons.

Generating new RSA public-private key pairs is a time-consuming process for key lengths greater than 2048 bits, which can still take about ½ minute. For example, generating a 4096 bit long public and private key pair took about 30 minutes on a 2.2 Ghz laptop, as shown in this next screenshot.

Decryption of 4096-bit RSA also takes about 4 times longer than 2048-bit RSA.

And with fake certificates created by hackers, there is an attack surface for them to take advantage of. Also, biometric identification methods have the problem that, if hacked and stolen, they cannot be changed by the legitimate owner, and they become unusable - you can’t change biometric markers such as fingerprints and iris appearance.

History

• 31^st August, 2018: Initial version