ISO/TR 14742:2010

TECHNICAL ISO/TR
REPORT 14742
First edition
2010-07-01
Financial services — Recommendations
on cryptographic algorithms and their
use
Services financiers — Recommandations sur les algorithmes
cryptographiques et leur utilisation

Reference number
©
ISO 2010
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2010 – All rights reserved

Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Measuring bits of security.2
3 Algorithm migration .3
4 Block ciphers .4
4.1 General .4
4.2 Keying options.4
4.3 Recommended block ciphers .5
4.4 Block size and key use .6
4.5 Modes of operation .6
4.6 Enciphering small plaintexts.7
4.7 Migrating from TDEA to AES.7
5 Stream ciphers.7
6 Hash functions.7
6.1 Hash functions and their properties.7
6.2 Hash functions based on block ciphers .8
6.3 Dedicated hash functions.8
6.4 Hash functions using modular arithmetic .10
6.5 Migrating from one hash function to another.10
7 Message authentication codes .11
7.1 Recommended MAC algorithms .11
7.2 MAC algorithms based on block ciphers.11
7.3 MAC algorithms based on hash functions .11
7.4 Length of the MAC.12
7.5 Message span of the key .12
8 Asymmetric algorithms.12
8.1 General .12
8.2 Factorization-based security mechanisms.14
8.3 Integer discrete logarithm-based security mechanisms.14
8.4 Elliptic curve discrete logarithm-based security mechanisms .15
8.5 Algorithm or key expiry .15
8.6 Digital signature schemes giving message recovery.15
8.7 Digital signatures with appendix .16
8.8 Asymmetric ciphers .16
9 Random number generation.18
Annex A (informative) Entity authentication and key management mechanisms .19
Bibliography.28

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In exceptional circumstances, when a technical committee has collected data of a different kind from that
which is normally published as an International Standard (“state of the art”, for example), it may decide by a
simple majority vote of its participating members to publish a Technical Report. A Technical Report is entirely
informative in nature and does not have to be reviewed until the data it provides are considered to be no
longer valid or useful.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/TR 14742 was prepared by Technical Committee ISO/TC 68, Financial services, Subcommittee SC 2,
Security management and general banking operations.
iv © ISO 2010 – All rights reserved

Introduction
The financial services industry has a clear need for cryptographic algorithms for a number of different
applications. ISO standards provide definitions for an extensive and comprehensive set of such algorithms.
However, as the state of the art of cryptology progresses and the power of computers increases,
cryptographic algorithms as well as cryptographic keys of a particular length all have a limited window of time
in which they can be considered secure. Furthermore, as neither the development of cryptology nor the
increase in computing power are entirely predictable, the collective wisdom of the cryptographic community as
to which algorithms and key lengths are secure is constantly evolving. For this reason it was felt that there
was an equally clear need in the financial services industry for guidance regarding the current and up-to-date
view in the cryptographic community about the security of cryptographic algorithms and their keys. It was also
felt that there was a need for appropriate guidance on migration from one algorithm or key length to another.
The ISO standards that define cryptographic algorithms for the financial services industry do not contain such
guidance, and by the evolving nature of the field, it would be difficult for them to do so. Hence, the need was
recognized for a document that could contain such guidance, and be updated more frequently than the five
year review cycle for ISO standards. This Technical Report is intended to be that document. The intention is to
update this Technical Report when the need arises, or at least every other year.
The strength requirements of a security mechanism can vary depending on the application(s) in which the
mechanism is being used and the way it is being used. The recommendations given in this Technical Report
are considered to be general purpose recommendations. Although it is accepted that there may exist low-risk
applications that do not warrant the level of cryptographic strength recommended in this Technical Report, it is
advisable that deviation from the recommendations only be made after appropriate analysis of the risks and in
the context of any rules and policies that might apply.
A special case of the above relates to the lifetime of protection required by the application and its data. For
example, if protection requirements are ephemeral (e.g. confidentiality is required only for one day, or
authentication is one-time) then this may be cause for allowing a deviation from the recommendations.
Conversely, if the data must remain protected for a very long period of time, then the keys and algorithms
used to provide the protection must be good for that duration, even if the keys are no longer in active use.
TECHNICAL REPORT ISO/TR 14742:2010(E)

