IY5502 Cryptography Assignment 3

This document provides solutions to Assignment 3 for the course IY5502 Introduction to Cryptography and Security Mechanisms. The assignment focuses on the article 'Why Johnny Can't Encrypt' and explores the use of PGP software, its cryptographic services, and the challenges users face. The solutions cover topics such as public-key encryption, digital signatures, key management, and the web of trust. It also discusses the relevance of the article's criticisms to modern encryption technologies like SSL/TLS. The assignment highlights the importance of user-friendly design in security software and the need for clear explanations of complex cryptographic concepts.

IY5502 Introduction to Cryptography and Security Mechanisms
Assignment 3
Questions based on article Why Johnny Can’t Encrypt by Whitten and Tygar
Q1. What use of the security software PGP is discussed in this article, and what
(cryptographic) security services does it provide?
A: Pretty Good Privacy (PGP) is a software for computers that allows users to send and receive
email securely, such that the contents cannot be read or modified in transit, and only the intended
recipient can read the message. All this is based on cryptography.
In other words, the (cryptographic) services provided by PGP include confidentiality by not
allowing unauthorised persons to be able to read the email message. The message is encrypted
using a public-key or symmetric cryptographic algorithm and this key is encrypted using the
private-key and included in the message being sent.
And it also provides authentication by allowing to verify the sender of the email. This is based on
the use of cryptographic hashing algorithms (e.g. SHA-1), which creates a fixed-length unique
representation (called message digests, hash value or hash) of any input data of arbitrary length.
This message digest is encrypted with the private key of the sender (in asymmetric
cryptography), and thus will only be decrypted by the public key of the same sender.
Additionally, both encryption and authentication can be used to together.
Q2. In your own words, provide a one paragraph summary of the main findings of this
article.
A: The hypothesis of the paper is that security software is different from consumer software and
user design principles for consumer software cannot be blindly applied to the security software.
Security mechanisms are only effective when used correctly, and humans are often the weakest
link in any security technique. Also, users of all skill-sets will eventually prefer convenience, so

the software has to be learnable and convenient, without sacrificing the integrity it is supposed to
provide. The software tested is Pretty Good Privacy (PGP) 5.0, which has been developed with a
focus on user experience. It is used for ensuring that email messages cannot be read by
unauthorised people and that the sender can be verified. The study found lots of deficiencies, not
due to lack of motivation, but a flawed understanding of the requirements for a security software.
Cognitive walkthrough analysis, heuristic evaluation, and laboratory tests on twelve individuals
representing the cross-section of average email users confirm the researchers' original
hypothesis.
Q3. The article suggests that users encountered difficulties because they did not
understand the basic concepts behind public-key encryption and digital signatures.
Provide a short explanation of these two concepts that is suitable for educating users
who are trying to use PGP software.
A: Some of the difficulties encountered in the use of Pretty Good Privacy (PGP) arose from the
users' being unaware of how the underlying concepts of public-key encryption and digital
signatures work. Both of these are based on cryptography, mathematics while digital signature
also uses central or distributed entities for trust.
Encryption: It is used to implement confidentiality. Public-key (also called asymmetric)
encryption is based on mathematics. For every entity (individual or organisation), there is a pair
of keys - one of them in public, and thus freely available and distributed to all, and the other is
private, kept secure by the entity. These keys are bound by mathematical properties that
encryption (making data unintelligible but can be recovered by applicable key) by one of these
can only be reversed (decryption) by the other associated key. This does away with the
requirement of sharing any common key between the sender and receiver. In PGP, this translates
into the software managing the owner's public and private key, other's public keys, encrypting
outgoing emails for particular senders, decrypting incoming email. To use this, the message is
encrypted with the public key of the receiver, only who owns the corresponding private and thus
is the only person who will be able to recover the message.

