On cryptosystems untrustworthiness
centre, St. Petersburg Technical University
The reasons of cryptosystems
untrustworthiness can be divided into 4 main groups: application of weak
algorithms, cryptalgorithms wrong implementation or application and human
factor. There is clear parallel between these reasons and computer system
security violation ones.
Because of pointed reasons
there were and still there are security problems in all kinds of software,
where cryptalgorithms are used, be it operating systems; cryptographic
protocols; clients and servers supporting them; office programs; user encryption
utilities or popular archivers.
To proper implement your
own cryptosystem you should not only learn somebody's mistakes and understand
the reasons of their occurrence, but perhaps use sophisticated protection
programming approaches and special design tools.
Cryptalgorithms are widely used in
modern software not only for data encryption but also for authentication
and integrity. To date there exist well-known and approved cryptalgorithms
(both symmetric and asymmetric), whose strength is either mathematically
proved or based on mathematically hard computational problem (factorization,
discrete logarithm, etc.). The most famous ones are DES,
These algorithms can be breaked only by solving this problem or by
On the other hand, information on errors
and flaws in one or other program or on cracking some programs (including
those using cryptalgorithms) appears in computer world and about all the
time. It causes distrust to both specific programs and ability to protect
anything with cryptography in general, not only against secret services,
but also against hackers.
Thus, when designing secure systems
it is necessary to learn history of attacks and flaws in cryptosystems
and to understand the reasons of their occurrence. The promising research
branch in this field is the analysis of successful attacks or detected
cryptosystem vulnerabilities in order to generalize, classify and detect
the reasons and regularity of their appearance and existence. This is the
item of this paper.
By analogy with computer systems security
violation reasons taxonomy , let us pick out the reasons
for which cryptographic programs cannot be considered secure (see figure
- Impossibility of strong
- Cryptalgorithm implementation
- Cryptalgorithm wrong
- Human factor.
Note that reasons in concern cover
only two potential threats, namely confidentiality and integrity
ones, leaving aside denial of service, which becomes more and more
significant with the development of distributed cryptosystems.
Figure 1. Cryptosystems
of applying strong cryptalgorithms
This kind of reasons is the most prevalent
because of following factors.
Low rate of strong cryptalgorithms
It is one of the main factors hampering
good algorithms usage in total ciphering or "on-the-fly" ciphering
systems. In particular, while Norton DiskReet program is DES-implemented,
it may not encrypt all the disk when the user changes his key, as it will
take too much time. Just so, there is the option of compressed data password
protection in Stac Electronics'
Stacker on fly compression program. But it is physically unable
to encipher its own file (usually of hundreds megabytes) with this password,
that's why it contents with very weak algorithm and keeps hash-function
of password along with data being protected. Cryptographic strength1
of this function was examined and appeared to be 28, i.e. a
be breaked trivially.
This reason is connected with cryptalgorithm
export or with necessity of getting patent or rights. In particular, U.S.
is limited to 40-bit key length2. Such strength
evidently cannot be secure because of modern computer power. Even for personal
computer, setting exhaustive search rate to 50000 passwords per second,
we get exhaustive search time of about 4 months at average.
Among known export restricted software
last versions of Internet browsers, Netscape
Communications' Netscape Navigator and Microsoft's
Internet Explorer, can be mentioned. They represent encryption with
128-bit key for U.S. users and with 40-bit key for the rest. The last version
of ARJ 2.60 archiver, known for
its weak archive enciphering algorithm, also can be referred to this group.
Today U.S. users can use cryptographically strong GOST. The funny side
of situation is that while algorithm is Russian, due to U.S. law even Russians
still cannot use it in ARJ program.
Own cryptalgorithms usage
Paradoxical situation, when developers
ignore known algorithms, often occurs, especially with freeware and shareware,
in archivers or file encryption tools, for instance.
As we have already mentioned, ARJ archiver
(up to version 2.60 inclusive) uses very weak encryption algorithm, simple
XOR with password. It may seem that it could be used, because archived
text must not absolutely be redundant and statistical cryptanalysis methods
would not do here. But after detailed consideration it appeared that archived
text possesses some nonrandom information (and it holds for any archiver),
for example, Huffman table and other housekeeping information. That's why,
if one knows exactly or can predict with certain probability the values
of these housekeeping variables, he can also determine corresponding password
characters with the same probability.
Further usage of such a weak algorithm
leads to successful plaintext attack: if an adversary knows at least
one file from encrypted archive he could easily
determine archive password and extract all the rest files (for given
plaintext, ARJ strength is 20 !). Even if all the files are
encrypted, simple XOR allows
to get exhaustive search rate of 350000 password per second on Pentium.
The same we have in the case of popular
programs from Microsoft Office
95, where to determine
a password one must know only 16 plain bytes of .doc or .xls file which
are to be present there, whereupon it is sufficient to look through only
24 variants. Microsoft Office 97 contains improved encryption
algorithms, allowing exhaustive search only, but... not everywhere! MS
Access 97 uses absolutely primitive algorithm, while XOR-encrypting
with fixed constant not data but password!
Netware network operating
system (3.x and 4.x versions) also uses its own
hash algorithm. Hash-function has 32-byte value, derived from user
original password by truncation a password with the length of more than
32 characters with XOR operation or by replication a password with the
length of less than 32 characters, in the input and 16-byte hash-value
(Hash16) in the output. It is this value (for Novell Netware 3.x)
to be stored in bindery data base as "PASSWORD" property.
One of the main features of cryptographically
strong hash-function is that it should not allow easy collisions (such
as crypt() function, used in UNIX and based on mathematically
strong cryptalgorithm DES). It is this feature that is violated in Novell
Netware's hash function.
was built, which for given hash-value after some search (about few seconds
on 80386+ computer) generates 32-byte sequence, which is not, of course,
a true password, but is perceived by Novell Netware as such, since being
processed by hash algorithm it has exactly available hash value in the
The same hash algorithm remained also
in Novell Netware 4 version.
Microsoft, in turn, also has significant
shortcomings in its main hash algorithm, applied for local (NetBIOS protocol)
and global (CIFS and http protocols) networks authentication in all of
its operating systems since Windows 3.11, so called LM-hash (Lan Manager-hash)
. (However, Microsoft pleads that it remained since
OS/2 and was designed by IBM).
It runs as follows:
- Password is converted into 14-character
string by truncating longer passwords or by complementing shorter passwords
- All the lowercase characters are changed
into uppercase ones. Numeric and special characters are stayed unchanged.
- 14-byte string is divided into two
- Fixed constant is encrypted on each
of these halves as on DES-key, resulting in two 8-byte strings.
- These strings are merged to form 16-bit
It is obvious that attacks against
LM-hash are easily crowned with success due to the following:
- Converting all the characters into
the uppercase further restricts a few number of possible combinations (26+10+32=68)
for each one.
- Two 7-byte "halves" are encrypted
independently, i.e. two "halves" may be chosen by exhaustive search independently;
and passwords of length more than 7 characters are not stronger than 7-character
length passwords. Thus, to guarantee password disclosure we must look through
only (680+681+...+687) >
instead of 940+941+... 9414 >
(i.e. nearly 1015 times less) combinations. Moreover,
passwords with the length of less than or equal 7 characters are easy to
recognize, because the second half of hash is the same value AAD3B435B51404EE,
resulting from fixed constant encryption on the seven-zero key.
- There is no salt, as in crypt(),
so two users with the same password will always get the same hash-value.
So we may compile a dictionary of hashed passwords beforehand and search
the unknown password in it.
Although cryptographically strong or
certified algorithms are used in this case, this group of reasons leads
to cryptosystem security violation because of algorithms wrong implementation.
Decrease of cryptographic strength
while key generation
This reason has various examples, when
cryptosystem truncates user password or generates data from it of the bit
length less than a password one is. For example:
- A lot of (old) UNIX versions truncate
user password up to 8 byte before hashing. It's interesting, that Linux
2.0, for example, while keeping users to enter alphanumerical passwords,
does not test if 8-character password beginning is also alphanumerical.
That is why the user, having set the highly safe passwordIsgood19
password, will be surprised at hacker logging in on his behalf with a trivial
- Novell Netware allows user passwords
up to 128 byte, i.e. 68128 >
2779 combinations (including case-insensitive Latin alphabetic,
numeric and special characters). But here hash-function (vide
supra) has only 32-byte value in the input, limiting effective password
length to the same value. Moreover, hash output has only 128 bit length,
i.e. 2128 combinations. It causes further decrease of effective
length to =21 characters3,
i.e. 6 times as against original.
- Entirely the same situation is with
RAR-archiver of 1.5x version, where
password of 10 characters length does not increase time for its disclosure.
While the upper bound of password length
is formed by cryptalgorithms use, the lower limitation is connected with
bit or entropy notation. In case with Novell Netware to get hash-value
with 128-bit entropy one must use a password of at least =69
bit4 length or at least 22 characters5.
Unlimiting minimal password length in a lot of cryptosystems results in
successful exhaustive search when searching not for keys but for passwords.
Lack of weak key testing
Some cryptalgorithms (in particular,
DES, IDEA), when ciphering on specific keys, cannot guarantee proper cryptographic
strength level. Such keys are called weak. It is known 4 weak and
12 semi-weak keys for DES. And while the probability of meeting them is
we should not neglect it in serious cryptographic systems.
The cardinality of weak keys set for
IDEA is neither more nor less than 251 (however, since there
are 2128 keys on the whole, the probability of meeting them
107 less than in DES).
Insufficient protection against
Malicious software includes computer
viruses, Trojan horses and other software, able to eavesdrop secret key
or plaintext and to substitute strong algorithm for weak one. If the programmer
does not provide for sufficient protection against malicious software,
it can violate cryptosystem security. It is mostly topical for operating
systems without built-in security or access control services, such as MS
DOS or Windows 95:
- Password eavesdropping. Let
us recall the oldest way of password eavesdropping, known since mainframe,
when the "phantom" program emulates operating system prompt, suggesting
a user to enter his name and password, stores it in certain file and terminates
with the message "Invalid password". In MS DOS and Windows there
exists a lot of logic bombs
for reading and storing keyed-in passwords (by eavesdropping suitable
interrupt), for example, when DiskReet v. 6.0 utility is running.
- Cryptalgorithm substitution.
As an example we may consider a logic bomb, posed
as accelerator application, Turbo Krypton, for instance. This
logic bomb substitutes GOST 28147-89
encryption algorithm, implemented by "Krypton-3" board (demo version),
for another simple and easy decryptable algorithm .
- E-mail Trojan horse. The last
example is the attempt of "Trojan horse" to percolate through electronic
mail, occurred in June 1998. The letter contained a pornographic picture
and FREECD.EXE file, which decrypted provider connection passwords (Dial-Up)
and sent them to firstname.lastname@example.org, while user was amusing himself by the letter.
Dependence on time of key processing
This is relatively new aspect of cryptalgorithms
incorrect implementation, called "Timing attacks" and discussed
in , where it is shown that a lot of cryptosystems
process different inputs for different time interval. The reasons for this
are both hardware (different number of cycles per operation, hitting into
processor cash, etc.) and software (especially while time optimization
of the program). Time interval may depend on both encryption key and encrypted
Hence, an adversary, possessing detailed
information on cryptalgorithm implementation or encrypted data and being
able to measure the time of data processing somehow (for example, by analysis
of data packet sending time), can try to fit a secret key. This paper 
describes in detail attacks against RSA, Diffie-Hellman
and DSS implementing
systems, while the key can be obtained by elaboration bit by bit, a number
of necessary time measuring is proportionate to key length.
While these research has not been brought
to specific result (to compute a secret key), considered example demonstrates
that crucial systems (including cryptosystems) programming is to be extremely
careful and perhaps require special secure programming approaches and special
design tools (especially compilers).
Software implementation errors
It is clear that this factor will always
be present until programs are written by human beings. Novell Netware 3.12
operating system can serve a good example, where in spite of highly considered
authentication system, in which, as Novell says, "unencrypted password
is never transmitted", a bug in SYSCON program v. 3.76 was detected, due
to which just plain password finds itself in one of network packets. This
is not the case in neither earlier nor later versions of this program,
so we may call it pure programmer's error. This error can be revealed only
if supervisor changes one's password (including himself). Apparently, keyboard
buffer gets somehow into network packet.
Trapdoors occur in cryptosystems for
obvious reasons: the designer wishes to control information, being processed
in his system, and reserves the right to decrypt it without user key. Perhaps,
they are used for debugging too and are left in finished products for certain
reasons. Naturally it becomes known to sufficiently wide circle of persons
sooner or later and the value of such cryptosystem becomes next to nothing.
The most wide-known ones are AWARD BIOS (up to 4.51PG version) with its
universal "AWARD_SW" password and Paradox
database management system from Borland International, also including
"superpasswords" "jIGGAe" and "nx66ppx".
In real earnest of implementation trapdoors
(in this case they evidently use explicitly weak algorithms or store a
key along with data) are those algorithms, which allow a third party to
read encrypted message, as in caused a sensation CLIPPER
project, where the state, known for snooping its citizens' secrets,
had played a role of a third party.
Random number generator (RNG) shortcomings
Strong, mathematically tested and correctly
implemented RNG is of great importance for cryptosystem as well as mathematically
strong and correct cryptalgorithm, otherwise its shortcomings may influence
overall cryptographic strength of the system. Moreover, pseudorandom number
generator (PRNG) is generally used for RNG computer modeling, characterized
by period, dispersion and seed. PRNG application can be scarcely called
a happy choice for cryptosystems, so strong cryptosystems use physical
RNG (special board) for these purposes, or at least generate a number for
PRNG initialization, with the use of physical values (time of user's keystroke,
Short period and bad dispersion
are among mathematical shortcomings of RNG and appear when you take your
own RNG for some reasons. In other words, it is dangerous to use your own
RNG, as well as your own cryptalgorithm.
In a case of short period (when a number
of pseudorandom values, produced by generator, is less than a number of
possible key values) an adversary can cut down time overhead for key searching,
by looking through not keys, but pseudorandom values and generating keys
from these values.
Given generator with a bad dispersion,
an adversary can also cut down average search overhead, if he looks through
the most likely pseudorandom numbers.
The most common error, even for tested
PRNG, is its wrong initialization. Here initialization number either
has less information bits than generator itself or is being chosen from
nonrandom numbers and can be predicted with one or other probability.
situation occurred with Netscape Navigator of version 1.1. It initiated
PRNG with current time in seconds (sec) and microseconds (usec)
and process identificators (pid and ppid). The researches
have cleared up that such scenario gives 47 significant bits of information
at most (note, that this generator was used for getting 40- or 128(!)-bit
keys). But when adversary
- was able to intercept network transferred
- had an account at the computer with
he could easily learn sec, pid
and ppid with high probability. When the second condition was not
met, an adversary could try to set time with network demon time;
pid could be obtained through SMTP demon (generally it was located
in Message-ID field). Furthermore, ppid was either a few different
from pid, or just equal to 1.
program was written, which found 40-bit secret key in a minute
at average, searching for microseconds.
Because of this group of reasons cryptographically
strong and correctly implemented algorithms appear to be untrustworthy.
This is the most obvious reason. The
question arises: why strong cryptalgorithms may use short keys? Perhaps,
because of following:
- some algorithms can work with variable-length
key, providing different cryptographic strength; it is the designer to
choose necessary length for desirable strength and efficiency. Sometimes
this desire is limited by other circumstances, such as export restrictions.
(An example here is Norton Secret Stuff program that can be
breaked in a few
days because of 32-bit Blowfish key use).
- some algorithms were developed long
ago, when their key length was thought more than sufficient for required
RSA algorithm, breaking of which is
equivalent to factorization
problem solving, was the first to meet with a great advance of computer
power. In March 1994 8-months factoring of a 129-digit (428-bit6)
number was completed. 600 volunteers and 1600 machines, communicated via
electronic mail, carried out the computation. The calculation was the equivalent
of 5000 MIPS-years7.
The progress in factorization problem
solving is conditioned greatly not only by computer power growth but also
by recent new efficient algorithms. (Factoring the next 130-digit number
took only 500 MIPS-years). Today 512-bit numbers factorization is realistic.
Since numbers of such a kind have been used in PGP
just not long ago, we may assert that it is the most highly developed branch
of cryptography and number theory.
On January 29, 1997, RSA
Labs announced a competition
for breaking RC5
symmetric algorithm. 40-bit key was
cracked 3.5 hours later! (It didn't even need to computers Internet
communication; Berkley University local network of 250 machines was sufficient).
48-bit key was cracked in 313
hours. Thus, it became obvious that the key length, which meets export
restrictions, cannot provide even minimum safety.
Simultaneously with RC5 breaking, 56-bit
key DES, a pillar of American cryptography, was challenged. It capitulated
on July 17, 1997, in 140 days after competition had begun (it took about
450 MIPS-years to test about 25% of possible keys). Without no doubt, it
was outstanding achievement, meant that DES' days as encryption standard
were numbered. Indeed, when in the beginning of 1998 the next
competition for DES key determination was crowned with success in 39
days only, U.S. National Institute of Standards and Technology (NIST)
announced a competition for AES
(Advanced Encryption Standard) confirmation. AES is to be entirely
public symmetric algorithm with 128-, 192-, 256-bit key and 128-bit block.
Wrong choice of algorithm class
This is also widespread reason, when
a designer chooses good but absolutely unsuitable algorithm for his purposes.
Mostly it is encryption instead of hashing or symmetric algorithm instead
of asymmetric one.
A lot of examples may be given here.
Among them there are almost all the programs, restricting with password
computer access while it is powering on or loading, for example, AMI BIOS,
which stores encrypted version of password (easily
decryptable) instead of hashed one.
It is naturally to use asymmetric cryptography,
which doesn't allow to fit a key even when the entire traffic is eavesdropped,
in all network authentication procedures. However, such algorithms (from
network computer systems) are yet implemented only by Novell Netware 4.x,
the rest are satisfied (in the best case!) with ordinary "challenge-response"
scenario, where one may carry out rather a quick search of eavesdropped
"challenge" and "response" values.
Repeated usage of cipher keystream
Windows 3.x and Windows 95 early versions'
encryption-relevant vulnerability have already become classical example.
Microsoft programmers, known for their security knowledge, applied RC4
(representing none other than stream encryption) several times with the
same keystream to different data (network resources, stored in .pwl-type
It turned out that one of data sets
of .pwl file represents extremely specific text, namely 20-character user
name (in uppercase) and resource pointers set (see Table 1). Thus, guessing
user name (which often coincides with file name) allows to compute at least
20 byte of a keystream. Since keystream remains unchanged while other resources
are being encrypted (it is the main error of RC4 application in this case),
one can compute the first 20 bytes of all resources, containing the length
of each of them. After the length computing one can determine pointer values,
thus adding several tens of bytes to guessed keystream. This algorithm
is implemented in the wide-known glide
Figure 2. .PWL file format.
Storing a key along with data
For this reason data, encrypted with
cryptographically strong and correctly implemented algorithm, can be decrypted
easily. This is because of problem being solved specific, when it is impossible
to enter a key from without, and it is stored somewhere inside, practically
in plaintext form. In other words, the most vulnerable algorithm here will
be not encryption on key but key encryption (on some secondary key). But
since this secondary key cannot be stored on the outside (it evidently
follows from the problem characteristics), the rest data will be decrypted
without exhaustive search sooner or later.
Typical examples here are all of WWW-,
ftp-, e-mail-clients. The point is that for base (the most common) authentication
in these protocols a password is to be transferred to server in public.
That is why client programs are to encrypt (but not hash) a password, and
with fixed key, in order not to pester a user with endless requests. Hence,
all your passwords, practically exposed, are kept somewhere inside any
browser, e-mail- or ftp-client (be it Netscape Communicator, Eudora, Outlook,
FAR, etc.), and it takes no trouble to decrypt
them. (By the way, password is mostly not even encrypted but encoded by
algorithm of base-64 type in such programs).
4. Human factor
Human operator errors are perhaps the
most expensive and widespread in all crucial system. As for cryptosystems,
unskilled user's work brings to naught the strongest cryptalgorithm and
the most correct implementation and application of such algorithm.
Firstly it is conditioned by password
choice. Clearly, short or sensible passwords are easy to remember, but
they are also easy to disclose. Without any doubt, long or senseless passwords
are better in cryptographic strength sense, but in general users cannot
remember them: they write them down on a slip of paper, which can be either
lost or fallen into adversary's hands.
Last years are signed by attention
paid to solving of this conflict, but good password choice recommendations
are out of the scope of this paper.
Since inexperienced users usually choose
either short or sensible passwords, there are two methods of their disclosure:
exhaustive search attack and dictionary attack.
Exhaustive search attacks had got a
good chance of success due to the great advance of computer power (see
also "Short key"). If in UNIX crypt()
function, answering for password hashing, was being executed for nearly
1 second on PDP machine, its execution rate was 15000 times increased (!)
in the space of twenty years. Hackers (and designers, who limited password
length to 8 characters) could not even imagine exhaustive search attack
quite recently, and now this attack succeeds in 80 days at average8.
Table 1 demonstrates exhaustive password search rate for several cryptosystems.
Rate, password per second
- 56 bit
|UNIX - crypt()
|UNIX - MD5
Table 1. Exhaustive search
rate on Pentium/166.
But let return some years back, when computer power was not enough for
exhaustive password search. Nonetheless, hackers have invented a witty
approach, benefited from the fact that in general user chooses sensible
word or some information about himself or his friends (name, birthday,
etc.) as a password. Since any language includes at most 100000 words,
it will not take much time to look them through, moreover, from 10 to 40%
of existing passwords can be guessed with a simple "dictionary attack"
scheme. (By the way, up to 50% of these passwords can be guessed with the
help of dictionary of only 1000 words!). Even Morris' virus (in 1988!)
used this approach, especially as dictionary file, commonly used by corrector
programs, is often at hand in UNIX. As for "own" passwords, one
can get much information about user from the /etc/passwd file: user login
name, name and surname, home directory. Morris' virus benefited from following
- login user name is used as a password;
- doubled user name is used as a password;
- the same read from right to left;
- user name or surname;
- the same in lowercase.
Today users have already understood that they would not choose such
passwords, but computer security experts will scarcely wait for use of
such simple passwords to their liking as 34jXs5U@bTa!6. Therefore
even experienced user uses cunning and chooses passwords like hope1,
user1997, pAsSwOrD, toor, roottoor, parol, gfhjkm, asxz. Clearly, all
of them are generally based on sensible word and some simple transformation,
such as adding a numeric character, adding a year, changing upper-lower
case every letter, writing a word backwards, adding a word written backwards,
writing national (Russian) word in Latin, typing national word with the
Latin keyboard, forming a password of neighbour keys of a keyboard, etc.
So you should not be surprised at hackers" cracking such "sophisticated"
password, they are not more stupid than users and have already inserted
the rules of possible word transformation into their programs. In the most
advanced programs (John
The Ripper, Password
Cracking Library) these rules may be programmable and be given
in special language by hacker himself.
Here is an example of such exhaustive search strategy efficiency. A
lot of books on security recommend to choose two sensible words, divided
by a sign (good!password, for example), as a safe password. Let
us count, how much time it would take to crack such passwords at average,
if such a rule is included into cracker-program set (given dictionary of
10000 words, with 10 numeric characters and 32 punctuation marks and special
symbols as dividing signs, Pentium of 15000 crypt/sec rate): =140000
seconds or less than 1.5 days!
Since this paper was being working on in 1996, the situation with cryptography
usage in application programs has been changing for the better indisputably.
Gradually the developers realize that it is necessary to apply proved algorithms,
the problem of cryptalgorithm export is set in motion in a number of countries,
new algorithms and standards with more key length and efficiency for all
processor types implementation, from 8-bit to RISC processors, are developed.
Nevertheless, a huge gap still remains between strength level and safety
of existing cryptalgorithm software, where "infantile" flaws
are being discovered up to now (the last example is Microsoft's PPTP application
), and cryptographic strength level, demonstrated
by recent algorithms and protocols, tested independently by leading cryptanalysts,
where one of the most serious vulnerabilities requires 265 ciphertext
blocks and then looking through 258 variants, or the same plaintext,
encrypted with 233 different but interdependent keys, and then
analysis complexity of 257 .
I should like to hope for future implementation and application of such
algorithms to keep the high level of safety.
1 Cryptographic strength
here and further means key amount needed for key determination by exhaustive
2 It was such till recently.
Now it is 56 bit.
3 [ ] - integer part (the
nearest integer from below).
4 ] [ - the nearest integer
5 It is obvious that we get
the same values both here and in the example above, but because of rounding
off from different sides it appears one symbol difference.
6 It approximately corresponds
to 56 bit for symmetric algorithms.
7 million instructions per
second in a year.
8 Special boards or concurrency
can give several digits reduction of time overhead.
- "Theory and practice of information security".
Moscow, "Yachtsman", 1996.
- Paul C. Kocher. Timing Attacks on Implementations
of Diffie-Hellman, RSA, DSS, and Other Systems
- Mark W. Eichin, Jon A. Rochils. With Microscope and
Tweezers: An Analysis of the Internet virus of November 1988
- Bruce Schneier, Peter Mudge. Cryptanalysis of Microsoft's
Point-to-Point Tunneling Protocol (PPTP)
- Eli Biham, Lars R. Knudsen, Cryptanalysis of the ANSI
X9.52 CBCM Mode, CS 0928, Proceedings of Eurocrypt'98.
User SURESH.MINT wrote about ver. 2007-01-12
User Reviewer wrote about ver. 2007-01-04
User wrote about ver. 2006-08-17
|Submit your opinion/rating about article:|
Please be constructive and use English language