Key Encapsulation:
An Emerging Paradigm for
Public

Key Cryptography
Burt Kaliski, RSA Laboratories
RSA Conference 2002 Japan
May 29
–
30,
2002
Summary
•
Most specifications of public

key encryption
follow the original “encrypt/decrypt” model from
25 years ago
•
New model is emerging, based on work of Shoup
and others: key encapsulation, with better
flexibility and security proofs
•
Recommend transition over time to new model
Original Model
•
Bob has public key / private key pair
•
Alice encrypts message
M
with Bob’s public key
to produce a ciphertext
C
:
C
= E(
PubKey
B
,
M
)
•
Bob decrypts
C
with his private key:
M
= D(
PrivKey
B
,
C
)
Limitations
•
Message length:
Length of
M
may be limited
•
Malleability:
Encryption may not protect message
integrity
•
Mathematical properties:
Encryption of related
messages may be related
•
Modeling:
DH doesn’t fit well
Traditional Remedies
•
Typically, some message padding is applied to
address these limitations, but current approaches
to RSA encryption are less than ideal:
–
PKCS #1 v1.5 padding is
ad hoc
, doesn’t provide
integrity
–
RSA

OAEP provides integrity and is provably secure,
but bounds aren’t tight
•
Message length is still bounded, and DH needs its
own method
New Remedy: Two Layers
•
Public

key layer
(“key encapsulation”)
establishes a random symmetric key
•
Symmetric

key layer
protects data with the
established symmetric key and symmetric
algorithm
–
data can be of any length
•
Layers are independent
Two

Layer Approach
Public

Key Layer
Symmetric

Key Layer
symmetric key
Public

Key Layer:
Key Encapsulation
(Shoup 2001)
•
Encryption:
Alice generates a symmetric key
W
and a ciphertext
C
that “encapsulates”
W
:
(
C
,
W
) = E(
PubKey
B
)
•
Decryption:
Bob regenerates
W
from
C
:
W
= D(
PrivKey
B
,
C
)
Two Layers with Key
Encapsulation
E
D
symmetric key
W
Symmetric

Key Layer
public key
private key
C
Addressing the Limitations
•
Modeling:
DH, PSEC, RSA, other PKC all fit
•
Message length:
Length of
M
not limited
•
Malleability:
Symmetric layer can provide integrity
protection
•
Mathematical properties:
Symmetric keys are
unrelated; symmetric layer avoids mathematical
properties
Don’t We Do This Already?
•
Many specifications (including S/MIME) have two
layers:
–
message encrypted with symmetric key
–
symmetric key encrypted with public key
•
But the symmetric key is generated first
then
encrypted; more than needed, and results in a
looser (or no) proof of security
Related Research
•
Damgard, Zheng

Seberry, Bellare

Rogaway
(1991

1993): early constructions
•
Abdalla

Bellare

Rogaway (1998): DH scheme
•
Fujisaki

Okamoto (1999): new general conversion
•
Okamoto

Pointcheval (2001): REACT
transformation
•
Shoup (2001): key encapsulation for ISO proposal
•
Coron

Handschuh

et al.
(2002): GEM
Encapsulation Using RSA
(RSA

KEM)
•
Encrypt with public key (
n
,
e
):
(
C
,
W
)
–
r
R
[0,
n

1]
–
C
r
e
mod
n
–
W
䭄䘨
r
)
•
Decrypt with private key (
n
,
d
):
C
W
–
r
C
d
mod
n
–
W
䭄䘨
r
)
(KDF = key derivation function)
Security Sketch: RSA

KEM
•
Encrypt:
C
r
e
mod
n
,
W
䭄䘨
r
)
•
Decrypt:
r
C
d
mod
n, W
䭄䘨
r
)
•
Goal: Distinguish (
C
,
W
) from (
C
, random), given
access to Decrypt
•
Distinguisher
剓R

楮癥牴敲i楮慮摯洠潲慣汥o
浯摥m
–
adversary must recover
r
(= invert) to distinguish
–
inverter simulates Decrypt by looking up (
C
,
W
) from
old KDF call
—
or making new one
–
“tight” bounds
—
distinguish, invert in
獡浥s瑩浥
Encapsulation Using DH
•
Encrypt with public key (
p
,
q
,
g
,
y
):
(
C
,
W
)
–
r
R
[1,
q

1]
–
C
g
r
mod
p
–
Z
y
r
mod
p
–
W
䭄䘨
C

Z
)
•
Decrypt with private key (
p
,
q
,
g
,
x
):
C
W
–
Z
C
x
mod
p
–
W
䭄䘨
C

Z
)
Symmetric

Key Layer
•
Depends on overall objective:
Asymmetric Objective
Symmetric

Key Layer
Encryption w/Integrity
Encryption w/Integrity
Key Transport (1

pass)
Key Wrapping
Key Agreement
Key Derivation &
Confirmation
Asymmetric Encryption
w/Integrity
E
D
symmetric key
W
Symmetric Encryption
w/Integrity
public key
private key
C
M
M
Symmetric Encryption w/Integrity
•
Encrypt message
M
with integrity protection
–
optional label
L
•
“Data encapsulation”, in Shoup’s terminology
•
In IEEE P1363a, ISO/IEC 18033

2,
et al.
, hash
function

