Cryptography Reference
In-Depth Information
not be finding themselves in the headlines every half year. Whether the answer
already exists in SHA-224, SHA-256, SHA-384, or SHA-512 (see [F180]) needs to
be investigated. An increase in the block length may not suffice to compensate
for possible weaknesses in the functional building blocks of a hash algorithm.
It is always possible that methods of attack will be developed whose effect is
independent of the block length, as has been discussed in relation to the hash
algorithms that we have mentioned.
How one finds suitable algorithms has been demonstrated by the European
Union in the development of RIPEMD in connection with the RIPE project, 12
and in the USA with the competition for the development of the AES. Within
the framework of a public international competition, new candidates for hash
algorithms with the greatest possible transparency can be put to the test and the
most suitable algorithms adopted. The only disadvantage of such a process is that
it costs time: In the case of AES it was about three years from the announcement
of the competition until a victor was crowned, and four years altogether before
the standard was published in 2001. Given this experience, until 2010 is enough
time for the development and standardization of new hash functions, although
the migration to a new algorithm (or, better, two or three of them) will take time.
Whether in specific applications a switch to other transitional algorithms
might be necessary, and what consequences might be thereby associated, can be
evaluated only on a case by case basis.
We shall not go into further detail on this topic, which is very important to
cryptography. The interested reader is referred to [Pren] or [MOV], Chapter 9,
as well as the literature cited therein, above all literature on the current state of
affairs. Algorithms for transforming texts or hash values into natural numbers can
be found in [IEEE], Chapter 12: “Encoding Methods” (we already have available
the corresponding functions clint2byte_l() and byte2clint_l() ; cf. page 152).
Implementations of RIPEMD-160, SHA-1, and SHA-256 can be found in ripemd.c ,
sha1.c ,and sha256.c in the downloadable source code.
In thinking about the signature protocol described above we are immediately
confronted with the following question: How can B know whether he is in
possession of the authentic public key of A ? Without such certainty B cannot
trust the signature, even if it can be verified as described above. This becomes
critical when A and B do not know each other personally or when there has been
no personal exchange of public keys, which is the normal case in communication
over the Internet.
To make it possible for B nonetheless to trust in the authenticity of A 's
digital signature, A can present her communication partner a certificate from a
certification authority that attests to the authenticity of A 's public key. An informal
12
RIPEMD has been further developed to RIPEMD160 [DoBP]. Although RIPEMD160 has
meanwhile been rejected in favor of SHA-1, this algorithm in its current state remains
unbroken.
 
Search WWH ::




Custom Search