The Value of User-Visible Internet Cryptography

Cryptographic mechanisms are used in a wide range of applications, including email clients, web browsers, document and asset management systems, where typical users are not cryptography experts. A number of empirical studies have demonstrated that explicit, user-visible cryptographic mechanisms are not widely used by non-expert users, and as a result arguments have been made that cryptographic mechanisms need to be better hidden or embedded in end-user processes and tools. Other mechanisms, such as HTTPS, have cryptography built-in and only become visible to the user when a dialogue appears due to a (potential) problem. This paper surveys deployed and potential technologies in use, examines the social and legal context of broad classes of users, and from there, assesses the value and issues for those users

SoK: Why Johnny Can't Fix PGP Standardization

Pretty Good Privacy (PGP) has long been the primary IETF standard for encrypting email, but suffers from widespread usability and security problems that have limited its adoption. As time has marched on, the underlying cryptographic protocol has fallen out of date insofar as PGP is unauthenticated on a per message basis and compresses before encryption. There have been an increasing number of attacks on the increasingly outdated primitives and complex clients used by the PGP eco-system. However, attempts to update the OpenPGP standard have failed at the IETF except for adding modern cryptographic primitives. Outside of official standardization, Autocrypt is a "bottom-up" community attempt to fix PGP, but still falls victim to attacks on PGP involving authentication. The core reason for the inability to "fix" PGP is the lack of a simple AEAD interface which in turn requires a decentralized public key infrastructure to work with email. Yet even if standards like MLS replace PGP, the deployment of a decentralized PKI remains an open issue

A secure searcher for end-to-end encrypted email communication

Email has become a common mode of communication for confidential personal as well as business needs. There are different approaches to authenticate the sender of an email message at the receiver‟s client and ensure that the message can be read only by the intended recipient. A typical approach is to use an email encryption standard to encrypt the message on the sender‟s client and decrypt it on the receiver‟s client for secure communication. A major drawback of this approach is that only the encrypted email messages are stored in the mail servers and the default search does not work on encrypted data. This project details an approach that could be adopted for securely searching email messages protected using end-to-end encrypted email communication. This project proposes an overall design for securely searching encrypted email messages and provides an implementation in Java based on a cryptographically secure Bloom filter technique to create a secure index. The implemented library is then integrated with an open source email client to depict its usability in a live environment. The technique and the implemented library are further evaluated for security and scalability while allowing remote storage of the created secure index. The research in this project would enhance email clients that support encrypted email transfer with a full secure search functionality

Intended status: Standards Track

draft-davin-eesst-00 A common format simplifies exchange of secondary school academic transcripts via electronic mail. Extant standards are applied to prevent unauthorized alteration of transcript content and to deliver transcripts directly and securely from each student to his or her chosen recipients. By eliminating third-party intervention and surveillance, the defined protocol better protects student privacy and independence than does current practice. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatrac ker.ietf.org/drafts/current / 1. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”. This Internet-Draft will expire on July 4, 2014. Copyright Notice Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Document

"I don't know why I check this…" Investigating Expert Users' Strategies to Detect Email Signature Spoofing Attacks

OpenPGP is one of the two major standards for end-to-end email security. Several studies showed that serious usability issues exist with tools implementing this standard. However, a widespread assumption is that expert users can handle these tools and detect signature spoofing attacks. We present a user study investigating expert users’ strategies to detect signature spoofing attacks in Thunderbird. We observed 25 expert users while they classified eight emails as either having a legitimate signature or not. Studying expert users explicitly gives us an upper bound of attack detection rates of all users dealing with PGP signatures. 52% of participants fell for at least one out of four signature spoofing attacks. Overall, participants did\ud not have an established strategy for evaluating email signature legitimacy. We observed our participants apply 23 different types of checks when inspecting signed emails, but only 8 of these checks tended to be useful in identifying the spoofed or invalid signatures. In performing their checks, participants were frequently startled, confused, or annoyed with the user interface, which they found supported them little. All these results paint a clear picture: Even expert users struggle to verify email signatures, usability issues in email security are not limited to novice users, and developers may need proper guidance on implementing email signature GUIs correctl

A security analysis of email communications

The objective of this report is to analyse the security and privacy risks of email communications and identify technical countermeasures capable of mitigating them effectively. In order to do so, the report analyses from a technical point of view the core set of communication protocols and standards that support email communications in order to identify and understand the existing security and privacy vulnerabilities. On the basis of this analysis, the report identifies and analyses technical countermeasures, in the form of newer standards, protocols and tools, aimed at ensuring a better protection of the security and privacy of email communications. The practical implementation of each countermeasure is evaluated in order to understand its limitations and identify potential technical and organisational constrains that could limit its effectiveness in practice. The outcome of the above mentioned analysis is a set of recommendations regarding technical and organisational measures that when combined properly have the potential of more effectively mitigating the privacy and security risks of today's email communications.JRC.G.6-Digital Citizen Securit

How to design browser security and privacy alerts

Browser security and privacy alerts must be designed to ensure they are of value to the end-user, and communicate risks efficiently. We performed a systematic literature review, producing a list of guidelines from the research. Papers were analysed quantitatively and qualitatively to formulate a comprehensive set of guidelines. Our findings seek to provide developers and designers with guidance as to how to construct security and privacy alerts. We conclude by providing an alert template, highlighting its adherence to the derived guidelines