Financial services — Recommendations on cryptographic
algorithms and their use
1 Scope
This Technical Report provides a list of recommended cryptographic algorithms for use within applicable
financial services standards prepared by ISO/TC 68. It also provides strategic guidance on key lengths and
associated parameters and usage dates.
The focus is on algorithms rather than protocols, and protocols are in general not included in this Technical
Report. However, in some cases, for example for some key agreement and some authentication protocols,
there is no “underlying” algorithm, and in a sense it is the protocol that constitutes the algorithm. In this case,
the mechanisms are included, in particular where they have security parameters that can be adjusted for
higher or lower security.
Algorithmic vulnerabilities or cryptographic keys of inadequate lengths are less often the cause of security
compromises in the financial industry than are inadequate key management or other procedural flaws, or
mistakes in the implementation of cryptographic algorithms or the protocols that use them. However,
compromises caused by algorithmic vulnerabilities are more systemic and harder to recover from than other
kinds of compromises.
This Technical Report deals primarily with recommendations regarding algorithms and key lengths.
NOTE Key management is covered in ISO 11568-1, ISO 11568-2 and ISO 11568-4.
The categories of algorithms covered in this Technical Report are:
⎯ block ciphers;
⎯ stream ciphers;
⎯ hash functions;
⎯ message authentication codes (MACs);
⎯ asymmetric algorithms:
⎯ digital signature schemes giving message recovery,
⎯ digital signatures with appendix,
⎯ asymmetric ciphers;
⎯ authentication mechanisms;
⎯ key establishment and agreement mechanisms;
⎯ key transport mechanisms.
This Technical Report does not define any cryptographic algorithms; however, the standards to which this
Technical Report refers may contain necessary implementation information as well as more detailed guidance
regarding choice of security parameters, security analysis, and other implementation considerations.
2 Measuring bits of security
For both block ciphers (Clause 4) and hash algorithms (Clause 6) the notion of “n bits of security” is introduced
(e.g. see NIST SP 800-57, 2007, 5.6.1). For a block cipher to have n bits of security means that an estimated
n
2 operations are needed to break the block cipher. Given a few plaintext blocks and corresponding ciphertext,
n–1
a block cipher with n bits of security would then require an average of 2 T of time to recover the encryption
key, where T is the amount of time needed to perform one encryption of a plaintext value and a comparison of
the result against the corresponding ciphertext value. For a hash algorithm to have n bits of security with
n
respect to collision resistance means that an estimated 2 calls to the hash function are necessary to find a
hash collision, that is, two messages that when hashed yield the same hash result.
Table 1 below reflects recommendations for when an algorithm with n bits of security can be used. The dates
coincide, where applicable, with the recommendations in NIST SP 800-57.
Table 1 — Recommended usage periods for algorithms of varying bit-strength
Bits of security Recommended usage period
80 until end 2010
96 until end 2020
112 until end 2030
W 128 as from 2030
The recommendations from Table 1 reflect that it is estimated that there is an overwhelming likelihood that an
algorithm of the indicated bit strength will remain secure (that is, unbroken) until at least the year indicated.
For other categories of algorithms, such as message authentication codes and asymmetric algorithms, the
concept of n bits of security is more difficult to define because of the nature of compromises and the
measurement of the work or cost required to accomplish a compromise. However, for each category of
algorithm, their security is still expressed in terms of bits of security. The intended interpretation is that if an
algorithm is listed as having n bits of security, then it is estimated that it will remain secure until the same year
as a symmetric cipher with n bits of security.
The efforts of breaking ciphers of different categories may have very different “profiles”. One algorithm may
require a large amount of computing power and little storage, while another may use a large amount of
storage and less computing power. One effort may be parallelizable, so that the main limitation is the number
of computers that can be recruited to participate, whereas another may require a single computer with a very
large amount of RAM. Lenstra and Verheul in Reference [52] estimate that the financial costs associated with
breaking an asymmetric cipher are 2 500 times larger than those associated with breaking a symmetric cipher,
if the computational efforts measured in MIPS years are the same. See also Reference [19] for comparisons
of cryptographic strengths of symmetric and asymmetric algorithms.
For algorithms with an estimated security of 128 bits or more, a recommendation of “past 2030” is given,
reflecting the view that any estimate beyond 2030 is so far into the future that it seems unwise to make the
estimate any more precise at this time.
For symmetric algorithms, Grover's algorithm (see Reference [17]) means that if a quantum computer were to
be implemented, key sizes should be roughly doubled to maintain the same level of security. All the
asymmetric algorithms mentioned in this Technical Report are vulnerable to quantum computing algorithms
(see Reference [69]), and hence any leaps in progress in the area of implementing quantum computers could
render the recommendations in Table 1 void. However, the commonly established wisdom is currently that
2 © ISO 2010 – All rights reserved