Digital signature: It is used to ensure authentication, which means to verify the sender of a
message. This too is based on public-key (also called asymmetric) encryption. In this scenario,
the sender uses his private key (which only he is supposed to know) to encrypt a message. Now,
the associated public key can be used to decrypt the message. The laws of cryptography
guarantee that any encryption done by either of the pair can only de reversed by the associated
other key. Thus, successful decryption by the public key of an entity confirms that the private
key of that entity was used i.e. that entity is the sender of the document. This is usually used with
hashing algorithms, which are one-way functions to create a fixed-length unique representation
(called message digest, hash value or hash) for any arbitrary input. Then this message digest in
encrypted with the private key to help implement authenticity. However, who is to vouch for the
association of a public key with an entity and this introduces responsibility of trust which can be
maintained by central authorities or peers.
Q4. Providing assurance of purpose of keys is an important aspect of key management:
a) How does PGP provide assurance of purpose of public keys?
A: Pretty Good Privacy (PGP) is the brainchild of a single person, Phil Zimmermann, who is
against governments and establishments. This shows in his design for the issue of trust in PGP.
He developed a decentralised method for assuring trust in the public and private key pairs, as
explained next.
A vetting scheme called "web of trust" is used to manage the public-private key association.
Creating a pair of a public and private key is a trivial operation. The difficult part is the
verification that a particular public key belongs to the individual being claimed (trust), and
secondly, that the owner of the key is actually the same individual as being claimed (validity). To
manage this in a decentralised way, any individual can publish a public key claiming to be his.
This is maintained in an identity certificate. Next, some other people will vouch for this claim by
digitally signing this person's identity certificate. This will be the process for every person. Now,
PGP software downloads the list of public keys. The concept is that out of the people who have
digitally signed the identity certificate, some of them will be trusted by the sender (in varying
degrees - complete trust, partial trust, or no trust). Thus, the accuracy of the public key can be
estimated. This setting is user-configurable. A couple of issues crop up in this method for the

underrepresented regions where it may be difficult for people to meet and verify documents
before digitally signing the identity certificate.
b) How important do the authors believe the provision of assurance of purpose is to
most users of PGP?
A: The authors are not very satisfied with the average user of Pretty Good Privacy (PGP). They
have found that the average user is, understandably, more interested in getting his job done and
the things like security are usually a secondary goal. According to them, for most users of PGP,
assurance of keys is not important.
There are two ratings for the keys - validity, which indicates that the key actually belongs to the
person being claimed, and trust, which indicates the faith the user has in the key being authentic.
By default, PGP does automatic calculations of these as per the "web of trust" paradigm, and the
unless the user studies the manual carefully, chances are less that he will be aware of this. The
words trust and validity are general enough to cause confusion, and the "unmotivated user" has
no protection from innocently assigning his own interpretations.
c) What recommendations do the authors make about the provision of assurance of
purpose of PGP public keys?
A: Tha authors have confidence in the decentralised model of trust in the Pretty Good Privacy
(PGP). Since there is no central agency like a certification authority, a peer-reviewed rating
system has to be maintained to ensure the validity and trust of the public-key and the entity
claimed as the owner of it. PGP maintains two ratings - validity, which indicates that the key
actually belongs to the person being claimed, and trust, which indicates the faith the user has in
the key being authentic.
The recommendations are not about the model per se but about the user-end view of them. Trust
and validity are general terms and can confuse the average user, who would be unwilling to take
out the time and study the manual to find out how these work. They recommend putting the key
server operations under a Key Server pull-down menu as it would encourage the user to make a
mental distinction between operations that access remote machines and that are purely local.

Also, the automatic calculations as to the validity and trust of the public key associations must be
made explicit to the user, so that they are saved the confusion of trying to guess the meaning of
trust and validity in the context of PGP.
Q5. This article was written in 1999. To what extent have the problems discussed in this
article concerning PGP been addressed since then?
A: The article was written in 1999, and since then a lot of upgrades have been done in Pretty
Good Privacy (PGP) software, but the overall key certification architecture was still the same in
2006 ("Why Johny Still Can't Encrypt" in 2006) and still, a decade and a half after the article,
modern PGP tools are still unusable for the masses ("Why Johny Still Still Can't Encrypt" in
2016).
However, some pain points have been relieved. The users tested have no problem in creating
keys. This has been possible by a key generation wizard. Similarly, there was absolutely no
difficulty in decrypting email, as this has been automated. Also, users had very little difficulty in
getting public keys, verify public keys, encrypting an email, signing an email, verifying a
digital signature, and saving a backup of public and private keys.
Q6. To what extent do you believe similar criticisms to those made in this article might
apply to modern use of encryption in SSL/TLS?
A: Encryption is an important technology. In the contemporary information age, the ability to
safeguard information as it moves from one point to another, and when it is stored is critical to
the success of businesses, organisations and individuals. The article "Why Johny Can't Encrypt"
was published in 2005, and we would like to know how the technology has been progressing in
2016.
It is said that technology may change but people do not. As far security technology for the
masses, the untrained people who would understandably be more interested in completing their
task at hand, things are not looking up yet. Consumer software like email encryption is still
unusable for the masses a decade and a half year after the publication of the above-mentioned
article. However, modern software for specialists, the people whose day to day task at work is

security, seem to have been made available software that is intuitive, prevents dangerous
mistakes and allows efficient usage (e.g. IIS Crypto by Nartac software which is based on
SSL/TLS (Secure Sockets Layer/Transport Layer Security)). Since professionals may be
motivated to learn the tools of their trade, while the average user is unmotivated, thus we
conclude that most the criticisms of "Why Johny Can't Encrypt" still apply to encryption in
SSL/TLS using modern software.