Homework
solution for
CIS729.7:
Cryptography
Dr. Dexter
By Sun Qing
2002.12.13
[On
PKI vs. Kerberos] Both PKI and Kerberos offer the potential of
"single sign-on" authentication. Describe the infrastructure requirements
for single sign-on for both technologies, assuming each is being implemented
on a smallish intranet. Then describe any additional requirements for making
each technology a truly "global" (or at least very-wide-spread)
infrastructure. What are the main challenges in each case? Can you make a
final determination about which seems more likely to be used as a
"global" infrastructure?
First of all, I found two definitions
on the SSO. The first one is, single sign-on user can use many applications;
the 2nd one is, like MSN is doing, storing all sensitive
information on a centralized server, one can use one single username/password
pair to retrieve all for web business; the benefit is, one can limit the time
to input information, which makes the e-commercial more secure. PKI and KERBEROS are both good to for
the SSO definition 1. PKI use CA to proof one’s identity. In SSO, any
application can verify one user’s certificate by questing the CA’s. In
Kerberos, one user first gets TGT from AS and TGS can give user ticket for
the specific application to let user enter the application when user use his
TGT to request so. In both schemes, we can see, if used in a small-ish intranet, they are almost the same. We need only one
CA or TGS/AS. There’s no need to use sibling CA’s. But if going global, by PKI we can
have many CA’s to grant access to applications. In Kerberos, there seems to
be nothing similar to this mechanism. PKI is more fitful for a big network.
[On Hash Functions]
We (briefly) discussed some of the desirable characteristics of cryptographic
hash functions, including "strong collision resistance." a.
Discuss whether or not this is a desirable
characteristic for hash functions in general (i.e. non-cryptographic
applications). Explain why or why not. b.
What sort of attack could be mounted against a hash
function (in a cryptographic application) that didn't have strong
collision resistance?
a)
It may not be a desirable characteristic for hash
functions in general. In some of the cases, Hash function is mainly to
compress the searching space. In those applications, we don’t expect it with
a good collision resistance property; instead we care the efficiency of the
compression and the ease of computation. For example, in data structure, the
hash table can always use hash function to facilitate the searching of data.
In this situation we just want the data can be evenly placed into each slot.
We need not security here, so, need no collision resistance. b)
We can have the chosen-text attack mounted if the
hash function doesn’t have strong collision resistance. The more
efficient attack can be the birthday attack. This attack is based on the
Birthday Paradox. Suppose that the number of bits in
the digest is n. Any message M can be represented (written) in
many different ways (e.g., by adding blanks and empty lines, using equivalent
words, abbreviations, and full wording, or removing some words whose existence
is not essential). Attacker generates r1 variants
of an original message and r2 variants of a bogus message. The
probability of finding a pair of variants (one of the genuine and one of the
bogus message) which hash to the same digest is
where
r2>>1. When r1 = r2 = 2n/2,
the above probability is about 0.63. Therefore, any hashing algorithm which
produces digests of the length about 64 bits is insecure as the time
complexity function for the corresponding birthday attack is about 223.
From
this we can see, the strong collision resistance is required against birthday
attacks.
[On Secure Code Technologies] Read this
report on .NET security, and then write a couple paragraphs on whether .NET
or Java security is better designed to deal with the security challenges of
"run anywhere" code. (Your response will almost certainly be too
simplistic -- I don't want you to write TOO much -- but that's OK. (You
might also want to skim the article on user authentication in Java so have a
fuller sense of its security architecture).
.Net and Java all provide
some security mechanism. In different fields, they have different
performance. It’s impossible to say which one is better in general. The main languages of
these two platforms C# and Java look very similar. They all remove pointer
and use garbage collection. In language level, we can say they are tie. .Net
and Java both provide evidence-based security or the akin. .Net seems better
than Java, because .Net is highly integrated into Windows system. It can use
system information to help to make a decision. As for code access security, .Net
is also better than Java. At least the .Net’s code verification is stronger
than Java by default. Because Java has no JIT
compiling option, we can not compare the verification process security .Net
has. But Java security manager does make the verification process when it
executes a Java program. To role-based security,
Java is trusted better than .Net. JAAS provides more scalability and
modifiability. JAAS is available for Java developers to modify and then plug
in pluggable authentication modules, it provides rich customization, making
Java's authentication preferable to .NET's. Java is
also proved better than .Net for secure communication. .NET developers will
need to use IIS for communication protection—and that doesn't bode well for
the platform's communication security, since IIS might be the most attacked
server in the world. The last thing is, .Net
is running mainly under Windows, which is much less secure and stable than
UNIX. For a common server usage, Java+UNIX can be
much better than .Net+Windows. |
