Upload
shavonne-bailey
View
222
Download
3
Embed Size (px)
Citation preview
doc.: IEEE 802.15-10-0273-02-0006
Submission
<May 2010>
Slide 1
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Generalized secure services to accommodate cryptos]Date Submitted: [13 May, 2010]Source: [Masayuki Kanda, Shin’ichiro Matsuo, Masahiro Kuroda, Grace Sung, Ryuji Kohno, Toshinori Fukunaga] Company [IPA,NICT, NTT]Address [4-2-1 Nukui-Kitamachi, Koganei, Tokyo, Japan(NICT) ]Phone:[+81-42-327-6886], FAX: [+81-42-327-5519], E-Mail:[[email protected], [email protected], [email protected], [email protected], [email protected], [email protected]]
Abstract: [This document explains the updates for security services in the TG6 Draft (revision 4) 15-10-0245-04-0006-tg6-draft.doc to the TG6 group. The proposal normative text is 15-10-272-02-0006-generalized-security-services.doc. ]
Purpose: [Discussion in 802.15.6 Task Group ]
Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.
<M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
doc.: IEEE 802.15-10-0273-02-0006
Submission
Generalized secure services to accommodate cryptos
Masayuki Kanda [IPA]
Shin’ichiro Matsuo, Masahiro Kuroda, Grace Sung, Ryuji Kohno [NICT]
Toshinori Fukunaga [NTT]
<May 2010>
Slide 2 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
doc.: IEEE 802.15-10-0273-02-0006
Submission
Outline• Addition of Security services using Camellia cipher
– Our normative text describes details of the security services process in chapter 8 that can use AES and Camellia ciphers
– Camellia is assigned to the field value “1” in the message security protocol field
• Amendment of Security association frames– Frame payload format for security disassociation frames are revised to
add security suit selector
• Other points– Technical Comment
• The length of MIC should be extended to enhance collision resistance
– Editorial Comments• Security association frame is corrected because of mistakes• KMAC calculations in 8.1.5 and 8.1.6 are corrected because of mistakes• Improper references and other mistakes are revised• Explanation of Camellia-CCM are added in Chapter 3 – Definitions
<May 2010>
Slide 3 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
doc.: IEEE 802.15-10-0273-02-0006
Submission
• For AES and Camellia, all modes of operation described in this document can be shared without any modifications
– SP800-38B/C (also ISO/IEC 19772) only specifies “Prerequisites: block cipher CIPH (with block size b)”, not “AES”
– AES and Camellia have perfectly convertible interface
Addition of Security services using Camellia cipher<May 2010>
Slide 4 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
< Ref > SP800-38B CMAC Generation <Ref> SP800-38C CCM Generation-Encryption Process
doc.: IEEE 802.15-10-0273-02-0006
Submission
Addition of Security services using Camellia cipher• Implementation outline for CCM
<May 2010>
Slide 5 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
B1 B2B0 BmB3
ctr1
ctr2
ctr0
ctrm
ctr3
Unencrypted Frame Payload
CIPHK
CIPHK
CIPHK
CIPHK
CIPHK
CIPHK
B1 B2MIC BmB3
Encrypted Frame Payload
CIPHK
CIPHK
CIPHK
CIPHK
Counter(Unencrypted)
AES Camellia
AES-CCM Camellia-CCM
CCM Process(Independence of ciphers)
Cipher(CIPHK)
Key (K)
message security protocol is “0”
message security protocol is “1”
Cipher is selected, depending on the message security protocol field in the Security_suite_selector (Ref: in 6.3.2.3.4 Table 7)
doc.: IEEE 802.15-10-0273-02-0006
Submission
Addition of Security services using Camellia cipher
8. Security Services Proposal• All present descriptions of chapter 8 can be duplicated only
except algorithm name and reference
<May 2010>
Slide 6 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
(Chap. 8.3.1) Secured frames shall be authenticated, and encrypted/decrypted when required, based on AES-128 CCM, i.e., the CCM mode as specified in the NIST Special Publication 800-38C, with the AES forward cipher function for 128-bit keys as specified in FIPS Pub 197 applied as the underlying block cipher algorithm.
Secured frames shall be authenticated, and encrypted/decrypted when required, based on Camellia-128 CCM, i.e., the CCM mode as specified in ISO/IEC 19772, with the Camellia forward cipher function for 128-bit keys as specified in ISO/IEC 18033-3 applied as the underlying block cipher algorithm.
Using AES-CCM Using Camellia-CCM
Example:
(Chap. 8.1) In these association protocols, the cipher-based message authentication code (CMAC) algorithm as specified in the NIST Special Publication 800-38B, with the AES forward cipher function under a 128-bit key as specified in FIPS Pub 197, is used to compute key message authentication codes (KMAC) and the desired shared master key. Specifically, the functional notation CMAC(K, M) represents the 128-bit output of the CMAC applied under key K to message M based on the AES forward cipher function.
In these association protocols, the cipher-based message authentication code (CMAC) algorithm as specified in the NIST Special Publication 800-38B, with the Camellia forward cipher function under a 128-bit key as specified in ISO/IEC 18033-3, is used to compute key message authentication codes (KMAC) and the desired shared master key. Specifically, the functional notation CMAC(K, M) represents the 128-bit output of the CMAC applied under key K to message M based on the Camellia forward cipher function.
Using AES-CMAC Using Camellia-CMAC
doc.: IEEE 802.15-10-0273-02-0006
Submission
Addition of Security services using Camellia cipher• Our proposal for revision: Merger of both descriptions
– Algorithm name: change “AES” to “128-bit block cipher(-based)”
– Reference: change “NIST SP” to “ISO/IEC standard”
– Clarification for algorithm selection; i.e., Message Security Protocol
<May 2010>
Slide 7 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
(Chap. 8.3.1) Secured frames shall be authenticated, and encrypted/decrypted when required, based on 128-bit block cipher-based CCM, i.e., the CCM mode as specified in ISO/IEC 19772, with the 128-bit block cipher-based forward cipher function for 128-bit keys as specified in ISO/IEC 18033-3 applied as the underlying block cipher algorithm, depending on the message security protocol in the security suite selector of the frame payload of the first Security Association frame.
Proposal - Generalized version
(Chap. 8.1) In these association protocols, depending on the message security protocol in the security suite selector of the frame payload of the first Security Association frame or the Security Disassociation frame, the cipher-based message authentication code (CMAC) algorithm as specified in the NIST Special Publication 800-38B, with the 128-bit block cipher-based forward cipher function under a 128-bit key as specified in ISO/IEC 18033-3, is used to compute key message authentication codes (KMAC) and the desired shared master key. Specifically, the functional notation CMAC(K, M) represents the 128-bit output of the CMAC applied under key K to message M based on the 128-bit block cipher-based forward cipher function.
Using CMAC
Using CCM
doc.: IEEE 802.15-10-0273-02-0006
Submission
Amendments of Security association frames• Frame payload format for security disassociation frames
are revised to add security suit selector
– 8.1.6 Disassociation
<May 2010>
Slide 8 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
RecipientAddress
SenderAddress
SenderNonce
DA_KMACRecipientAddress
SenderAddress
SecuritySuite
Selector
SenderNonce
DA_KMAC
Octets:Octet order:
(TG6 Draft rev.4)
0-5 0-5 0-1 0-15 0-76 6 2 16 8
(Proposal)Octets:
Octet order: 0-5 0-5 0-15 0-76 6 16 8
The node and the hub shall compute DA_KMAC, depending on the message security protocol in the Security_Suite_Selector, as follows: P = CMAC(MK, Address_A || Address_B || Nonce_A || Security_Suite_Seletor) DA_KMAC = LMB_64(P)
The node and the hub shall compute DA_KMAC as follows: P = CMAC(MK, Address_A ||
Address_B || Nonce_A) DA_KMAC = LMB_64(P)
* CMAC means AES-CMAC definitively
(TG6 Draft rev.4) (Proposal)
doc.: IEEE 802.15-10-0273-02-0006
Submission
Other points – Technical Comment• The length of MIC should be extended to enhance collision
resistance– 32-bit MIC is too short to achieve collision resistance from the aspect of
cryptology
– SP800-38C also states “value of Tlen that is less than 64 shall not be used without a careful analysis of the risks of accepting inauthentic data as authentic”
– If you can, should extend to 64-bit (8-octets) or more
(Chap. 8.3.1 & 8.3.1.5) The length of what is referred to as the Message Authentication Code (MAC) for message (frame) authentication in NIST Special Publication 800-38C but as the Message Integrity Code (MIC) in this standard—to be distinguished from another accustomed standing of the term MAC for medium access control—shall be four octets. That is, in the NIST Special Publication 800-38C, t = 8.
<May 2010>
Slide 9 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
doc.: IEEE 802.15-10-0273-02-0006
Submission
Other points – Editorial Comments • Security association frame (Fig. 17) is corrected
• KMAC calculations in 8.1.5 and 8.1.6 are corrected– The length of resultant KMAC is 128-bit, while the length of KMAC
field is 64-bit
– Need to add the “LMB_64” truncation
• Improper references– FIPS 186-2 is changed to FIPS 186-3
– FIPS 180-2 is changed to FIPS 180-3
<May 2010>
Slide 10 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
RecipientAddress
SenderAddress
SecuritySuite
Selector
AssociationSequenceNumber
SecurityAssociation
Data
(TG6 Draft rev.4)
0-5 0-5 0-1 0 L-R6 6 2 1 72
(Correction)
RecipientAddress
SenderAddress
SecuritySuite
Selector
AssociationSequenceNumber
SecurityAssociation
Data
0-5 0-5 0 0 L-R6 6 1 1 72
doc.: IEEE 802.15-10-0273-02-0006
Submission
Why should ready to multiple cipher suites?• Even when one of algorithms in the cipher suites is
compromised, it is easy to change to more secure one– This kind of concept, “algorithm agility,” comes common recent years
• At least two kinds of cipher should be working to achieve risk hedging
– It probably takes long time - over 18 months - to provide “new” products equipped with alternative cipher
– It is difficult to replace current products to secure ones in a short time if alternative products are not ready
• Cipher selection policy is greatly influenced by governmental security policy
<May 2010>
Slide 11 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
doc.: IEEE 802.15-10-0273-02-0006
Submission
Proposal on Selection Criteria for Cipher Suites1. Security
Selected algorithms must be resistant to cryptanalytic attacks
2. Performance on a variety of typical platformsThis includes time and space efficiency on both software and hardware
3. EndorsementThe nature of any evaluations is also of great importance, especially those conducted
by widely recognized evaluation organizations and cryptographic community
4. Number of ciphersThe number of ciphers to be standardized should be as small as possibleTwo conditions to this principle exist(a) Selected algorithms should be selected as standard or recommendation
by various well-known organizations and region in the world(b) It is desirable to have available selected algorithms based on different
fundamental principles, such that if one becomes vulnerable to cryptanalytic attack, the another has a good chance of remaining secure
<May 2010>
Slide 12 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
doc.: IEEE 802.15-10-0273-02-0006
Submission
Selecting secure cryptographic algorithms• The important criteria is selecting from international standard.
– ISO/IEC JTC1 SC27/WG2 standardizes cryptographic algorithms
– ISO standardization process includes careful reflection of reliable evaluation results.
– Collects evaluation results on security and efficiency from national bodies
– The reports from national bodies are based on technical results from academic papers, which are main stream of evaluation activities
– Members from national evaluating organization/activities, such as NIST and CRYPTREC, give deep contribution to ISO standard.
– For national usages, we must consider the international standard due to WTO/TBT.
• Both AES and Camellia are standardized in ISO/IEC JTC1.
<May 2010>
<M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
Slide 13
doc.: IEEE 802.15-10-0273-02-0006
Submission
Endorsement – Open Evaluation Activity• AES project sponsored by USA
– US standard encryption “AES” was produced after an open call and four-year evaluation using a transparent and open process through industry-academic-government collaboration
– One winner “Rijndael” was selected from 15 submission algorithms
• CRYPTREC activity sponsored by Japan– “The e-Government Recommended Ciphers List” for Japanese
government systems was produced after an open call and three-year evaluation through industry-academic-government collaboration
– “Camellia” has been confirmed to be secure
• NESSIE project sponsored by European Commission– “The NESSIE portfolio of strong cryptographic primitives” was
produced after an open call and three-year evaluation using a transparent and open process through industry-academic-government collaboration
– Only “Camellia” was selected from 10 submission algorithms
– “AES” was added by NESSIE secretariat
<May 2010>
Slide 14 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
doc.: IEEE 802.15-10-0273-02-0006
Submission
Security Evaluation Results by CRYPTREC• No major defect is reported for Camellia
– Despite many analysis of security, Camellia is still secure against known attacks– Related key attack is not reported, though the same attack is reported for AES
• Secure against current known attacks– Linear cryptanalysis– Differential cryptanalysis– Truncated linear cryptanalysis– Truncated differential cryptanalysis– Higher order differential cryptanalysis– Impossible differential cryptanalysis– Interporation Cryptanalysis– Linear sum cryptanalysis– Slide cryptanalysis
• Timing attack on cache memory is reported.However, this is NOT issue of the algorithm and fixed by other implementation techniques
<May 2010>
Slide 15 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
doc.: IEEE 802.15-10-0273-02-0006
Submission
What’s Camellia• 128-bit block cipher (allowing key sizes of 128, 192, and 256
bits), jointly developed in 2000 by NTT & Mitsubishi– Compatible interface with AES
• World’s highest security and efficiency – technically comparable to AES
• Ready for easy usage circumstance
– Camellia essential patents can be used at no charge by any user without concluding royalty-free licensing agreement
– Already adopted to various international standards & recommendations
– Already supported into various major open source software, e.g., Mozilla, OpenSSL, Linux, FreeBSD and Kerberos
– NTT’s open source codes of Camellia free of charge through multiple OSS licenses (GPL, LGPL, BSD, MPL, OpenSSL)
• Began to collaborate with MIT and Kerberos Consortium
<May 2010>
Slide 16 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
doc.: IEEE 802.15-10-0273-02-0006
Submission
Security• Achievement of the world’s highest resistant security against
known attacks– NO vulnerabilities of Camellia with any size of keys are found against
state-of-the-art attacks by world’s top-class researchers (over 40 papers) – World’s top-class resistant security (security margin) against unknown
attacks in the future
[FYI] In 2009, AES-192/256 can be theoretically broken using related-key attack proposed by Alex Biryukov, et al.
• Suitable to backup; based on different structure from AES– Adoption of Feistel structure (like DES), Not SPN structure (like AES)
<May 2010>
Slide 17 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
Breakable rounds 7 8 9 10 11 12 13 14 15 Original
128-bit keysSuccessful
attacksSuccessful
attacksBest Known
attacksUnknown attacks
Unknown attacks
Unknown attacks
Unknown attacks
Unknown attacks
Unknown attacks
Unknown attacks up to 18 rounds
256-bit keysSuccessful
attacksSuccessful
attacksSuccessful
attacksSuccessful
attacksBest Known
attacksUnknown attacks
Unknown attacks
Unknown attacks
Unknown attacks
Unknown attacks up to 24 rounds
(2009.9 at the present time)
Breakable rounds for AES 6 7 8 9 10 11 12 13 14 15
128-bit keysSuccessful
attacksBest Known
attacksUnknown attacks
Unknown attacks
Unknown attacks
256-bit keysSuccessful
attacksSuccessful
attacksSuccessful
attacksSuccessful
attacksSuccessful
attacksSuccessful
attacksSuccessful
attacksSuccessful
attacksBest Known
attacks
Break
doc.: IEEE 802.15-10-0273-02-0006
Submission
Performance and Flexibility• Achievement of high-speed software without dependence on
platform such as PCs or smart cards– For PCs: Performance is achieved by using many registers, pre-
computed large tables and powerful instruction sets
– For smart cards: Containment of memory usage is achieved using small tables and on-the-fly subkey generation
• Achievement of world's smallest hardware implementation with world top-class efficiency
– Substitution tables can be implemented using an inversion function over GF(28) and affine transformations
– F function can be shared between data randomization block and key scheduler
– On-the-fly subkey generation technique can be used with secret key and intermediate keys
<May 2010>
Slide 18 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
doc.: IEEE 802.15-10-0273-02-0006
Submission
Performance and Flexibility• Performance of Camellia is comparable to that of AES on
any platform– Designed world’s smallest circuit for 128-bit block ciphers (smaller
than 10 Kgates) with world top-class efficiency
<May 2010>
Slide 19 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
71.6Mbps/6.4KGs
204.6Mbps/6.3KGs
325.8Mbps/6.5KGs
1908Mbps/20.8KGs
1051Mbps/11.9KGs
567.3Mbps/9.1KGs
969.7Mbps/14.2KGs
2155Mbps/29.8KGs1881Mbps/
44.3KGs
1422Mbps/31.1KGs
(128-bit key ASIC)
971.2Mbps/7.8KGs
2024Mbps/13.2KGs
2728Mbps/20.0KGs
doc.: IEEE 802.15-10-0273-02-0006
Submission
Performance and Flexibility• Anyone can implement Camellia using open documents
Quote: “Hardware-Focused Performance Comparison for the Standard Block Ciphers AES, Camellia, and Triple-DES,”by Akashi Satoh, et al. (IBM Japan Ltd)
http://www.hpl.hp.com/conferences/isc03/pdfs/IBM%20Japan.pdf
<May 2010>
Slide 20 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
Specification available from Camellia website
doc.: IEEE 802.15-10-0273-02-0006
Submission
Performance and Flexibility• Comparison between AES and Camellia (by Satoh, et al.)
<May 2010>
Slide 21 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
doc.: IEEE 802.15-10-0273-02-0006
Submission
Performance and Flexibility• AES & Camellia Combination Hardware
Quote: “Unified Hardware Architecture for 128-bit Block Ciphers AES and Camellia ,” by Akashi Satoh (IBM Japan Ltd)
http://www.iacr.org/workshops/ches/ches2003/presentations/SatohMorioka_2003.pdf
<May 2010>
Slide 22 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
doc.: IEEE 802.15-10-0273-02-0006
Submission
<May 2010>
<M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
Slide 23
Organization Years Standard
ISO/IEC JTC1 2005 18033-3 (Block Cipher)
ITU-T 2010 Y.2704 (NGN)
NESSIE 2003 European Recommendation
CRYPTREC 2003 e-Government Recommended Ciphers List
IETF 2004 RFC 3657 (S/MIME)
2005 RFC 4051 (XML)RFC 4132 (SSL)RFC 4312 (IPsec)
2009 RFC 5528 (CTR, CCM)RFC 5529 CTR,CCM for IPsecRFC 5581 (PGP)
RSA Lab. 2006 PKCS #11
TV-Anytime Forum 2003 Bi-directional Metadata Delivery Protection
2004 TV-Anytime Rights Management and Protection Information for Broadcast Applications
Status on Standardization of Camellia
doc.: IEEE 802.15-10-0273-02-0006
Submission
<May 2010>
<M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
Slide 24
Organization Standard Status
IETF tls-rfc4132bis (TLS) Finalizing
ipsec-camellia-cmac96and128 (CMAC in IPsec) In discussion
ipsec-camellia-gcm (GCM in IPsec) In discussion
tls-camellia-ecc-sha (ECC and SHA-2 in TLS) In discussion
tls-camellia-psk (PSK in TLS) In discussion
tls-camellia-gcm (GCM in TLS) In discussion
srtp-camellia (SRTP) In discussion
krb-wg-kanno-camellia (Kerberos 5) In discussion
keyprov-pskc (PSKC) In discussion
smime-cms-rsa-kem (RSA-KEM in S/MIME) Finalizing
RSA Lab. GCM in PKCS #11 In discussion
W3C XML Security (Encryption) In discussion
XML Security ( Cross-Reference) In discussion
Status on Standardization of Camellia (Ongoing)
doc.: IEEE 802.15-10-0273-02-0006
Submission
Users & Products equipped with Camellia• Major Open Source Software
• Users
Government systems, Financial services, Online Game (eg. Capcom), SNS services (eg. mixi), Network services, Manufacturing systems, Universities, etc.
• Supported Venders: More than 60 companies adopt Camellia into their products
<M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>
<May 2010>
NTT Software CipherCraft/Mail, CipherCraft/VPN, CipherCraft/File, etc
NTT Electronics Camellia LSI, IP Super-Compact MPEG-2 Codec, etc
NTT-AT Smart Leak Protect, File Lock II, etc
Mitsubishi Electric Cryptopia, MistyGuard(R)<CRYPTOFILE(R) PLUS>, etc
Renesas Technology SH7781 MPU and MCU/SuperH RISC engine Family
AuthenTec (prev. SafeNet) QuickSec Toolkit
THALES (prev. nCipher) netHSM, nShield series, miniHSM
IAIK IAIK-JCE, iSaSiLk, CMS-S/MIME, IAIK-XSECT
Bloombase Spitfire Ethernet Encryptor, Spitfire StoreSafe, Spitfire Messaging, etc.
<May 2010>
Toolkit i. OpenSSL toolkit 0.9.8c/1.0.0 (or later)
ii. NSS (Network Security Services) 3.12 (or later)
iii. Crypto++ library 5.4 (or later)
iv. The Legion of the Bouncy Castle 1.30 (or later)
v. GNU Transport Layer Security Library 2.20 (or later)
OS Kernel
i. FreeBSD 6.4 (or later)/7.0 (or later)
ii. Linux kernel 2.6.21 (or later)
iii. Fedora Core 7 (or later)
Application
i. Firefox 3.0 (or later)
ii. ipsec-tools 0.7 (or later)
iii. GnuPG 2.0 (or later)
iV. Kerberos KRB5 1.9 (or later)
doc.: IEEE 802.15-10-0273-02-0006
Submission
For More Detail …• Please see the Camellia website
http://info.isl.ntt.co.jp/crypt/eng/camellia/– Introduction handout– Specifications– Technical Information– Open Source codes– Test Vectors
• Also see Cryptographic Hardware Project websitehttp://www.aoki.ecei.tohoku.ac.jp/crypto/web/cores.html
– Camellia sample hardware core exists
<May 2010>
Slide 26 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>