I have no idea how to do this coding project for class. This course wasn\'t even

Question

I have no idea how to do this coding project for class. This course wasn't even supposed to have anything to do with coding but he surprised us with this project. I really need help!!

1. Design and build a blind signature protocol to be used as part of a Digital Cash system. Build the protocol using C# and Visual Studio.
2. Use the RSACryptoServiceProvider class to generate RSA public and private keys and modulus for the bank. Use the BigInteger class to store these values.
3. The customer generates 100 coins, each worth $5, and blinds each coin using a 128-bit random number. Use the RNGCryptoServiceProvider class to generate these random numbers.
4. The bank requests the customer to un-blind the first 99 coins by providing the corresponding 99 random numbers. Upon checking to see that the amount is the same ($5) in all 99 coins, the bank blindly signs the 100th coin.
5. Upon receiving the blindly signed coin from the bank, the customer un-blinds it to create a coin signed by the bank that can be spent with a merchant.
6. As the last step, check the coin signed by the bank using the bank’s public key (the merchant normally does this in a Digital Cash system but you are not required to implement merchant functionality and cheating detection).

Explanation / Answer

In cryptography a blind signature as introduced by David Chaum[1] is a form of digital signature in which the content of a message is disguised (blinded) before it is signed. The resulting blind signature can be publicly verified against the original, unblinded message in the manner of a regular digital signature. Blind signatures are typically employed in privacy-related protocols where the signer and message author are different parties. Examples include cryptographic election systems and digital cash schemes.

An often-used analogy to the cryptographic blind signature is the physical act of a voter enclosing a completed anonymous ballot in a special carbon paper lined envelope that has the voter's credentials pre-printed on the outside. The ballot can be marked through the envelope by the carbon paper. The voter hands the sealed envelope to an official who verifies the credentials and signs it. Once signed, the package is given back to the voter, who transfers the now signed ballot to a new unmarked normal envelope. Thus, the signer does not view the message content, but a third party can later verify the signature and know that the signature is valid within the limitations of the underlying signature scheme.

Blind signatures can also be used to provide unlinkability, which prevents the signer from linking the blinded message it signs to a later un-blinded version that it may be called upon to verify. In this case, the signer's response is first "un-blinded" prior to verification in such a way that the signature remains valid for the un-blinded message. This can be useful in schemes where anonymity is required.

Blind signature schemes can be implemented using a number of common public key signing schemes, for instance RSA and DSA. To perform such a signature, the message is first "blinded", typically by combining it in some way with a random "blinding factor". The blinded message is passed to a signer, who then signs it using a standard signing algorithm. The resulting message, along with the blinding factor, can be later verified against the signer's public key. In some blind signature schemes, such as RSA, it is even possible to remove the blinding factor from the signature before it is verified. In these schemes, the final output (message/signature) of the blind signature scheme is identical to that of the normal signing protocol.

