BF Model of Cryptographic Store or Transfer
Cryptography is a broad, complex, and subtle area. It incorporates many clearly separate processes, such as
encryption/decryption, verification of data or source, and key management. There are bugs if the software does
not properly transform data into unintelligible form, verify authenticity or correctness, manage keys, or
perform other related operations. Some transformations require keys, for example encryption and decryption,
while others do not, for example secret sharing. Authenticity covers integrity of data, identity of data source,
origin for non-repudiation, and content of secret sharing. Correctness is verified for uses such as
zero-knowledge proofs. Cryptographic processes use particular algorithms to achieve particular security
Examples of attacks are spoofing messages, brute force attack, replaying instructions, timing attack, chosen
plaintext attack, chosen ciphertext attack, and exploiting use of weak or insecure keys.
We use cryptographic store or transfer to illustrate our ENC, VRF, and KMN classes of bugs. Note that these
classes may appear in many other situations such as self-sovereign identities, block ciphers, and threshold
cryptography. We focus on transfer (or store) because it is well known and it is what most people think of when
"cryptography" is mentioned. We define bugs in cryptographic store or transfer as: The software does not
properly encrypt/decrypt, verify, or manage keys for data to be securely stored or transferred.
A modern, secure, flexible cryptographic storage or transfer protocol likely involves subtle interaction
between encryption, verification, and key management processes. It may involve multiple stages of agreeing on
encryption algorithms, establishing public and private keys, creating session keys, and digitally signing texts
for verification. Thus, encryption may use key management, which itself uses encryption and verification. The
following figure presents a model of these recursive interactions and where potentially the corresponding ENC,
VRF, KMN, and other BF bugs could happen. The rounded rectangles indicate the boundaries of the classes. The
dashed ones show sending and receiving entities
Our Model of Cryptographic Store or Transfer Bugs. Encryption may occur in tandem with Verification or it
may precede Verification serially, if the ciphertext is signed or hashed. Encryption uses Key Management, and
Key Management likely uses Encryption and Verification to handle keys - click on image for detailed view
KMN is a class of bugs related to key management. Key management comprises key generation, selection,
storage, retrieval and distribution, and determining and signaling when keys should be abandoned or replaced. A
particular protocol may use any or all of these operations. Key management could be by a third party, the
source, or the user - thus the KMN area intersects the Source and User areas. A third-party certificate
authority (CA) distributes public keys in signed certificates. Key management often uses a recursive round of
encryption and decryption, and verification to establish a shared secret key or session key before the actual
plaintext is handled.
ENC is a class of bugs related to encryption and decryption. Encryption is by the source, decryption is
by the user. The encryption/decryption algorithm may be symmetric, that is uses the same key for both, or
asymmetric, which uses a pair of keys, one to encrypt and the other to decrypt. Public key cryptosystems are
asymmetric. Ciphertext may be sent directly to the user, and verification accompanies it separately. The red
line is a case where plaintext is signed or hashed and then encrypted.
VRF is a class of bugs related to verification. Verification takes a key and either plaintext or
ciphertext, signs or hashes it, then passes the result to the user. The user uses the same key or the other key
from the key-pair to verify data integrity or source. Note that hash alone without any other mechanism cannot be
used to verify source or to protect data integrity against attackers. However, it can be used to protect data
integrity against channel errors.
In the cases of symmetric encryption, one secretly shared key (shKey) is used. The source encrypts with shKey,
and the user decrypts also with shKey. In the cases of asymmetric encryption, pairs of mathematically related
keys are used. The source pair is pbKeySrc and prKeySrc; the user pair is pbKeyUsr and prKeyUsr. The source
encrypts with pbKeyUsr and signs with prKeySrc. The user decrypts with prKeyUsr and verifies with pbKeySrc.