Cryptography – Page 5

Easy, Password-Free, Cryptographic Authentication for Web Applications

See also the cryptographic authentication page.

Update. The demo code mentioned below has been updated to fix bugs. If you find any additional bugs please report them through the contact form ~~or by posting to the PJCL forum~~. (The PJCL user forum has been discontinued as of May 27, 2018.) The date of the latest update will be shown in the PJCL page. Please see also the blog post Cryptographic Authentication Is Not That Easy After All.

For years there has been consensus that passwords have to go. To the many reasons for not using password authentication, the European GDPR will add, when it goes into effect on May 25, stringent requirements to notify users and regulators when passwords are compromised, backed by substantial fines. And yet, passwords are still the dominant authentication technology for web applications. This is because the alternatives that have been proposed and tried so far are complicated and expensive to implement. But there is a simple alternative that you can implement yourself, if you are a web application developer: cryptographic authentication with a digital-signature key pair stored in the browser.

At last week's Internet Identity Workshop (IIW) we showed how easy it is to implement this alternative. We gave a demo of a sample web application, exercising the user interface and looking at the code. The sample application was implemented in Node.js and used the Pomcor JavaScript cryptographic library (PJCL) on the client and server sides. The code of the sample application, which we will refer to as the demo code, can be found in the PJCL page of the Pomcor site (subsequently modified as explained below to accommodate Internet Explorer).

PJCL Can Now Be Used in Node.js Server-Side Code Exactly as in the Browser

We have just released Revision 1 of Version 0.9.1 of the Pomcor JavaScript Cryptographic library (PJCL), which changes the way in which library functions are defined, making it easier to use PJCL in Node.js. In this post I describe the change and explain why it is important for full stack web application development.

Second Release of PJCL Expands Functionality Following NIST Cryptographic Specifications

Today we have released version 0.9.1 of the Pomcor JavaScript Crytpographic Library (PJCL). The initial public release provided digital signature functionality, which we had been using internally for our own research on authentication and identity proofing. This release adds key agreement and key derivation functionality. The next release will provide symmetric and asymmetric encryption primitives, including AES and RSA. To be notified of future releases you may ~~sign up for the user forum~~, subscribe to the feed of this blog, or follow me on Twitter (@fcorella). (Update: The PJCL user forum has been discontinued as of May 27, 2018.)

PJCL can be used in any JavaScript environment, both client-side (e.g. in a browser) and server-side (e.g. under Node.js). It comes with extensive documentation on the functionality that it provides, which includes:

Pomcor Releases JavaScript Cryptographic and Big Integer Library

We have just released a beta version of a JavaScript cryptographic library usable in any JavaScript environment and based on very fast big integer arithmetic functionality that may be of interest in its own right.

The Pomcor JavaScript Cryptographic Library (PJCL) is available free of charge for any kind of use, but not under a traditional open source license. The traditional open source paradigm encourages contributions by the developer community at large, but we believe that this paradigm is not well suited to cryptography. To protect the integrity of the cryptographic code, the license prohibits modification of the cryptographic functions.

We have been using the library internally for our own research on authentication and identity proofing, and this first release includes symmetric and asymmetric digital signature functionality, including HMAC, DSA, and ECDSA with NIST curves. Future releases will provide broader cryptographic functionality, including encryption and key exchange. We believe that the library provides the only available JavaScript implementation of DSA, which is important to those wary of the opportunities for hiding backdoors that might be provided by elliptic curve technology.

The underlying big integer functionality includes Karatsuba multiplication. Continue reading "Pomcor Releases JavaScript Cryptographic and Big Integer Library"

Storing Cryptographic Keys in Persistent Browser Storage

Update (March 5, 2025): This post, and the presentation at ICMC 2017, show how to use a browser as a credential wallet for same-device presentation. Section 12.4 in Chapter 12 of a book I'm writing with Sukhi Chuhan and Veronica Wojnas shows how it can also be used for cross-device presentation, and how a WebView component of a native app can be combined with a native code component to further support proximity presentation over BlueTooth or NFC.

This blog post is a companion to a presentation made at the 2017 International Cryptographic Module Conference and refers to the presentation slides, revised after the conference. Karen Lewison is a co-author of the presentation and of this blog post.

Slide 2: Key storage in web clients

Most Web applications today use TLS, thus relying on cryptography to provide a secure channel between client and server, and to authenticate the server to the client by means of a cryptographic credential, consisting of a TLS server certificate and its associated private key. But other uses of cryptography by Web applications are still rare. Client authentication still relies primarily on traditional username-and-password, one-time passwords, proof of possession of a mobile phone, biometrics, or combinations of two or more of such authentication factors. Web payments still rely on a credit card number being considered a secret. Encrypted messaging is on the rise, but is not Web-based.

