Keeping Secrets

CS 493 Lecture, Dr. Lawlor

"Three people may keep a secret, if two of them are dead."
    -- Ben Franklin

The three pillars of computer security are:
I personally have a really hard time with secrets.  My job is explaining things to people.  Basically all the software I write is open source.

Yet I still have secrets.  I can't give out my passwords, my bank account numbers, my SSH private keys, or my social security number without losing control over my identity.

The folks breaking into the Linux kernel distribution site aren't trying to "steal the source code", which would be absurd since the whole point of is to give out the source code.  They're trying to modify the official copy of the source code, thus placing a back door in the millions of computers, cellphones, and industrial control systems that use this software.  Back doors are a key difference between the control required for open-source code, and the looser access to open-access text such as Wikipedia, where the damage due to vandalism is less widespread and more obvious.

Table of secrets: On revealing the secret, "happy" means benefit or enjoyment; "sad" means harm, dislike, or disapproval.

Happy You

Sad You

Happy Me

Surprise party

Anonymous benefactor

Secret Santa

Too Much Information (TMI)


Sad Me


Identity theft

Login credentials

Troop movements

Most bodily functions

Most medical problems

Secrets versus Accountability

In most organizations, the payroll processing system is fairly tricky to set up correctly, since you normally want to keep salaries secret (though not at UAF!), and certainly must keep blank check stock and account credentials secret.  Yet you also need sufficient transparency and auditing to make it difficult for a corrupt employee to embezzle payroll money: by paying fictional employees, paying real employees too much and splitting the difference with them, diverting money withheld for retirement or taxes, etc.

Some organizations have even harder problems.  Say you're working in Human Resources at the CIA.  Seemingly simple tasks like paying employees become difficult when the employee is not only behind enemy lines, but working at enemy headquarters--thus, simply mailing your informant a check or a tax form could get them killed!  If you're running the CIA payroll, consider the difficulty of distinguishing these situations:
Authorized Uses
Unauthorized Uses
Direct deposit paychecks.
Audit informant list.
Steal bank account numbers.
Sell informant list.
Write (modify)
Hire new employees.
Fire employees.
Pay fake employees.
Burn current employees.

There isn't a general technical solution to these challenges, but cryptography provides some options--for example, you could hide employee identities behind a one-way hash function, or encode authorization using public key cryptography.  The key technical and organizational challenge is correctly managing read and write access to the data.

The US government's official protocol for handling secrets is "classification". 

How paranoid do you need to be?

Some organizations, like intelligence services, know they're targeted, and act accordingly.  This means the backup CIA payroll computer, like the primary, probably sits in a vault with two armed guards, inside a bunker, inside a military base.  Backup tapes are hand-carried from the primary to the secondary by a carefully scripted, well defended transport system, then incinerated onsite. 

Other organizations don't think of themselves as targets.  For example, stores that sell hammers can still lose millions of customer credit card numbers due to malware on their point-of-sale computers.  A number of breaches involve unencrypted USB drives, such as a series of disclosures involving millions of health care patients in British Columbia; but 94% of US hospitals reported a data breach in the last two years.  After a series of stolen laptops,NASA now has an agency-wide whole-disk encryption policy.

Basically everybody, and every organization, has at least some secrets that need to be protected.  This course will explore how to do that.

Adversarial Algorithms

One big difference between normal code and cryptographic code is the latter is "adversarial": smart people giving input are allowed to try to structure it to screw up your code.  For example, if your sort has a quadratic worst case, but it's rare and happens only on highly non-random pathological datasets, you can probably ignore it because it won't happen often enough to make a difference.  The same situation for crypto is a recipe for disaster, because an attacker can hand you pathological cases all day long.