Message-ID: <2138832542.3494.1657136097029.JavaMail.confluence@wiki.campllc.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3493_822652823.1657136097027" ------=_Part_3493_822652823.1657136097027 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html CB2: Types of Cryptographic Algorithms

# CB2: Types of Cryptographic Algorithms

There are two different types of keyed cryptographic algorithms,= which use very different types of key management. This section discusses t= hose keyed algorithms and also two other important cryptographic primitives= , hash functions and random number.

## Symmetric= Algorithms

In a symmetric algorithm, the sender and receiver use the same key (or k= eys that are related to each other in some trivial-to-derive way). Alice us= es k1 to encrypt; Bob uses k1 to decrypt. Alice uses k2 to authenticate; Bo= b uses k2 to validate. Symmetric algorithms have two significant properties= :

• They are fast (which translates into implementations being low cost). F= or example, AES, a symmetric encryption algorithm, can encrypt 81 MB per se= cond on a 2 GHz processor, or generate authentication codes on 1,000,000 me= ssages per second with a size of 100 bytes per message.
• They require secure, private key exchange. Before Alice and Bo= b can use a key k to communicate, they must securely agree on k in such a w= ay that no other party (except perhaps a trusted center) knows k. This mean= s that Alice and Bob must have some kind of pre-existing relationship to us= e symmetric cryptography.
• NOTE: In a vehicular setting, vehicles are often encountering each othe= r for the first time and do not have a pre-existing relationship. This is o= ne of the main reasons why symmetric key cryptography is not being consider= ed for use in authenticating V2V safety messages.

## Public Ke= y Algorithms

In an asymmetric or public key algorithm, the encryption and de= cryption, or authentication and validation, keys come as a pair, Pub an= d Priv, with the property that they are related but that it is very ex= pensive (in terms of computer time) for someone who only knows Pub= to work out Priv. Pub is called the public key. Priv= is called the private key. The private key is not widely shared and u= sually known only to the key owner; the public key can be distributed widel= y. They are used this way:

• For confidentiality: Alice uses Bob=E2=80=99s (note, not Alice=E2=80=99= s) public key to encrypt the message. Only Bob knows his own private key, s= o only Bob can decrypt the message.
• For authentication: Alice uses her own private key to generate the auth= entication code =E2=80=93 for a public key algorithm, this is called si= gning. Bob uses Alice=E2=80=99s (note, not Bob=E2=80=99s) public key t= o validate the authentication code =E2=80=93 for a public key algorithm, th= e authentication code is called a signature and the validation is = called verification. If the signature verifies with Alice=E2=80=99= s public key, then the signature was generated with Alice=E2=80=99s private= key and the message was not modified. Because only Alice knows her own pri= vate key, that means that Alice generated the signature and so that the mes= sage came from Alice. For performance reasons, an actual implementation wou= ld perform the signature operation on a checksum of the message only.

Public-key algorithms have two significant properties:

• They are relatively slow compared to symmetric algorithms (whi= ch translates into implementations being more expensive in terms of process= ing compared to symmetric algorithms). For example, ECDSA-256, the public k= ey algorithm that is used in the CAMP VSC3 design, can generate about 1500 = signatures per second on a 2 GHz processor and can verify only about 300 si= gnatures per second.
• They require authenticated key exchange, but the key exchange = can be public. If Alice has some assurance that a public key belon= gs to Bob, she can use that key to verify Bob=E2=80=99s signed messages or = encrypt messages to him even if many other people know the public key as we= ll. Alice knows that a public key belongs to Bob usually because the CA att= ests to it by signing Bob=E2=80=99s public key. Bob=E2=80=99s public key is= signed by the CA and is referred to as Bob=E2=80=99s certificate. So long = as Alice and Bob trust the CA and have access to the CA=E2=80=99s public ke= y, they can trust that keys signed by the CA are genuine. This makes public= key cryptography ideal for settings where two parties encounter each other= briefly and need to trust each other=E2=80=99s communications, even if the= y do not have access to an online key service. This is the relevan= t setting for V2V communications, which is why CAMP VSC3 and IEEE 1609.2 us= e public key cryptography.

## Random Number Generators

Random number generators are used to generate keys and other random data= within a system that uses cryptography. Since the security of a system dep= ends on private and secret keys being unobtainable through unauthorized exp= osure, it is important that the random number generators used to generate t= hem are good. In this context, =E2=80=9Cgood=E2=80=9D means a number of thi= ngs:

• An attacker must not be able to determine the next output from the rand= om number generator, no matter how much previous output the attacker has se= en. This means that the output must be statistically random and contain no = bias. If the random number generator is used to generate an integer modulo = some modulus n, all numbers between 0 and n-1 must be equ= ally probable with no bias towards particular values.
• If the random number generator uses an internal state, an attacker must= not be able to guess the internal state of the random number generator and= use this to predict output. This means that:
• The internal state must be large enough to be infeasible to guess by br= ute force
• The initialization process that initialized the internal state must be = infeasible to reproduce
• If the random number generator uses some hardware-produced randomness s= ource, the output from this source must be infeasible to reproduce

As well as secret and private keys, random number generators are used fo= r other purposes within the SCMS:

• When signing with Elliptic Curve Digital Signature Algorithm (ECDSA), a= fresh entirely random number must be generated for each signature with the= same key. Repeated random numbers, random numbers with a bias, or random n= umbers with a known relationship to each other will reveal the private key.=
• Random numbers are used by the PCA when creating implicit certificates = or when expanding a butterfly signing key (see SCP1: Butterfly Keys). If these random numbers are = not good, it can result in the Registration Authority (RA) being able to tr= ack a device, or even the PCA=E2=80=99s private key being revealed.
• Random numbers are used to generate Linkage Seeds (LSs) for linkage cha= ins (see CB3: Pub= lic Key Infrastructure, SCP2: Linkage Values). If these random numbers are not good, it can re= sult in a device being trackable by a Linkage Authority (LA) or the PCA.

All SCMS components, as well as EEs, must be equipped with industrial qu= ality random number generators, e.g., one of the Approved Random Number Generators.

------=_Part_3493_822652823.1657136097027--