quantum computing on the scale necessary, say to factor a 1 024-bit RSA modulus, is at least 20 to 25 years
away. On the other hand, if and when quantum computers are realized, it would be expected that increases in
key lengths would be much less a barrier to compromise than now, so that the mentioned asymmetric
algorithms would quickly become obsolete.
3 Algorithm migration
As the state of the art of cryptology progresses and the power of computers increases, cryptographic
algorithms and key lengths that once were secure may no longer be so. For algorithms that have security
parameters, security can be improved by adjusting the security parameters rather than migrating to a new
algorithm. Examples include RSA-based crypto systems where the RSA key length can be increased and
AES where the choice is between key lengths of 128, 192 and 256 bits.
Migration where only the security parameters are changed is mostly less onerous than migration where the
cryptographic algorithm itself changes, and although performance in general would be expected to deteriorate
with a more secure choice of security parameters, improvements in computer performance may make up for
such a deterioration.
However, specific applications, implementations, data formats or indeed performance considerations may
impose limits on the values of certain security parameters such that at some point it becomes impossible,
infeasible or un-economical to maintain adequate security by only adjusting the security parameters.
It must further be assumed that no cryptographic algorithm will continue forever to provide adequate and cost-
efficient security, regardless of the choice of security parameters. Hence it must be assumed that although
increasing the security parameters for an existing algorithm may buy some time, eventually any application of
a cryptographic algorithm will face a migration from that algorithm to a newer one.
Any such migration will be likely to incur both cost and disruption, but it is also an opportunity to take
advantage of cryptographic and technical progress in modernizing the use of cryptographic algorithms, to
what should be a faster, more secure and more cost-effective solution.
Experience gained in migrating from DES to TDEA has highlighted that the financial industry must establish a
long-term and holistic (as opposed to piecemeal) approach to cryptographic algorithms. Lying as they do at
the heart of all data security systems, changes to such algorithms are difficult, sensitive and expensive, and
they take a long time to implement.
Thus, apart from identifying and preparing the financial industry for migration to other algorithms and longer
key lengths with associated changes in key management, there is also a need to ensure that
⎯ the structure of stored and transmitted data is suitable to be processed by generic cryptographic
algorithms, and
⎯ systems are designed to be sufficiently flexible to enable the negotiation of cryptographic algorithms and
associated parameters.
For this reason, in order to create systems that are sufficiently flexible to withstand algorithm migration in the
future, it is important to first start migrating to more flexible data structures and methods for processing such
data structures. A good example of this is the adoption by ISO/TC 68 (e.g. see ISO 16609) of ISO/IEC 10116
in place of ISO 8372.
Because of the complexity of the task and the lifetime of relevant system components, a migration time of
10 to 15 years may well be realistic. Example steps that may need to be completed are:
a) development of flexible data structures;
b) agreement on algorithms and APIs;
c) development of plans to ensure interoperability through migration phase;
d) product development and test;
e) product implementation;
f) phased migration, including stopping the use of old algorithms;
g) protected data lifetime: this is the period after any new use of the old algorithms has ceased, but while
data must still remain protected by the old algorithms.
See Figure 1.
2010 2020 2030
10 year migration (a – f) Data retention time (g)
Start migration Cease use of old Old algorithms need no
algorithms longer be secure
Figure 1 — Example of migration from old to new algorithms
The individual clauses below will highlight any particular migration issues there may be for the algorithms they
discuss.
4 Block ciphers
4.1 General
This clause lists block ciphers that may be used within applicable ISO/TC 68 standards.
A block cipher maps a block of n plaintext bits to a block of n ciphertext bits using a key of k bits. The block
ciphers listed in Table 2 below are defined in ISO/IEC 18033-3.
Table 2 — Block ciphers
Block length Algorithm name Key length
TDEA 128 or 192 bits
64 bits
MISTY1
128 bits
CAST-128
AES
128, 192 or 256 bits
128 bits
Camellia
SEED 128 bits
4.2 Keying options
4.2.1 Keying options for TDEA
Keying option 1, also known as 2-key Triple DES: 128-bit key represented as two 64-bit DEA keys, where for
each DEA key 56 bits can be chosen arbitrarily and the rest can be used for error detection.
4 © ISO 2010 – All rights reserved

