لطفا منتظر باشید ...
Cryptography
There is no discussion of security that does not at least reference cryptography or encryption. Although cryptography is an absolute necessity to create a secure environment, it is not the “Holy Grail” of security. This section highlights the cryptography features that come with the .NET Framework. If you already have worked with Windows 2000 Cryptographic Service Providers (CSPs) and/or used the CryptoAPI, you know nearly everything there is to know about cryptography in the .NET Framework.The most important observation is that the ease of use of crypto functionalities has improved a great deal over the way we had to use the CryptoAPI, which only was available for C/C++. An important addition in the design concept of the cryptography namespace is the use of CryptoStreams, which make it possible to chain together any cryptographic object that uses CryptoStreams. This means that the output from one cryptographic object can be directly forwarded as the input of another cryptographic object without the need to store the output result in an intermediate object. This can enhance the performance significantly if large pieces of data have to be encoded or hashed. Another addition is the functionality to sign XML code, although only for use within the .NET Framework security system. To what extend these methods comply with the proposed standard RFC 3075 is unclear.Within the .NET Framework, three namespaces involve cryptography:
System.Security.Cryptography The most important one; resembles the CryptoAPI functionalities.
System.Security.Cryptography .X509 certificates Relate only to the X509 v3 certificate used with Authenticode.
System.Security.Cryptography.Xml For exclusive use within the .NET Framework security system.
The cryptography namespaces support the following CSP classes that will be matched on the Windows 2000 CSPs by the CLR. If a CSP is available within the .NET Framework, this does not automatically imply that the corresponding Windows 2000 CSP is available on the system the CLR is running:
DESCryptoServiceProvider Provides the functionalities of the symmetric key algorithm Data Encryption Standard.
DSACryptoServiceProvider Provides the functionalities of the asymmetric key algorithm Data Signature Algorithm.
MD5CryptoServiceProvider Provides the functionalities of the hash algorithm Message Digest 5.
RC2CryptoServiceProvider Provides the functionalities for the symmetric key algorithm RC 2 (named after the inventor: Rivest’s Cipher 2).
RNGCryptoServiceProvider Provides the functionalities for a Random Number Generator.
RSACryptoServiceProvider Provides the functionalities for the asymmetric algorithm RSA (named after the inventors Rivest, Shamir, and Adleman).
SHA1CryptoServiceProvider Provides the functionalities for the hash algorithm Secure Hash Algorithm 1.
TripleDESCryptoServiceProvider Provides the functionalities for the symmetric key algorithm 3DES.
To be complete, we give short descriptions of symmetric key algorithm, asymmetric key algorithm, and hash algorithm. A symmetric key algorithm enables you to encrypt and decrypt data that is sent between you and another party. The same key is used to both encrypt and decrypt the data. That is why it is called a symmetric algorithm. This algorithm forces you to exchange the key with your counter party, but this must be done in such a way that no other party can intercept this key. Because symmetric key algorithms are often used for a short exchange of data, they are also referred to as session key algorithms. For the exchange of session keys, the parties involved use an asymmetric key algorithm.An asymmetric key algorithm uses a key pair. One key is private and is kept under lock and key by the owner, and the other is public and available to everyone. Because the algorithm uses two related but different keys to encrypt and decrypt, it is called an asymmetric algorithm, but it is also referenced as a public key algorithm. The public key is wrapped in a certificate that is a “proof of authenticity,” and that certificate has to be issued by an organization that is trusted by all involved parties. This organization is called a certificate authority (CA), of which VeriSign is the best known. So, what about using an asymmetric key algorithm to exchange symmetric keys? The best example is two Windows 2000 servers that need to regularly set up connection between both servers on behalf of their users. Each connection—or session—has to be secured and needs to use a session key that is unique in relation to the other secured sessions. The servers exchange a session key for every connection. Both have an asymmetric key pair and have exchanged the public key in a certificate. Therefore, if one server wants to send a session key to the other server, it uses the public key of the other server to encrypt the session key before it sends it. The server knows that only the other server can decrypt the session key because that server has the private key that is needed to decrypt the session key.A hash algorithm, also referred to as a one-way hash algorithm, can transform a variable piece of data into a fixed-length piece of data, called a hash or message digest, that is nearly always much shorter—for example, 160 bits for SHA-1. One-way means that you cannot derive the source data by examining only the digest.
Another important feature of the hash algorithm is that it generates a hash that is unique for each piece of data, even if just one bit of data is changed. You can see a hash value as the fingerprint of a piece of data. Let’s say, for example, you send someone a plaintext e-mail. How do you and the receiver of the e-mail know that the message was not altered as it was being sent? Here is where the message digest comes in. Before you send your e-mail, you apply a hash algorithm to that message, and you send the message and message digest to the receiver. The receiver can perform the same hash on the message, and if the digest and the message are the same, the message has not been altered. Yes, someone who alters your message can also generate a new digest and obscure his act, but that’s where the next trick comes in. When you send the digest, you encrypt it with your own private key, of which you know the receiver has the public part. This solution not only prevents the message from being changed without you and the receiver discovering it but also confirms to the receiver that the message came from you and only you. How?Well, let’s assume that someone intercepts your message and wants to change it. He has your public key, so he can decrypt your message digest. However, because he doesn’t have your private key, he is unable to encrypt a newly generated digest. Therefore, he cannot go forward with his plan to change the e-mail without anyone finding out. Eventually, the e-mail arrives at the receiver’s inbox. She decrypts the encrypted digest using your public key. If that succeeds, she knows that this message digest must have been sent by you, because you are the only one who has access to the private key. She calculates the hash on the message and compares the digests. If they match, she not only knows that the message hasn’t been tampered with, but she also knows that the message came from only you, because every message has a unique hash. Moreover, because she already established that the encrypted hash came from you, the message must also come from you.
