19.12.2012 Views

IT Baseline Protection Manual - The Information Warfare Site

IT Baseline Protection Manual - The Information Warfare Site

IT Baseline Protection Manual - The Information Warfare Site

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Threats Catalogue Deliberate Acts Remarks<br />

____________________________________________________________________ .........................................<br />

T 4.35 Insecure cryptographic algorithms<br />

<strong>The</strong> extent to which cryptographic processes increase security basically<br />

depends on two parameters: secure cryptographic algorithms must be used and<br />

the secret codes must be treated confidentially (for the compromising of<br />

cryptographic codes see G 5.83).<br />

Insecure cryptographic algorithms are characterised by the fact that a potential<br />

perpetrator with justifiable resources is able to discover how the cryptographic<br />

process works. In the case of encoding algorithms, this means that it is<br />

possible to ascertain the original plain text from the encoded text without any<br />

additional information. Here, you must take into account that relevant<br />

resources for the perpetrator include available performance, aids such as<br />

analysis tools, prior knowledge, time available, knowledge concerning<br />

weaknesses, etc. <strong>The</strong>refore, if you use insecure cryptographic algorithms,<br />

perpetrators may be able to get round the cryptographic protection.<br />

However, you need to examine each case separately in order to determine<br />

whether a cryptographic algorithm is insecure. Nevertheless, there are several<br />

criteria which indicate insecurities:<br />

- If secret codes with actual lengths of less than 60 bits are used in<br />

symmetric cryptographic techniques, then they can be cracked using a huge<br />

number of computers to try out every possible code. With the increasing<br />

performance of computers, it is to be expected that this limit will increase<br />

to 80 bits in the future.<br />

- If algorithms whose security is based on the problem of factorising large<br />

numbers are used in asymmetric cryptographic techniques and signature<br />

procedures, it is now thought that code lengths of less than 768 bits should<br />

be considered insecure. This is founded on the progress in the development<br />

of efficient factorisation algorithms which currently make it possible to<br />

factorise numbers with approximately 500 bits using huge numbers of<br />

computers. At the same time, it must be taken into account that optoelectronic<br />

accelerators may be developed to perform a considerable<br />

proportion of the calculations in these processes, which would speed things<br />

up considerably.<br />

- Hash functions which convert character strings of any length into a hash<br />

value with a constant bit length can be considered insecure if the constant<br />

length of the hash value is less than 128 bits, as it would otherwise be<br />

possible to calculate two character strings which produce the same hash<br />

value.<br />

- Cryptographic algorithms developed by inexperienced developers that have<br />

not been investigated scientifically should be considered potentially<br />

insecure, as many years of experience are needed to develop secure<br />

cryptographic algorithms.<br />

- Unpublished cryptographic algorithms which run remarkably quickly in<br />

software should also be considered potentially insecure. Experience shows<br />

that secure algorithms are usually based on complex mathematical<br />

functions.<br />

____________________________________________________________________ .........................................<br />

<strong>IT</strong>-<strong>Baseline</strong> <strong>Protection</strong> <strong>Manual</strong>: Oktober 2000

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!