A major obstacle to broader use of cryptography by Web applications is the problem of where to store cryptographic keys on the client side. Continue reading "Storing Cryptographic Keys in Persistent Browser Storage"

What kind of “encrypted fingerprint template” is used by MasterCard?

In a press release, MasterCard announced yesterday an EMV payment card that features a fingerprint reader. The release said that two trials have been recently concluded in South Africa and, after additional trials, a full roll out is expected this year.

In the United States, EMV chip cards are used without a PIN. The fingerprint reader is no doubt intended to fill that security gap. But any use of biometrics raises privacy concerns. Perhaps to address such concerns, the press release stated that a fingerprint template stored in the card is “encrypted”.

That's puzzling. If the template is encrypted, what key is used to decrypt it before use?

NSA’s FAQs Demystify the Demise of Suite B, but Fail to Explain One Important Detail

Last July, the National Security Agency (NSA) issued CNSS Advisory Memorandum 02-15, available at the Advisory Memoranda page, updating the list of cryptographic algorithms that can be used in National Security Systems (NSS). A subsequent document referred to the new algorithms as the Commercial National Security Algorithm Suite (CNSA Suite), which replaces Suite B. The transition to the CNSA Suite took place two months before a Suite B deadline to discontinue the use of RSA, DH and DSA and rely exclusively on ECC algorithms for public key cryptosystems. The subsequent document explained the motivation for the transition by saying that "the growth of elliptic curve use has bumped up against the fact of continued progress in the research on quantum computing, which has made it clear that elliptic curve cryptography is not the long term solution many once hoped it would be," and announced "preliminary plans" for a future transition to quantum-resistant algorithms.

This abrupt change of course, following many years of promoting ECC, took the cryptographic community by surprise. Continue reading "NSA’s FAQs Demystify the Demise of Suite B, but Fail to Explain One Important Detail"

Cryptographic Module Standards at a Crossroads after Snowden’s Revelations

Last week I participated in the third International Cryptographic Module Conference (ICMC), organized by the Cryptographic Module User Forum (CMUF), and concerned with the validation of cryptographic modules against government and international standards. You may think of cryptographic module validation as a dry topic, but it was quite an exciting conference, full of technical and political controversy. The technical controversy resulted from the fact that the standards are out of sync with current technology and it is not at all clear how they can be fixed. The political controversy resulted from the fact that, after Snowden's revelations, it is not at all clear who should try to fix them. The organizers signalled that they were not afraid of controversy by inviting as keynote speakers both Phil Zimmerman, creator of PGP and co-founder of Silent Circle, and Marianne Bailey, Deputy CIO for Cybersecurity at the US Department of Defense, besides well known expert Paul Kocher of SSL fame. I enjoyed an exchange between Zimmerman and Bailey on the imbalance between defense and offense at the NSA and its impact on cybersecurity. Continue reading "Cryptographic Module Standards at a Crossroads after Snowden’s Revelations"

Faster Modular Exponentiation in JavaScript

Modular exponentiation is the algorithm whose performance determines the performance and practicality of many public key cryptosystems, including RSA, DH and DSA. We have recently achieved a manyfold improvement in the performance of modular exponentiation in JavaScript over the implementation of modular exponentiation in the Stanford JavaScript Crypto Library (SJCL). JavaScript was originally intended for performing simple tasks in web pages, but it has grown into a sophisticated general purpose programming language used for both client and server computing, which is arguably the most important programming language today. Good performance of public key cryptography is difficult to achieve in JavaScript, because JavaScript is an interpreted language inherently slower than a compiled language such as C, and provides floating point arithmetic but no integer arithmetic. But fast JavaScript public key cryptography is worth the effort, because it may radically change the way cryptography is used in web applications. Continue reading "Faster Modular Exponentiation in JavaScript"

Has Bluetooth Become Secure?

Bluetooth has a bad reputation when it comes to security. Many vulnerabilities have been found over the years in the technology, and many successful attacks have been demonstrated against it. But the Bluetooth specification has also changed much over the years, and each revision of the specification has made substantial changes to the Bluetooth security protocols. Whether the latest protocols are secure is a question open to debate. This question is especially important when Bluetooth is used in emerging medical and Internet-of-Things applications where security flaws have safety implications. But it has also come up recently in the context of the Derived Credentials being standardized by NIST for authentication of Federal employees who use mobile devices.

(This is a continuation of the last two posts, which reported on the recent NIST Workshop on PIV-Related Special Publications. It is also the last of a seven-part series of posts discussing the public comments on Draft SP 800-157: Guidelines for Derived Personal Identity Verification (PIV) Credentials, and the final version of the publication. Links to all the posts in the series can be found here.)

Before tackling the question of whether Bluetooth is secure today, Continue reading "Has Bluetooth Become Secure?"