Keying option 2, also known as 3-key Triple DES: 192-bit key represented as three 64-bit DEA keys, where for
each DEA key 56 bits can be chosen arbitrarily and the rest can be used for error detection.
4.2.2 Keying options for AES
Keying option 1: 128-bit, where all 128 bits can be chosen arbitrarily.
Keying option 2: 192-bit, where all 192 bits can be chosen arbitrarily.
Keying option 3: 256-bit, where all 256 bits can be chosen arbitrarily.
4.2.3 Keying options for Camellia
Keying option 1: 128-bit, where all 128 bits can be chosen arbitrarily.
Keying option 2: 192-bit, where all 192 bits can be chosen arbitrarily.
Keying option 3: 256-bit, where all 256 bits can be chosen arbitrarily.
4.3 Recommended block ciphers
Table 3 contains a list of recommended block ciphers and their current estimated security in bits. The
recommendations are based on the analyses and recommendations provided in the ECRYPT yearly report on
algorithms and key sizes (see References [13] and NIST SP 800-57).
Table 3 — Security of block ciphers
Algorithm Keying option Key length Security in bits
TDEA 1 128 bits 80 – 112
2 192 bits 112
AES 1 128 bits 128
2 192 bits 192
3 256 bits 256
Note that:
min (112, 120-t) t
⎯ 2-key Triple DES (TDEA with keying option 1) has effective strength 2 where 2 is the
number of plaintext ciphertext pairs available to an attacker.
⎯ 3-key Triple DES (TDEA with keying option 2) has effective strength exceeding 2 . Typically, its
strength is cited as 2 , but in general its strength is best expressed as in Reference [55], Note 7.38, as
57−s
a trade-off between memory and computation, where a “meet-in-the-middle” attack requires 2 space
112+s
and 2 time, for 1 u s u 56.
The recommended end date for use of 2-key Triple DES (TDEA with keying option 1) ranges from 2010 to
2030. Which date is appropriate for a given implementation depends on the way in which the keys are being
used in that implementation. If the key usage provides a potential attacker with a large number of plaintext-