based stream cipher + MAC
•
Alternatively, block cipher mode with integrity
protection (e.g., OCB, CCM)
Asymmetric Key Transport
(1

pass)
E
D
symmetric key
W
Symmetric Key Wrapping
public key
private key
C
K
K
Symmetric Key Wrapping
•
Encrypt (“wrap”) key
K
with integrity protection
–
optional label
L
•
Special case of symmetric encryption w/integrity
•
Symmetric encryption methods, or …
•
In ANSI X9.44 draft, AES Key Wrap
AES Key Wrap
•
NIST

proposed method for wrapping “key data”
with an AES key
–
six

pass iterative construction
–
confidentiality and integrity
•
With new model, AES Key Wrap can be a common
method for asymmetric and symmetric key
transport
Asymmetric Key Transport
(1

pass) with AES Key Wrap
E
D
symmetric key
W
AES Key Wrap
public key
private key
C
K
K
RSA

KEM + AES Key Wrap
•
Asymmetric key wrapping with only RSA primitive
and AES
•
Wrap with public key:
K
(
C
0
,
C
1
)
–
r
R
[0,
n

1]
–
C
0
r
e
mod
n
–
W
䅅A

䭄䘨
r
)
–
C
1
䅅A

䭥y坲W瀨
W
,
K
)
•
Unwrap with private key: (
C
0
,
C
1
)
K
–
r
C
0
d
mod
n
–
W
䅅A

䭄䘨
r
)
–
K
䅅A

䭥y啮U牡瀨
W
,
C
1
)
(AES

KDF to be defined)
Key Agreement in Two Layers
(one key

pair case)
E
D
symmetric key
W
Symmetric Key Derivation
& Confirmation
public key
private key
C
K
K
•
Derive and confirm new key
K
•
In SSL/TLS, three passes with MAC, KDF:
•
Other approaches may be applied
Symmetric Key Derivation &
Confirmation
N
B
N
A
,
MAC(
W
, 1
N
A

N
B
)
MAC(
W
, 2
N
A

N
B
)
K
= KDF(
W
,
N
A

N
B
)
(some aspects simplified …)
More on SSL/TLS Handshake
•
Symmetric

key level protects against weaknesses
in PKCS #1 v1.5 encryption
–
PKCS #1 v1.5 encryption plus KDF, “client finished”
can be modeled as key encapsulation
•
New research result (Crypto 2002): provably
secure under variant of RSA assumption
–
“gap

partial

RSA” problem: find part of RSA inverse,
given oracle that checks whether part is correct
RSA Encapsulation in SSL/TLS
Handshake
(some details omitted)
•
Encrypt with public key:
(
C
,
W
,
T
)
–
(
r
0

r
1
)
R
[0,
n

1]
–
C
(
r
0

r
1
)
e
mod
n
–
W
䭄䘨
r
1
)
–
T
䵁M(
r
1
)
•
Decrypt with private key (
n
,
d
): (
C
,
T
)
W
–
(
r
0

r
1
)
C
d
mod
n
–
W
䭄䘨
r
1
)
–
T
=?
MAC(
r
1
)
(
r
0
is padding;
r
1
is pre

master secret;
W
is session key;
T
is
“client finished” message;
W
,
T
derived via master secret,
not shown)
Security Sketch: RSA
Encapsulation in SSL/TLS
•
Encrypt:
C
(
r
0

r
1
)
e
mod
n
,
W
䭄䘨
r
1
),
T
䵁M(
r
1
)
•
Decrypt:
(
r
0

r
1
)
C
d
mod
n
,
W
䭄䘨
r
1
),
T
=?
MAC(
r
1
)
•
Goal: Distinguish (
C
,
W
,
T
) from (
C
, random),
given access to Decrypt
•
Distinguisher
partial

RSA

inverter given
partial

RSA

inverse

checker in r.o. model
–
adversary must recover
r
1
(= partial

invert) to
distinguish
–
inverter simulates Decrypt by looking up (
r
1
,
W
,
T
) from
old KDF, MAC calls, checking
r
1
against
C
–
(reasonably) tight bounds given full details
Standardization
•
Many standards already use key encapsulation in
some form, though most don’t use the term
•
Key encapsulation is being proposed for several
standards, particularly for use of RSA with AES
keys
Key Encapsulation in Standards
DH
RSA
ANSI X9F1
(X9.63, X9.44 draft)
䥅䕅 倱㌶P
(P1363a draft, P1363b)
proposed
ISO/IEC 18033

2
(draft)
偋䍓‣P
港n
灲潰潳敤
匯䵉䵅
灲潰潳敤
卓䰯呌S
What about RSA

OAEP?
•
RSA

OAEP, in many standards already, is fine for
current and new applications
–
asymmetric encryption w/integrity
–
provably secure in r.o. model
•
But security bounds aren’t ideal
–
inverting RSA (i.e., factoring) is fastest attack known,
but bounds don’t exclude faster ones
•
q
2
ratio in bounds, where
q
is number of queries to
Decrypt or random oracles
•
Also, architecture is not as flexible
–
AES Key Wrap can’t be employed directly
–
length of message is limited
A Gradual Transition
•
Improving the infrastructure over time …
1991
1995
2000
2005
2010
PKCS #1 v1.5
new
standards
& products
analysis
old
RSA

OAEP
new
standards
& analysis
products
RSA

KEM
new
& analysis
standards
& products
old
& more
Conclusions
•
Key encapsulation is a convenient way of
positioning public

key cryptography
•
A flexible model for new standards
•
Gradual transition recommended as standards
are upgraded, e.g., to support AES
Comments 0
Log in to post a comment