The same sort of idea can be used to construct a digital analogue of cash. The key property of cash is anonymity: when you take money out of the bank, the bank gives you the cash without knowing what you buy, and when you spend money, the merchant has no idea who you are. By contrast, when you buy something with a credit card online, you have to tell the merchant who you are, and you have to tell the credit card company who you are making a purchase from. The potential for invasion of privacy is immense. For the purposes of this construction, we will assume that all coins are worth a dollar. To withdraw a dollar from her account, Alice generates a coin C, applies a public hash function f, and masks the result by encrypting it with Ea. The bank signs Ea(f(C)) with S and debits Alice’s bank account. Alice then computes Da(S (Ea(f(C)))) to strip away her encryption, leaving her with S (f(C)), and checks to make sure S(S (f(C))) = f(C). To spend her dollar, Alice gives S (f(C)) and C to a merchant. The merchant computes S(S (f(C))) and compares that to f(C) to make sure the coin was actually signed by the bank (without the use of f, Alice could simply have taken a random X and presented the pair (X, S(X)) as a pair (S (C), C)). Then the merchant sends S (f(C)) and C to the bank, which checks the validity of the signature, pays the merchant, and puts C on a list of coins that have already been spent. This scheme preserves Alice’s anonymity and it lets the bank detect double-spending, but it provides no way to punish double-spenders. The only way Alice could be caught trying to double-spend is if the merchant is online and has the bank check her coin in real time. Jeremy talked about zero-knowledge proofs, which allow Alice to prove to Bob that she knows something, for example a square root modulo a composite n, while not revealing the information itself. David Chaum, Amos Fiat, and Moni Naor used similar ideas to build a digital cash protocol that lets Alice maintain her anonymity so long as she doesn’t cheat; the penalty for cheating is having her identity revealed. To begin with, the bank fixes a security parameter k that determines how likely it is to catch double-spenders—large k make it harder to cheat, and the probability that a cheater will be caught goes to 1 very quickly as k increases. Additionally, Alice has an account number u with an associated counter v (both Alice and the bank know the account number and the counter), and there are two functions f, g : Zn × Zn Zn which are hard to invert. One of 4 Alice’s coins consists of k 4-tuples (ai , ci , di , ri) Z 4 n , which she chooses at random. To get a coin signed, Alice proceeds as follows: 1. Alice computes the k blinded values Bi = Ea(f(xi , yi)), where xi = g(ai , ci) and yi = g(ai (u k (v + i)), di), and sends them to the bank. Here denotes bitwise exclusive or, and k denotes concatenation. Alice uses ri as a key for Ea, one for each candidate Bi . 2. The bank chooses a random set R of k/2 indices, and sends it to Alice. Alice then reveals (ai , ci , di , ri) for i R. The bank can check that these 4-tuples yield the values of Bi Alice claimed (since it knows u and v), so if Alice tried to cheat, it is likely that the bank catches her at this stage. 3. The bank sends Alice the signed masked coin S ( Q i/R Bi), debits her account, and increments the counter v by k. Here Q refers to some operation preserved by Alice’s encryption scheme and the signing scheme; in the original paper it is actually multiplication, because the signing scheme was extraction of cube roots and Alice’s encryption was multiplication by r 3 i . Alice now applies Da to find the value C = S ( Q i/R f(xi , yi)), and she can check that this is correct by applying S, so she increments v by k. Now that Alice has her electronic coin worth a dollar, she can pay Bob with it: 1. Alice gives C to Bob. 2. Bob sends Alice a random binary string of length k/2; if the ith bit is 1, then Alice sends Bob ai , ci , and yi , and if the ith bit is 0, then Alice sends xi , ai (u k (v + i)) and di . Bob can now check that these pieces of data fit the value of C Alice provided. Since f and g are assumed to be impossible to invert, and the bank’s signing scheme is assumed to be impossible to duplicate, if Alice is lying she is likely to be caught. 3. Bob sends the transcript of his conversation to the bank, which pays him and keeps the transcript on file.

Public key encryption provides a secure, snoop-proof means of transporting small amounts of data from one party to another without the need for any previously agreed secret key information. What one needs to achieve this is a public-private key pair. The public key is made generally available while the private key is kept secret (by the person who generated it in the first place, usually). Data encrypted with the public key can only be decrypted by the person holding a copy of the private key, while data encrypted with the private key is known to come from the holder of that key. There is some further reading here.

Our company, AlpineSoft, uses RSA public key encryption for generating software license codes that cannot be forged. When the user purchases our shareware application, he is emailed a license code which is signed with our private key. At the receiving end, the software verifies this code using our public key and only if the signature is valid is the license code accepted. This procedure is automated, but we ran into problems with the signing process on our public Web server, which runs on a shared hosting service.

A digital signature is a way of proving that a piece of information - a license code in our case - comes from a particular source. What is actually signed is not the data itself, but a hash (also known as a message digest) of the data. A hash is a fixed length string of bytes (16 bytes for MD5 and 20 bytes for SHA1) that is calculated by a 'one-way' hashing algorithm. The idea is that every message almost certainly generates a unique hash value, and contriving a different message which generates the same hash value is effectively impossible. If you want to know more about hashing, read this.

To sign a piece of data, we do this:

In other words, a digital signature is just an encrypted hash of the data to be signed. At the receiving end, the integrity of the signed data is verified as follows:

If the values differ, the signature is not valid. The point about this procedure is that only the sender can generate a valid encrypted hash, since only the sender knows the private key.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.