ciphertext pairs for the same key (e.g. 1 000 000 000 000 ≈ 2 pairs), the security of the key is approximately
80 bits and hence the recommended use is until 2010. If only a few (fewer than 256) pairs are available, it
may be acceptable to continue use until 2030.
Interpolating, by way of example, if an estimated maximum of 16 million plaintext-ciphertext pairs might
become available to an attacker, the estimated security of the key would be approximately 96 bits (since
2 ≈ 16 million), and the recommended use would be until 2020. Hence, proper use of session keys will
greatly extend the usable life of a 2-key Triple DES (TDEA with keying option 1) implementation, as will
frequent change of keys. If it is not possible to estimate a limit on the number of plaintext-ciphertext pairs that
may become available to an attacker, then the most conservative recommendation (to stop use by 2010)
applies.
Notice also that in the absence of session keys, 64-bit MACs may provide an attacker with plaintext-ciphertext
pairs (in particular for messages less than 8 bytes) and thus aid in reducing the security of the key used.
For example, consider PIN entry devices that use a fixed key versus those that use unique keys per
transaction, such as DUKPT (Derived Unique Key Per Transaction, as specified in ANSI X9.24-1). Fixed-key
devices could provide an attacker with a large number of plaintext-ciphertext pairs (one pair for each
encryption), weakening the strength of the key, whereas devices that use a unique key per transaction provide
at most one plaintext-ciphertext pair for each session key. Particular implementations or formats may also limit
the availability of plaintexts to attackers (e.g. by including randomness in the encrypted values, such as in PIN
block format 3), thereby protecting the strength of the encipherment key.
The other symmetric algorithms from Table 2 (MISTY1, CAST-128, Camellia and SEED) should only be used
when legacy applications require it. In this case, the maximum strength of the algorithm would be expected to
be similar to that of AES with the same keying option, and hence the recommendations from Table 3 can be
carried over for those key lengths. Consideration should however be given to the fact that these algorithms
have received significantly less scrutiny in the cryptographic community than TDEA and AES. Note that there
are recent research papers which propose theoretical related-key attacks against AES using keying options
2 and 3 (192-bit and 256-bit keys respectively). See Reference [75].
When evaluating the suitability of a particular block cipher for a given implementation, it is important to take
into account the length of time it is necessary to protect the data that the block cipher is used to encrypt. For
example, if a 3-key Triple DES (TDEA with keying option 2) implementation is used to encrypt data which
needs to be protected for 10 years after it is encrypted, then encipherment of new data should stop in 2020
[because in terms of years, 2020 + 10 = 2030, the last year where 3-key Triple DES (TDEA with keying
option 2) is recommended].
4.4 Block size and key use
Besides key length, block size is an important security parameter, e.g. the French government IT Security
Agency recommends against using 64-bit block ciphers for encryption or MAC-ing. The concern with small
block size is mainly that text dictionary attacks and matching ciphertext attacks become feasible, as outlined in
Reference [55], Note 7.8. A text dictionary attack builds a dictionary of known plaintext-ciphertext pairs (each
1 block), and a complete dictionary for a 64-bit block cipher can thus be built if 2 plaintext-ciphertext pairs
are available. Matching ciphertext attacks exploit that the birthday paradox implies that once the number of
n/2
available ciphertexts for an n-bit block cipher reaches 2, which for a 64-bit block cipher is approximately
4 290 000 000, one expects to find matching ciphertext blocks, which may reveal partial information about the
n/2
plaintexts. For this reason it is recommended not to use the same key for more than 2 times for an n-bit
block cipher.
The use of session keys greatly reduces the risks of small block size.
4.5 Modes of operation
The modes of operation for block ciphers should follow ISO/IEC 10116. For TDEA, see also ISO/TR 19038.
As stated in ISO/IEC 10116:2006, B.1.2, one property of the Electronic Code Book (ECB) mode is as follows:
“(.) the same plaintext block always produces the same ciphertext block (for the same key) making it
vulnerable to a “dictionary attack”, where a dictionary is built up with corresponding plaintext and
ciphertext blocks. The ECB mode is, in general, not recommended for messages longer than one block.
The use of ECB may only be specified in future International Standards for those special purposes where
the repetition characteristic is acceptable, blocks have to be accessed individually, or blocks have to be
accessed randomly”.
6 © ISO 2010 – All rights reserved

Hence, for plaintexts longer than the block size of the block cipher, Cipher Block Chaining (CBC), Cipher
Feedback (CFB), Output Feedback (OFB) or Counter (CTR) mode are recommended. Which mode of
operation to choose depends on the specific requirements of the application (such as ability of parallelizing
encryption/decryption, error propagation, or requirements to initialization values). Please refer to
ISO/IEC 10116:2006, Annex B, for properties of the modes of operation.
4.6 Enciphering small plaintexts
When enciphering small plaintexts such as customer PINs, special considerations apply when estimating the
security of a particular mechanism. For example, if the entire plaintext to be enciphered is an 8 byte PIN block
and no random data is added, dictionary attacks may be possible regardless of the size of the key used for
encipherment. In this case, it is important to follow established standards, such as ISO 9564-2 for PIN
encipherment, where the formats specified have been developed with these concerns in mind.
4.7 Migrating from TDEA to AES
In light of the experience of migrating from DES to TDEA in particular, any migration from TDEA to a
1)
replacement symmetric algorithm should be planned well in advance in order to reduce unnecessary costs.
Aside from the inherent challenges of migrating from one symmetric encipherment algorithm to another across
the financial services industry, one important difference between TDEA and AES is the block length of each.
TDEA is a 64-bit block cipher, whereas AES is a 128-bit block cipher. A consequence of this is that today,
many of the data structures used for storage and transmission are 8-byte oriented, prime examples of this
being TDEA keys themselves, and PIN blocks. Today, many payment networks would not be able to handle
the 128-bit blocks that an AES-based PIN block would use. Migration would have to be staged and hence
involve parts of the payment networks using TDEA and other parts using AES, which would lead to a
temporary but long lasting requirement for translations both from TDEA encrypted messages to AES
encrypted messages, and vice versa.
AES also supports longer key lengths than TDEA, and as a consequence a migration from TDEA to AES may
have significant key management impact as well. New AES-based systems should be built flexibly, so that
they can eventually employ all the available key lengths for AES (keying options 1, 2, and 3).
5 Stream ciphers
A stream cipher maps bits of plaintext to bits of ciphertext using a key of k bits. It does so by using the k-bit
key to generate a key stream of the same length as the plaintext. The key stream is used (like a one-time pad)
to encipher the plaintext, bit by bit (using the xor operation). Stream ciphers may be dedicated stream ciphers
or based on modes of operations of block ciphers. For modes of operations of block ciphers, see
ISO/IEC 10116. Stream ciphers are standardized in ISO/IEC 18033-4, including the dedicated stream ciphers
MUGI and SNOW, and the stream ciphers CTR, OFB, and CFB, which are based on block ciphers. ISO/TC 68
recommends use of CTR, OFB or CFB, because these schemes are based on well-known modes of
operations with block ciphers, whereas both MUGI and SNOW are of relatively recent design (2002).
6 Hash functions
6.1 Hash functions and their properties
For the purposes of this Technical Report, the terms “hash algorithm” and “hash function” are considered
equivalent. A hash function maps plaintext of an arbitrary length into an h-bit hash result, processing the input
in blocks of m bits. Hash functions are taken from ISO/IEC 10118-2 (hash functions based on block ciphers),
ISO/IEC 10118-3 (dedicated hash functions) and ISO/IEC 10118-4 (hash functions using modular arithmetic).
Applications rely on different properties of hash functions, such as:

