Atlantis - User Guide
Secure Messaging with OTP
Ricardo Matsui
Jonathan Vronsky
Dan See
Andrew Brandes
Preface
This document provides the details on design and implementation and an overview of setup and
deployment of the Atlantis application and backend. The goal is provide a comprehensive guide
for further development, troubleshooting, and deployment of the project for future developers.
Audience
The audience for this document includes future developers and project managers who need to
have a complete view of the project.
Vocabulary
●
Application - The mobile secure messaging application installed on the end user devices
built for Android
●
Backend - The server hosted on the Heroku cloud which exchanges messages between
different devices running the application.
●
End-to-end Encryption - A form of communication where the backend server does not
decrypt the messages being sent, and only the end-user devices can read the
messages.
●
OTP - A random block of data which is generated from a random source rather than
from an algorithm such as a pseudo-random number generator
●
OTP Encryption - The OTP computed for conversation is saved on the device after it is
encrypted using AES with the user PIN. Even if the file of OTP is compromised the
attacker would have to decipher the OTP.
●
Entropy - Entropy is the amount of disorder in the data the application collects. The
random data used by the app always follow the minimum entropy available to ensure as
unpredictable data as possible.
●
Harvester - The Harvester is a service that will run on the device in the background. The
service will collect random data that will be used to produce the OTP. The service will
run until the top cap of data the application can hold will be collected.
●
Syncing - Syncing is how the application maintains a copy of a given OTP on a separate
device for the purpose of decrypting enciphered messages send between them. To
ensure data privacy, syncing must be done locally with USB or bluetooth.
●
Notebook - A pair of one-time pads used for communication between two devices. It
contains a sending and receiving one-time pad to establish two-way communication.
●
Conversation - A conversation is the part of the application where a user can send
messages to one or more previously synced contacts.
●
Contact - A contact is another user who has synced OTPs with your system and with
who you can exchange messages and initiate conversations with.
●
Message - A message is a small note of text or an attachment, such as an image, you
can send that is received by all other members of a conversation.
Table of Contents
Preface ...................................................................................................................................... 1
Audience ................................................................................................................................ 1
Vocabulary ............................................................................................................................. 1
Table of Contents ................................................................................................................... 2
Overview of Product ................................................................................................................... 4
Installation & Distribution............................................................................................................ 4
Backend ................................................................................................................................. 4
Development ....................................................................................................................... 4
Deployment......................................................................................................................... 5
Android Application................................................................................................................. 5
Development ....................................................................................................................... 5
Deployment......................................................................................................................... 5
Functionality ............................................................................................................................... 5
Lock Screen ........................................................................................................................... 5
Conversation List .................................................................................................................... 5
New Conversation Screen ...................................................................................................... 6
Notebooks Screen .................................................................................................................. 6
Notebook Screen .................................................................................................................... 6
Syncing Screen ...................................................................................................................... 6
Conversation Screen .............................................................................................................. 6
Message Screen .................................................................................................................... 7
Settings Screen ...................................................................................................................... 7
Harvester Service ................................................................................................................... 7
Backend Service .................................................................................................................... 7
Troubleshooting ......................................................................................................................... 7
Frequently Asked Questions ...................................................................................................... 8
Contact Information .................................................................................................................... 9
Index .......................................................................................................................................... 9
Appendix .................................................................................................................................... 9
Design Document ................................................................................................................... 9
Summary ............................................................................................................................ 9
Introduction - Why One Time Pads? ..................................................................................10
Background........................................................................................................................10
Design Goal .......................................................................................................................10
The Platforms ....................................................................................................................10
OTP Transfer Medium........................................................................................................11
Generation of OTPs ...........................................................................................................11
Local Device Storage .........................................................................................................11
Local Encryption ................................................................................................................12
User Interface ....................................................................................................................12
Server ................................................................................................................................16
A Graphic Explanation on How OTP Works: ......................................................................17
Caveats & Possible Solution: .............................................................................................18
Testing Document .................................................................................................................19
Summary of Product ..........................................................................................................19
Developer Contact Information...........................................................................................19
Resources Required for Testing.........................................................................................19
Packaging and Building......................................................................................................20
Process for Defect Reporting & Repair ..............................................................................20
Functional Testing Plan......................................................................................................21
Non-Functional Testing Plan ..............................................................................................21
Test Cases.........................................................................................................................21
Overview of Product
With recent events, security and privacy have become major topics globally, and new
revelations on mass surveillance and the ever-increasing power of computers have shown how
existing Internet traffic encrypted with SSL and VPN can be problematic if the communication is
recorded, since that communication may be decrypted as more powerful computers become
available. The Atlantis project solves this by providing private, end-to-end encryption using the
one-time pad technique which guarantees the message cannot be decrypted as long as the pad
is not compromised. The app requires Atlantis users to start their conversation with an in-person
meeting, allowing their devices to exchange a completely random pad outside of any network.
This pad is then used to encrypt future messages for transfer across the Internet. Because the
pad is random and is never reused, it is not possible to decrypt the messages without the pad,
even with any amount of computational power. Atlantis therefore provides privacy-aware
customers such as journalists and businesses, with a convenient platform for secure
messaging.
Installation & Distribution
Backend
The backend can be be downloaded using Git from: https://bitbucket.org/ecs-193-atlantis/otpserver
Development
The backend can be easily installed locally by downloading the necessary dependencies:
●
MongoDB from http://www.mongodb.org/
●
Node.JS from https://nodejs.org/
●
Heroku Toolbet from https://toolbelt.heroku.com/
●
Install remaining dependencies by running `npm install` and `npm install nodemon`
After installation, the server can be run locally by running `nodemon index.js`
Deployment
It is designed to be deployable using Heroku https://www.heroku.com. To deploy the server,
create a new app on Heroku and add the following add-ons:
●
MongoLab - MongoDB database provider
●
New Relic APM - App performance monitoring
Then following the instructions for uploading the code using Git on the Heroku App Deploy
page. The backend will be uploaded and will auto-start on the domain provided by Heroku.
Pushing new code will automatically restart the service.
Android Application
The Android application can be downloaded using Git from:
https://bitbucket.org/ecs-193-atlantis/otp-android
Development
The only requirement for developing the Android application is Android Studio
http://developer.android.com/sdk/index.html
After opening downloaded the project, select Build and Run to compile and run the project. To
configure the application to use a different backend, modify the string resource `backend_url` to
the URL of the backend hosted on Heroku.
Deployment
The application can be packaged to an APK, signed, and distributed on the Play Store using the
latest guides published on the Android developer platform:
http://developer.android.com/tools/publishing/preparing.html
Functionality
Lock Screen
The lock screen shows to enter a PIN to unlock the application. The first time a PIN is needed,
the app will request the user to enter a PIN. The PIN is used to encrypt the local data of the
application, including the one-time pads. This provides security from attackers with only limited
access to the device.
Conversation List
The conversation list is the home page of the app and shows a list of the conversations that can
be selected to view the conversation. It also provides the ability to create a new conversation
using the new conversation button. The settings page can also be opened from this page.
New Conversation Screen
The new conversation screen can be opened from the conversation list. The contacts that this
conversation will be with can be entered, with the application providing suggestions from the
contacts on the phone when entering names. Multiple names can be entered to create a group
conversation with multiple people. The notebook length can also be selected on this page to
specify how large the one-time pads should be. The size slider allows a size based on the type
of content will be used most. Conversations with images will require significantly larger one-time
pads than text conversations. Submitting the new conversation will create the notebooks and go
to the notebook screen.
Notebooks Screen
The notebooks screen is opened after creating a new conversation and can be accessed from
any conversation screen. The notebooks screen is used to show the status of the notebooks of
the contacts in the conversation. These notebooks are the pairs of one-time pads used to
encrypt and decrypt the messages being sent. The amount left is shown, as well as if the
notebook has been synced with the necessary contact. Selecting an unsynced notebook will go
to the sync screen for that notebook, and selecting a synced notebook will go the notebook
screen.
Notebook Screen
The notebook screen shows extra details about the notebook selected and allows for the
notebook to the re-synced. Notebooks must be re-synced when they are empty or close to
being empty because one-time pads cannot be re-used. When selecting to re-sync, a new
notebook is created and the new notebook must be synced with the contact in-person via the
syncing screen.
Syncing Screen
The syncing screen is used to show methods of syncing the notebook which contains the onetime pad. It shows the various methods of syncing, including via Bluetooth and USB. Each
method has a description and instructions specific to perform the sync. The syncing method
must be the same between the two devices being synced. The Bluetooth method requires two
Bluetooth-enabled devices and USB requires an On-The-Go adapter. Once the method is
selected, the one-time pads will be transferred between the devices, and the conversation can
be used.
Conversation Screen
The conversation screen shows the message history in the conversation and send messages.
The top bar shows the amount of the notebook that is still available to be used to send
messages, and buttons to refresh and view the notebooks being used in the conversation. The
bottom bar contains the text entry, send button, and attachment button. Pressing the attachment
button shows an image picker to allow for sending messages. The message history list can be
scrolled and selecting a message in the list will open the message screen.
Message Screen
The message screen shows the full contents of a message, including a large view of image
messages so that the content can be easily seen and read. Pressing back will return to the
conversation screen.
Settings Screen
The settings screen shows options such as selecting the image quality preference and adjusting
the PIN code settings. The settings screen can be opened from the conversation list. The
settings are saved as they are changed making it easy to use.
Harvester Service
The harvester service runs in the background collecting data from various sources, then
extracting the randomness from them to create the one-time pads. The specific data in the
sources is destroyed, but the entropy is calculated and extracted in the process. This generates
cryptographically secure random bytes that are used during the conversation creation stage.
The harvester sleeps after it collects a sufficient amount of data for a new conversation in order
to conserve battery.
Backend Service
The backend exchanges messages by temporarily storing them and allowing the application to
look the messages up via their unique addresses that are generated by the one-time pads.
Since both participants have the one-time pad, they can query for each other’s messages via
the backend service. The backend service connects to the applications via Socket.io, which
provides a real-time connection, allowing messages to be quickly pushed and pulled from the
service to the devices.
Troubleshooting
●
Messages cannot be sent
Check the Internet connection of the device and check that the backend service is
running and the application is configured to use the correct one if it has changed.
●
USB device not found
Check the manufacturer’s website if the device supports accessories and the USB OnThe-Go standard. Replace the USB cable if the devices are still not working.
●
Messages do not load when debugging
The application may not have requested a PIN due to the application lifecycle when
debugging. Exiting the application and returning to it will cause the application to request
a PIN to decrypt the messages.
●
Database incompatible after updating schema during development
The database must be given an upgrade path for the new schema for it to upgrade to the
new version. Another solution is to clear the application data in phone settings to reset
the application, but all data in the application will be lost.
Frequently Asked Questions
●
How is randomness generated?
Randomness is generated from entropy sources that exist on the device.
●
Why does making a new a conversation require having the participants in-person?
Since the app uses one-time pad, the one-time pads must be exchanged outside of the
network in order to provide security.
●
What makes a good entropy source?
The entropy sources which are most affected by thermal noise, which is considered
random, are good candidates for entropy. They can also depend on the randomness
present in the environment, and the Shannon entropy calculation can determine the level
of entropy present.
●
Why use one-time pad if regular encryption is considered secure?
Encryption could be broken with stronger computing power, while one-time pad will
always be unbreakable if the pads are not compromised due to a lack of an algorithm
that related the ciphertext to the plaintext without the pad.
●
Why does the app require the participants to re-sync the notebook?
The one-time pad is used and never re-used, hence when all the data in the one-time
pad is sent, the it will run out and the notebook must be re-synced to create new onetime pads.
●
Does the location of the in-person syncing matter?
Sometimes, when using Bluetooth it could because the Bluetooth data could be captured
by someone using a Bluetooth receiver if the location was a public place. USB data on
the other hand is significantly more difficult to be captured by someone because it is a
wired connection, so the location is not as important.
●
Is an Internet connection necessary?
Yes, the messages are sent over the Internet and require connection to the backend
server to send messages.
●
How long does the one-time pad last?
It depends on the nature of the messages sent and the frequency that they are being
sent at. Images require significantly more OTP than text, and text only conversation can
last for several days with one sync.
Contact Information
Name
Email
Andrew Brandes
apbrandes@ucdavis.edu
Ricardo Matsui
rmmatsui@ucdavis.edu
Dan See
dcsee@ucdavis.edu
Jonathan Vronsky
jvronsky@ucdavis.edu
Index
Android, 1, 2, 5, 10, 19, 20, 22, 23, 24, 25,
26
Android Studio, 5, 19, 20
Application, 1
Backend, 1, 2, 3, 4, 7
Bitbucket, 20
Bluetooth, 6, 8, 10, 11, 19, 20, 22
Collision, 17
Contact, 2, 3, 9, 19
Conversation, 2, 3, 5, 6, 13, 21, 22, 24
encrypt, 4, 5, 6, 10, 12, 19, 26
end-to-end, 4, 10
Entropy, 1
entropy source, 8
Git, 4, 5, 19, 20
Harvester, 1, 3, 7
Heroku, 1, 4, 5, 20
Message, 2, 3, 7, 18, 19
Appendix
Design Document
Summary
MongoDB, 4, 5, 19, 20
Node.JS, 4, 20
Notebook, 2, 6
notebooks, 6, 7
On-The-Go, 6, 7
OrmLite, 12
OTP, 1, 2, 3, 9, 10, 11, 12, 13, 17, 19, 21,
24, 25
PIN, 1, 5, 7, 8
Randomness, 8
Receiving, 17, 18
re-synced, 6, 8
schema, 8, 12
settings, 5, 7, 8, 13
sync methods, 23
Syncing, 2, 3, 6
Transmission, 17
USB, 2, 6, 7, 8, 19, 20, 22
This document provides background and details on the implementation of One Time Pads
(OTPs) in a secure messaging application. The goal is to provide secure end-to-end messaging
that is fairly convenient and guarantees that your data will remain private.
Introduction - Why One Time Pads?
In any secure environment, users need a way to transfer data securely over a network. The
users cannot use the Internet because the public network cannot be trusted. They operate
under the assumption that all the data they send over it can be intercepted and read, even if it is
transmitted under SSL, VPN, or other encryption based on difficulty of solving certain
algorithmic problems such as factoring. By using encryption, the users can secure any data, but
it’s only as strong as the encryption used. If the traffic is captured, newer computers. OTPs tries
to solve this by providing secure transfer that can’t be decrypted even if all of the data is
intercepted. But for this to work, users need to transfer the OTPs over short range secure
methods.
Background
A one-time pad is an encryption technique that can’t be cracked if used properly. It works by
pairing plaintext with a random key (or pad). We combine each bit of the text with the
corresponding bit of the pad with modular addition. Since the pattern is never reused, and the
pad is truly random, it will be impossible to decrypt without the same pad.
Design Goal
Our goal is to create an application to guarantee the secure, end-to-end transmission of a
message using the one time pad technique to encrypt the message and related server
infrastructure to exchanges messages between devices running the app. We want to create this
mobile application in addition to an accompanying server that fields the transmission and
delivery of these messages. The application should show the users multiple recipients that they
can send to, and allows an easy process for starting a new OTP exchange/conversation with
another user. The OTP should be generated relatively quickly and have the encryption and
decryption logic built in.
The Platforms
1. Android: We choose to develop this system primarily for android, due to the high market
volume and a very friendly development process. It is free to develop and to publish
which helps keep costs to a minimum.
2. iPhone: We have plans to expand our working product to the iPhone is it is feasible. The
downsides include a cost to develop and the fact that they only run Bluetooth Low
Energy. We will also have to modify the android java code for use in Objective-C.
OTP Transfer Medium
1. Bluetooth: Easiest way to transfer the OTPs between phones. It only requires you to be
fairly close to the corresponding device, and no additional parts needed. We also
implemented a system that error checks the data being sent and has a resend option.
This will guarantee delivery even for larger file sizes. However, large OTPs (>10MB) can
have long transfer times, which is undesirable. In terms of security, Bluetooth is much
more secure than the network, but it is not perfect. Malicious users can gain access to
the data with use of specialized equipment if they are nearby.
2. Cable: Another very easy way but requires the use of additional piece that needs to be
obtained elsewhere. It requires physical interaction and something additional. You could
either use a computer as an intermediary, a male to male AUX cable, or a female usb
cable to connect the two phones directly. This takes away from the convenience factor
but could be useful for exceptionally large OTPs because we could transfer them much
faster. It makes for a good secondary transfer method.
3. SD Card: Very similar to the cable, as it requires a separate item. Potential to be very
useful for large OTPs and makes it easy to transfer between people. The problem is that
not all platforms (i.e.: iPhone) support SD cards. It requires more user knowledge and
can be a bit of a hassle. Users would have to be able to install and remove SD cards
from their individual phones.
Generation of OTPs
To generate the OTPs we started with the Secure Random function found in Java, and then
upgraded to harvesting higher entropy sources using audio and other sources and extracting
entropy. This function provides a way to generate a non-deterministic random value. This
approach makes it nearly impossible to reproduce the seed and the output. We use this
approach to generate an OTP that is a merely a file of random data. By encrypting the data
being sent with this, character by character, we create a ciphertext that can’t be decrypted
without the OTP. This OTP can also be used as an addressing system for the messages.
Because we want to keep it anonymous without permanent addresses, we adapted our system
to use a small part of the OTP for every message you send as an address. Because both users
in a conversation have the OTP, the receiving device can “listen” at that address for messages
on the server. While we could use a separate OTP for this operation, we decided that it would
be most efficient if both pulled from the same OTP. To keep the OTPs safe on the phones, they
will be encrypted into a database and retrieved only when the corresponding conversation is in
use.
Local Device Storage
To store data on the device, we are planning on using an OrmLite SQL database. This allows us
to store the applications data in a straightforward and logical way. We plan to make use of a
schema as shown below. By following this, we can set up our data in an easy to access and
manage way. In this way, we can link conversations to multiple OTPs which in turn will be linked
to people. Each person can have multiple OTPs but a single OTP can only belong to a single
person. Messages are simply a part of the conversation but also keep track of whether a
message has been read and if it needs to notify the user.
Schema Diagram
Local Encryption
In order to protect the users data on the phone, we plan to implement a pin lock system. We will
use the pin to generate a random string that is used to encrypt the data and the checksum.
When starts the app and enters in their pin, we will decrypt these values and compare the
checksum to ensure that the decoding was done properly. This offers protection for the data on
the phone for the user. We also want to give the user the option to delete data upon a number
of failed pin attempts.
User Interface
Our main page will give the user a few choices: Existing Conversations, New Conversation, and
settings. Existing conversations is merely the conversations that have already had OTP
exchanges and are ready to send. The page will let the user know how much of the OTP
remains and offer a simple chat UI. The new conversations panel will allow the user to start off a
OTP exchange with options letting the user select the transfer medium. After syncing, this will
be added as a new conversation. Settings will allow the user to edit things such as their pin.
UI Design Mock-Up
UI Design Examples
Server
Our server is going to field the retrieval and storage of the ciphered messages. When a user
goes to send a secured message over the network, it will use a small piece of the OTP as an
address. Using this address, it is stored in the server. The app will periodically check with the
server on addresses it is expecting messages from because it has the same OTP as the sender
so it knows what to addresses to look under. This keeps user identities anonymous so the
server can’t reveal this information if compromised.
1. Transmission: the device that is transmitting will send the message to the first address
decoded, and will start a timer. Then the transmitting device will wait for an "OK"
message to arrive from the receiver on the same address. Once the "OK" has arrived
the transmitter knows to disregard the first address and make address 2 into address 1
and generate new address for address 2. If the "OK" message does not arrive before
timeout is declared the transmitter will resend the message.
2. Receiving: As for transmission the receiver also keeps track of two addresses. When the
receiver sees a message on address1 it sends back an "OK" message. At this point the
receiver keeps address one until it sees a new address coming in address2. Arrival of
message in address2 indicates the "OK" was received. Then the receiver disregard
address1, makes address2 address1 and creates a new address2.
3. Collision: In case two different conversation use the same address space the newer
message will override the older one. The receiver will know if the address was meant for
it by comparing the decoded message to the checksum. To avoid constant race
condition we will introduce exponential back-off to help reduce the amount of overrides.
A Graphic Explanation on How OTP Works:
OTP Exchange
Sending Secure Message
Receiving Secure Message
Caveats & Possible Solution:
1. A nice thing to have for messaging is push notifications. They would let the user know
immediately when a message arrives for him/her. The problem with this is that our
server doesn’t know who is receiving. We believe it is not feasible to implement a push
notification system and instead just have our app check in with the server periodically
with addresses it is expecting traffic on. To do this without requiring constant access, we
feel a check that backs off is the best compromise.
2. Denial of service attacks could be very problematic for our application. An attacker could
send non-stop messages to random addresses and by that constantly override
everybody's messages. A proposed solution is to take addresses with high override rate
'out of service' till they clear up. By doing that we can minimize the damage done by the
attacker.
Testing Document
Summary of Product
Brief Primary Use Case of Product
The primary use case is to provide secure and private communication between two devices by
using the one-time pad encryption technique. This technique involves generating a random
pads of data, exchanging them between two devices outside of the network by using USB,
Bluetooth, etc., and then using the pads to encrypt messages between the devices and sent
over the network via an anonymous relay server. In this way, users can create conversations
and then send messages.
Major Elements of Product
1. Android Application
a. Storage
i.
Safety: Encrypt data
ii. Integrity
b. Off Network Communications
i.
Bluetooth
ii. USB
iii. AUX
c. Message Encryption using OTP protocol
d. Network Connection with the Server
e. GUI
2. Server
a. Distributing addresses
b. Storing of messages
Developer Contact Information
●
Ricardo Matsui (rmmatsui@ucdavis.edu)
●
Jonathan Vronsky (jvronsky@ucdavis.edu)
●
Dan See (dcsee@ucdavis.edu)
●
Andrew Brandes (apbrandes@ucdavis.edu)
Resources Required for Testing
Development Machine
●
Capable of running Android Studio and Git for building Android application
●
Capable of running Node.js, MongoDB, and Git for running server
Android Application
●
Two Android phones running Android 4.4
●
AUX Cable Connection
●
Bluetooth Capability
●
USB host capability
●
USB On-the-Go Cable
●
USB to Micro USB Cable
Estimated Person Hours
Approximately 1 hour and 30 minutes.
How to Obtain Resources
Hardware is widely available and can be purchase online at Amazon. Software is free and can
be downloaded from the Git, Android, Node.js, and MongoDB websites or package managers
for the development operating system.
Packaging and Building
Android Application
1. Application can be checked out with Git from the Bitbucket repo at
https://bitbucket.org/ecs-193-atlantis/otp-android
2. Open Android Studio and open the Atlantis project
3. Select Build and Run
Server
1. Server can be checked out with Git from the Bitbucket repo at https://bitbucket.org/ecs193-atlantis/otp-server
2. Install Node.JS from https://nodejs.org/
3. Install Heroku Toolbet from https://toolbelt.heroku.com/
4. Install dependencies by running `npm install` and `npm install nodemon`
5. Launch the server locally by running `nodemon index.js`
6. Configure the Android application by setting the remote URLs to use the IP address of
the local server.
Process for Defect Reporting & Repair
Issues defects will be reported to the Bitbucket repo issue tracker, with proper title, reproduction
steps, component identification, priority, and assigned to a developer. Within one day, the
developer will accept the issue by responding to it or request more information by assigning
back to the reporter. Once accepted, the developer will create a separate branch from the
master branch to address the issue and develop the fix. Once the fix has been completed, the
developer will create a pull request to master for code review including `Fixed #<issue number>`
in the title. Once the pull request has been reviewed by at least one other developer and
merged into master, the issue will be resolved, and the reporter of the issue can then close the
issue or reopen if the problem continues.
Functional Testing Plan
Test
ID
User
Identification
User Goal
Developer
Estimated Time
Tester
Estimated Time
#1
End-User
Create Conversation
3 min.
3 min.
#2
End-User
Sync Conversation
10 min.
7 min.
#3
End-User
Send and Receive Messages
20 min.
9 min.
#4
End-User
See Warning on Low OTP
10 min.
8 min.
#5
End-User
Delete Conversation
8 min.
8 min.
#6
Application
Application Can Send and
Query Messages on Server
7 min.
7 min.
Non-Functional Testing Plan
Test
ID
Category
Sub-Category Specific Goal
Developer
Estimated
Time
Tester
Estimated
Time
#6
Security
Encryption
Messages are
Encrypted with OTP
15 min.
15 min.
#7
Security
Authenticity
Messages are
Checked for
Authenticity
15 min.
18 min.
#8
User
Experience
Performance
Conversation Loads
Quickly
5 min.
8 min.
#9
User
Experience
Performance
Messages Are Sent
Quickly
5 min.
8 min.
#10
Security
Availability
Server Is Reliable
9 min.
10 min.
Test Cases
Test Case Template
1. User Type
2. Goal
3. Initial Conditions / Required Resources / Configurations
4. Test Script
a. User action
b. Expected response
c. User action
d. Expected response
e. …
f.
User action
g. Expected response indicating completion
5. Functional test cases - Checking for correct completion or Non-functional test cases measuring degree of compliance
1. Create Conversation
1. End-user of application
2. To start a new conversation with another user
3. The two users are together with both Android devices that have the application installed
4. Test Script
a. Both users launch the application
b. The application launches to the conversation list
c. Both users tap the new conversation button
d. The application moves to the new conversation button
e. Both users name the conversation with a title they like and choose a pad size
f.
The application configures the conversation with those parameters
g. Both users select create
h. The application creates the conversation and generates the pad size and
completes this test by showing the sync page
5. The application reaches the sync page without any error and the OTPs are saved to
each device’s memory.
2. Sync Conversation
1. End-user of application
2. To sync a conversation with another user
3. The two users are together with both Android devices that have the application installed
and have a common method of syncing data (USB, Bluetooth, etc.). They have created
a conversation in the previous step or already have made a conversation together.
4. Test Script
a. Both users select sync or are at the sync screen
b. The application shows them a list of supported sync methods on their device
c. Both users tap the same sync method
d. The application shows the instructions for the method they chose
e. Both users follow the instructions to start the transfer of the pad which may
include pairing the other device
f.
The application performs the transfer and shows progress as the transfer is
made
g. Both users can observe the progress of transfer of the pads
h. The application completes the transfer and completes this test by taking both
users to the conversation page
5. The application reaches the conversation page without any error and the OTPs are the
same on both devices.
3. Send and Receive Messages
1. End-user of application
2. To send a message from User A to User B
3. The two users have both Android devices with Internet access and have the application
installed with a conversation created and synced between the two devices
4. Test Script
a. User A opens the application and selects the conversation with User B
b. The application loads the conversation between User A and User B
c. User A selects the message field, enters a message, and presses send.
d. The application encrypts the messages and sends it to the server
e. User A sees the message in the conversation on their device
f.
User B opens the application and selects the conversation with User B
g. The application loads the conversation and requests new messages from the
server.
h. User B sees the conversation as it was previously rather than waiting for new
messages
i.
The application receives the new message from the server, decrypts it, and adds
it to the conversation
j.
User B sees the new message and it is the same as what User A entered
k. The application completes this test by having sent and received the message
correctly
5. The application was able to send and receive a message without any error and the
message is received correctly on the devices.
4. Warning on Low OTP for Conversation
1. End-user of application
2. To show that a conversation should be refreshed
3. A user has an Android device and has been using a conversation for some time and the
OTP available is below 20%.
4. Test Script
a. The user opens the conversation
b. The application shows them the conversation and a warning that the OTP is
below 20% and that they should refresh it with the other user
c. The user can tap the refresh button to begin the sync process
d. The application completes this test by showing the sync process
5. The application completes the test by showing the warning message with the OTP
available is below 20%
5. Delete Conversation
1. End-user of application
2. To delete an old conversation
3. A user has an Android device and no longer needs a conversation
4. Test Script
a. The user opens the conversation
b. The application shows them the conversation
c. The user taps the delete option
d. The application deletes the conversation and related OTPs from the device,
completing the test
5. The application completes the test by removing the conversation, messages, and OTPs
from the device memory
6. Messages are Encrypted With OTP
1. End-user of application
2. To show that messages are encrypted with OTP
3. An Android device with the application and with a conversation set up and synced. A
network which can have the traffic captured.
4. Test Script
a. The user opens the application and selects the conversation
b. The application shows them the conversation
c. The user enters a message and taps on send and repeats the same message
again.
d. The application encrypts the messages and sends them over the network
e. The tester examines the messages sent over the network and verifies that it was
sent encrypted and the tester verifies that the OTP is not reused in any way by
seeing that the encrypted text has been shifted accordingly. This completes the
test.
5. The test is completed by showing that the messages are encrypted with the OTP on the
device and the OTP is not reused
7. Messages Are Checked for Authenticity
1. End-user of application
2. To show that messages are checked for modification on the network
3. Two Android devices with the application and with a conversation set up and synced. A
network which can have the traffic modified.
4. Test Script
a. User A opens the application and selects the conversation
b. The application shows them the conversation
c. User A enters a message and taps on send
d. The application encrypts the messages and sends them over the network
e. The tester modifies the message sent on the packet on the network
f.
User B opens the conversation
g. The application requests new messages and does not validate the modified
message
h. User B does not see the modified message, completing the test
5. The test is completed by showing that the messages must be received correctly to be
shown and cannot be tampered
8. Conversations Load Quickly
1. End-user of application
2. To show that the application performance is acceptable
3. An Android device with the application and with a conversation set up and synced and
many messages sent.
4. Test Script
a. User A opens the application and selects the conversation
b. The application shows them the conversation without significant delay
5. The test is completed by measuring how quickly the application opens the conversation
9. Messages Are Sent Quickly
1. End-user of application
2. To show that the application performance is acceptable
3. An Android device with the application and with a conversation set up and synced and
many messages sent.
4. Test Script
a. The user opens the application and selects the conversation
b. The application shows them the conversation
c. The user sends a long message
d. The application encrypts the message without significant delay, completing the
test
5. The test is completed by measuring how quickly the application is able to encrypt the
message and send it to the network
10. Server Is Reliable
1. Application API
2. To show that the server does not fail with high loads
3. A server instance and another computer on the network to stress-test
4. Test Script
a. The tester runs a script to deliver many requests per second of messages and
message queries to the server of various lengths and some valid and invalid
b. The server processes and enqueues requests, but does not crash or consume
more resources that it has
c. The server completes the test if it does not crash
5. The test is completed by measuring how many requests per second can be processed
successfully and how many resources it uses on the server.
11. Server Can Receive and Query For Messages
1. Application API
1. To show that the server can accept and respond to queries
2. A server instance and another computer on the network to send API requests
3. Test Script
a. The tester send a message to the server at a message address to the API
endpoint
b. The server processes and stores the message
c. The tester queries the server for messages at the message address via the API
endpoint
d. The server responds with the message the tester originally sent
e. The tester queries the server for message at an address without messages
f.
The server responds without any messages
g. The test is completed by showing the messages can be sent and received
correctly
4. The test is completed showing that it can store and query for messages