Camellia in OpenPGP: The Camellia Cipher in OpenPGP
The algorithm identifiers and rules for using Camellia in OpenPGP
Shaw, D., "The Camellia Cipher in OpenPGP", RFC 5581, DOI 10.17487/RFC5581, June 2009, <https://www.rfc-editor.org/info/rfc5581>.
@misc{rfc5581,
series = {Request for Comments},
number = 5581,
howpublished = {RFC 5581},
publisher = {RFC Editor},
doi = {10.17487/RFC5581},
url = {https://www.rfc-editor.org/info/rfc5581},
author = {D. Shaw},
title = {{The Camellia Cipher in OpenPGP}},
pagetotal = 3,
year = 2009,
month = jun,
} RFC text
Contents
Network Working Group D. Shaw
Request for Comments: 5581 June 2009
Updates: 4880
Category: Informational
The Camellia Cipher in OpenPGP
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document presents the necessary information to use the Camellia
symmetric block cipher in the OpenPGP protocol.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 2
3. Camellia . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 2
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
6. Normative References . . . . . . . . . . . . . . . . . . . . . 3
1. Introduction
The OpenPGP protocol [RFC4880] can support many different symmetric
ciphers. This document presents the necessary information to use the
Camellia [RFC3713] symmetric cipher in the OpenPGP protocol.
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Camellia
Camellia is specified in [RFC3713]. It is a 128-bit symmetric block
cipher (as are AES and Twofish in OpenPGP) that supports 128-bit,
192-bit, and 256-bit keys. This document defines the use of Camellia
in OpenPGP.
+---------------------+----------------------------------------+
| Camellia Key Length | OpenPGP Symmetric-Key Algorithm Number |
+---------------------+----------------------------------------+
| 128 | 11 |
| 192 | 12 |
| 256 | 13 |
+---------------------+----------------------------------------+
OpenPGP applications MAY implement Camellia. If implemented,
Camellia may be used in any place in OpenPGP where a symmetric cipher
is usable, and it is subject to the same usage requirements (such as
its presence in the Preferred Symmetric Algorithms signature
subpacket) as the other symmetric ciphers in OpenPGP.
While the OpenPGP algorithm preferences system prevents
interoperability problems with public key encrypted messages, if
Camellia (or any other optional cipher) is used for encrypting
private keys, there could be interoperability problems when migrating
a private key from one system to another. A similar issue can arise
when using an optional cipher for symmetrically encrypted messages,
as this OpenPGP message type does not use the algorithm preferences
system. Those using optional ciphers in this manner should take care
they are using a cipher that their intended recipient can decrypt.
4. Security Considerations
At publication time, there are no known weak keys for Camellia, and
the Camellia algorithm is believed to be strong. However, as with
any technology involving cryptography, implementers should check the
current literature, as well as the Camellia home page at
http://info.isl.ntt.co.jp/camellia/ to determine if Camellia has been
found to be vulnerable to attack.
5. IANA Considerations
IANA assigned three algorithm numbers from the registry of OpenPGP
Symmetric-Key Algorithms that was created by [RFC4880].
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of
the Camellia Encryption Algorithm", RFC 3713, April 2004.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
Author's Address
David Shaw
EMail: dshaw@jabberwocky.com
ISO Plain Language
On this page
§1Camellia in OpenPGP
OpenPGP can support different symmetric ciphers. This document gives the information needed to use Camellia, a symmetric block cipher with a 128-bit block size and keys of 128, 192 or 256 bits.
The RFC references the Camellia algorithm description in RFC 3713 and updates the OpenPGP message-format specification, RFC 4880.
Camellia is one cipher that OpenPGP can use to protect data. This RFC explains how OpenPGP identifies its different key lengths.
§2OpenPGP Algorithm Numbers
OpenPGP identifies a symmetric-key algorithm with a number. This RFC assigns number 11 to Camellia with a 128-bit key, number 12 to a 192-bit key, and number 13 to a 256-bit key.
These identifiers let OpenPGP implementations distinguish the Camellia key length when using the cipher.
OpenPGP uses a number to identify which Camellia key length a message uses. The three numbers in this RFC each match one of the defined key lengths.
§3Optional Support and Interoperability
OpenPGP applications MAY implement Camellia. If an application implements it, the cipher may be used anywhere a symmetric cipher is usable in OpenPGP and follows the same usage requirements as other symmetric ciphers, including algorithm preferences.
The RFC warns of interoperability problems if an optional cipher encrypts a private key or a symmetrically encrypted message. Those cases do not use the algorithm-preference system to avoid the problem, so the intended recipient needs to support the cipher. At publication, the RFC reports no known weak keys and says implementers should check current cryptographic literature.
Support for Camellia is optional. Before using it for a private key or a symmetrically encrypted message, make sure the recipient can decrypt it.