1) Note that similar planning will be needed for the future migration from SHA-1 to its approved successor(s).
a) pre-image resistance — the property that given an h-bit bit-string H, it is infeasible to find a plaintext value
the hash of which is H;
b) second pre-image resistance — the property that, given a plaintext A, it is infeasible to find a different
plaintext B such that the hash of A is identical to the hash of B;
c) collision resistance — the property that it is infeasible to find any two different plaintexts A and B such
that the hash of A is identical to the hash of B.
6.2 Hash functions based on block ciphers
The following is a list of hash functions based on a block cipher with block size n (see ISO/IEC 10118-2):
a) Hash algorithm 1 — size of hash result less than or equal to n;
b) Hash algorithm 2 — size of hash result less than or equal to 2n;
c) Hash algorithm 3 — size of hash result equal to 2n;
d) Hash algorithm 4 — size of hash result equal to 3n.
The security of hash functions based on block ciphers depends on the security of the underlying block cipher
and on the size of the hash result. If there are no known algorithmic vulnerabilities (such as, presently, for
AES), the security in bits of a hash function
⎯ based on a block cipher with m bits of security and
⎯ with size of hash result equal to h bits
⎧⎫h
is expected to be min ,m .
⎨⎬
⎩⎭
ISO/IEC 10118-2 mentions specifically using DEA (“single DES”; see ANSI X3.92 and ISO/IEC 18033-3:2005,
Annex A) as the underlying block cipher, and provides examples for how to construct hash algorithms 1 to 4
with the size of hash result equal to 64, 128, 128 and 192 bits. If it is necessary to use a hash function based
on a block cipher, AES should be used as the underlying block cipher. Otherwise, using a dedicated hash
function is recommended.
6.3 Dedicated hash functions
Table 4 lists dedicated hash functions, together with their estimated security strength in bits. Their
recommended last usage dates can then be inferred from Table 1, depending on whether collision resistance,
pre-image resistance, or second pre-image resistance is required. If it is not clear if collision resistance is
required or not, it must be assumed that it is required, and hence the more conservative estimate should be
used for usage dates.
8 © ISO 2010 – All rights reserved

Table 4 — Dedicated hash functions and their security
Hash function Block length Hash result Collision resistance Pre-image Second pre-image
m in bits length h strength in bits resistance strength resistance strength
in bits in bits in bits
RIPEMD-160 512 160 80 160 105-160
RIPEMD-128 512 128 <60 128 73-128
SHA-1 512 160 63* 160 105-160
SHA-224 512 224 112 224 201-224
SHA-256 512 256 128 256 201-256
SHA-512 1024 512 256 512 394-512
SHA-384 1024 384 192 384 384
WHIRLPOOL 512 512 256 512 265-512
NOTE Recent progress in the research on finding hash function collisions has resulted in the estimated collision resistance
security of SHA-1 decreasing from 80 bits to 63 or 69 bits during the period from 2004 to 2006 (see Reference [73]). For this reason,
NIST has published the following recommendation regarding the SHA family of hash functions on their website:
“March 15, 2006: The SHA-2 family of hash functions (i.e. SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal
agencies for all applications using secure hash algorithms. Federal agencies should stop using SHA-1 for digital signatures, digital time
stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions
for these applications after 2010. After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message
authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST
encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols.”
Even more recent work suggests that the collision resistance of SHA-1 may be as low as 52 bits.

NIST has initiated a competition to identify alternatives to the SHA family of hash functions. The competition is
scheduled to run from 2007 to the end of 2011, ending with an announcement of the alternative hash
function(s) at the end of 2011. It is then anticipated that the augmented and revised Hash Function Standard
will be published by 2012. Assuming that the NIST competition and subsequent standard end up nominating a
hash algorithm which is not among the SHA family of hash algorithms, then the recommendations in this
Technical Report would change accordingly.
Whether a particular hash function is fit for a particular application depends on which properties of the hash
function the application relies. As the three columns for security strength in Table 4 show, pre-image and
second pre-image resistance are much easier to achieve than collision resistance. Hence, if an application
uses a hash function and relies only on the pre-image resistance of the hash function, it can continue to use
that hash function longer than if it relies also on the collision resistance of the hash function.
For a practical example, collisions have been found for several hash functions (such as MD4 and MD5),
where it still seems infeasible for the moment to find second pre-images in general (for the best results so far
on finding second pre-images for MD4, see Reference [74]).
For all hash functions except SHA-384, second pre-image resistance strength varies according to the size of
the input string, with the strength decreasing with increasing input length (see Reference [49]). The range
indicated in Table 4 above is calculated using the formula given in the appendix of NIST SP 800-107, and
using the definitions of maximum input length specified in ISO/IEC 10118-3. The minimum strength indicated
in the column for second pre-image resistance strength in bits corresponds to the maximum input length
allowed by ISO/IEC 10118-3, and the maximum strength corresponds to input strings of length at most the
same as the block length of the hash function.
Whether an application relies on collision resistance or only on pre-image or second pre-image resistance
may well require expert input. If it cannot be determined whether collision resistance is required or not, it
should be assumed that it is required.
For applications that currently use SHA-1 and rely on collision resistance, migration to another algorithm
would have to take place before 2010 in order to comply with the recommendations in Table 4, which
coincides with the recommendations regarding use of SHA-1 given in NIST SP 800-57.
6.4 Hash functions using modular arithmetic
ISO/IEC 10118-4 defines two hash functions, MASH-1 and MASH-2, that are based on modular arithmetic,
and where their basic properties such as pre-image and collision resistance depend on the difficulty of
factoring a product of two large primes. Neither MASH-1 nor MASH-2 has seen any significant practical
deployment and for this reason they are not recommended.
6.5 Migrating from one hash function to another
The industry has already seen a sizable migration from MD-5 and other obsolete hash algorithms to mainly
SHA-1, but also to some extent to SHA-256. With the gradual demise of SHA-1 and with the NIST competition
to find an alternative by 2012 we can expect a migration to the new hash algorithm starting even before 2012,
but lasting many years.
If migrating to a hash algorithm with a larger hash result, the migration will likely result in a change of data
formats and will, as such, require larger changes than just switching one hash algorithm for another with the
same size of hash result. In order to facilitate more flexibility in the future, data formats should, therefore, be
designed with the consideration in mind that not only might the hash algorithm change, but so may the size of
the hash result.
For many financial applications, a migration away from SHA-1 before 2010 is not feasible for financial and
logistical reasons having to do with a large installed base of equipment with a long shelf life (e.g. Point-of-Sale
devices). In addition, a quick migration may not be necessary, as outlined above.
As a worst case, if a migration prior to 2010 is not feasible, but on the other hand a compromise will result in
significant financial loss or loss in reputation, and collision resistance is indeed required, a migration away
from SHA-1 to one of the recommended hash algorithms from Table 4 should be planned, and mitigating
security measures (such as procedural controls) should be introduced to compensate for the risk in the period
from 2010 until a migration has been completed, and no further reliance is placed on the value of SHA-1 hash
results. If satisfactory mitigating controls can be maintained until a migration to the new NIST recommended
hash algorithm can be completed, this may be preferable.
If collision resistance is not required, SHA-1 can be used well beyond 2010, and a migration can therefore
take place after NIST has nominated an alternative. In this case, migration should take place as soon as
practical, after the new hash algorithm has been identified. It should be noted that
...