Digital Signature & Identification

Posted on 2005-04-07
Last Modified: 2010-04-11
Suppose that I have a key pair (Private and Public) to communicate securely via email when it is necessary. Let's assume that someone else one the net e.g. e-shop wants to identify myself as a client using Public Key Cryptography. Do I have a create a different key pair (Private and Public) in order identify myself securely to the e-shop's server?
Question by:emmanuel_
    LVL 27

    Expert Comment

    You could send your public key to that e-shop to communicate via email.

    Though it would be best to upload that key to a keyserver and point the recepient to that key on the public keyserver.


    Author Comment

    We have two different situations of identification here:

    1.myself communicating with the other party via email using Public Key Cryptography. Here we are talking about the past i.e. that a message received at some point in the past did indeed come from the claimed sender (digital signature).

    2.myself communicating with an e-shop using Public Key Cryptography. Here we are talking about a live party i.e. I must prove my identification at the point in time when the communication is actually occurring.

    e-shop case \\ Challenge response using Public Key Cryptography between myself and the e-shop:

    a) The e-shop sends me a nonce (random value) in response to my request to log on.

    b) To authenticate myself, I encrypt the nonce with my Private Key, which essentially generates my digital signature.

    c) The e-shop compares my response to the original nonce's value, after decrypting it with my Public Key.

    Though, it is never a good idea to encrypt something with my Private Key and then send it to somebody else, unless I know exactly what I am encrypting. This is because the encrypted value can be used against me. Only I could have done the encryption on the grounds that only I have the Private Key!

    One may suggest the following: OK, you will use (Private1, Public1) keys for communication via email and (Private2, Public2) keys when you want to identify yourself to someone else on-line. So, you will have 2 key pairs, one for digital signature and one for real-time identification. This solution seems to be correct. On the other hand, we know that each and every key pair carries at least the name of its owner. In addition to this, as far as I am concerned, there is no standardized tag on a single key pair, to tell to the outside world ¨Look, this pair is used for digital signing and this for real-time identification¨. This protocol is based on an informal agreement between the two peers i.e. we have agreed to use this key pair when it comes for digital signing and the other one for on-line identification. In conclusion, I don´t think that security must based on such informal agreements between parties. In my humble opinion protocol is not safe and should not be used.

    Someone may pretend to identify me on-line. I'll sign something unknown to me (e.g. the hash value of an e-check of $10,000) with my second key pair and then what will I'll tell to the outside world ... ¨Well, look I signed it but with my identification key pair so the check is not valid¨. No one will believe me because there is no way to prove that this key is used for identification and the other for digital signing.

    Do you think that this two key pair approach is correct, is it applied in practice?  

    I'll appreciate any help.

    LVL 27

    Expert Comment

    This two pair approach is used in practice.

    I worked in a insurrence company that gave each empoyee a encryption key to sign emails and one to sign and encrypt emails.

    The 1st key could only be used to sign but not encrypt emails. They were using tctrust PKI:

    Here you can get such a key for private use:


    Author Comment

    I don't think I am understanding your answer. I haven't mentioned anything about CERTIFICATES (PKI) or ENCRYPTION either. I agree that you may use two key pairs: your PRIVATE key to sign a message and the receiver's PUBLIC key to encrypt the message.
    LVL 27

    Expert Comment

    Nope you get 2 pairs of keys (2 private and 2 public keys):

    1st belongs to you: the pair for signing emails
    2nd belongs to your company: the key pair to encrypt your business emails (the company got a copy of your private key in case something happens to you and you cannot work any longer...)

    A PKI is to sign your keys, to make them trustworthy.

    So it this way: Give me your full name, I create on e.g. an email account, then I create a keypair in your name and upload it to the pgp directory service. Now I send emails signed with that fake private key in your name...

    This is where a PKI comes in business: A e.g. TC-Trust Class 2 or 3  certificate is granted after you sent  a copy of your ID card to TC-Trust. (Class 3 means you have to show them your ID card, I suppose) then they sign your pair of keys with their class 2 or 3 certificate showing the "world" that this key is legit.

    This is the reason I don't really trust a pgp key stored on the directory server. Even if that key is singed by 10 other keys, who says that these are not compromized too.





    Author Comment

    Who is the SENDER and who is the RECEIVER?

    Case 1: If you are the sender and your company is the receiver, it makes sense. When you are away, you SIGN your messages with your PRIVATE key and you ENCRYPT them with your company's PUBLIC key. Only your company can DECRYPT the messages because only they have the PRIVATE key.  

    Case 2: If you and your company are the sender and somebody else is the receiver, it makes no sense. You SIGN your messages with your PRIVATE key and then ...
    >If you ENCRYPT them with your company's PUBLIC key, only you and your company can DECRYPT them because only you have the PRIVATE key.
    >If you ENCRYPT them with your company's PRIVATE key, everybody could DECRYPT them on the grounds that everybody knows your company's PUBLIC key.

    If someone wants to answer my question please read my >>question<< and >>first comment<<.    
    LVL 27

    Expert Comment

    Hehe. Well almost.

    You sign your emails with your private signing key - tell your clients where to find your public signing key.
    Now the email is signed but NOT encrypted.

    If you got the public key of your client/customer you can encrypt your signed email with their key.
    Now your email is signed by you and encrypted, so only your customer can read it.

    Your public key is needed if your customer wants to answer you: The customer can sign their email with their private signing key and encrypt it with your public encryption key. (Don't forget, encrypting with your signing key is not possible, so they need not only your signing public key, but also your encryption public key.)

    If you go to hospital your company can use your private encryption key to decypher the content and keep the business with your client running, because of key escrow.

    That's how secure emails are made: to make sure the recipient get an email really from YOU and no one else claiming to be you AND to make sure the email can only read be the recipient.

    Now you might ask: but why are 2 pair of keys needed? Isn't just one key for both: signing and encrypting sufficient? I say NO: The company could use your private key to fake emails in your name. They could ask their mailserver admin to send an email in your name and even leave it in your outbox. How will you prove the compromising email wasn't written and sent by you? So it's very important that you own your signature.

    To make sure your identity is correct, the PKI comes in place. It has proven by signing your public keys, that you are indeed the Mr. Smith you claim to be.

    The drawback of the who system is, you have to use compatible  en- and decryption methods. But if you talk about $10.000 of dollars you can see this as a good investment.

    For private use: you can use simple pgp with one pair of keys. Since you gave your friends your public key, there is no need to make certain the messages came from you and no one else, since there is (should) be no one who could claim to be you, because you made no key escrow.

    If you communicate with an eshop, right now most use SSL. They claim to be the shop with that name and you can prove it be checking the certificate of the shop. The public key of a trustcenter like verisign is buildin your bowser. So all the browser does is checking if the certificate claiming authenticity is valid.

    Right now the shop owner identifies you most likely by checking your creditcard number or by sending you goods to your home adress.
    This might be a weakness but it speeds up business.

    Hope this helps,

    Author Comment

    My question title is "Digital Signature & Identification" and not "Encryption, Certificates & PKI".

    Tolomir> The information you have given is nice written and to the best of my knowledge correct. I admire that you have tried to answer my question but if I give you the points now, IMHO my question will still be unanswered and I will have to ask it again :(  

    Lets give a last try.

    When trying to answer PLEASE take the following ASSUMPTIONS into account:
    a) the receiver (e-shop) is SURE about the Public Keys of the sender
    b) the protocol used for real-time identification is CHALLENGE RESPONSE (described on my first comment)
    c) two keys pairs are used - ONE for digital signing and ONE when it comes for real-time identification

    1) Is there any option when creating a key pair to DECLARE it as a
        - digital signature key pair or
        - identification key pair
    My answer: NO
    Your answer:
    2) Can this protocol with the TWO keys be applicable in practice?
    My answer: NO, because it is based on an INFORMAL AGREEMENT between the two parties i.e. "we use this key for digital signing and that key for real time identification". Both keys will carry the NAME of the owner and as long as there is NO options to differentiate them (i.e. "this key pair is declared for digital signature use and that for real-time identification") we have a problem.  
    Your answer:
    LVL 27

    Expert Comment

    Alright, I simply asked tctrust about your questions, because I gave you all knowledge I possess in that field.
    I simply translate the answers for you.

    > b) the protocol used for real-time identification is CHALLENGE RESPONSE
    > two keys pairs are used - ONE for digital signing and ONE when it comes for
    > real-time identification

    Here we are talking about 2 pair of keys, with different intended purposes:
    To sign and to authenticate. These certificate porposes called extentions
    are defined by the cetification of the public key by a Certification Authority like TC-trust.
    A certificate for a client is usually defined for both purposes.

    (**Hier geht es um zwei (!) Schluesselpaare, die unterschiedliche
    Zwecke besitzen sollen: Signieren und Authentifizieren. Diese
    Zertifikatszwecke, sog. Extensions, werden bei der Zertifizierung
    des oeffentlichen Schluessels durch eine CA, z.B. TC, festgelegt.
    Ueblicherweise erhalten Clientzertifikate beide Zwecke.**)

    > Questions:
    > 1) Is there any option when creating a key pair to DECLARE it as a
    >     - digital signature key pair or
    >     - identification key pair

    There might be cryptographic tools, that create keys and define extentions,
    but usually this is done by a CA.
    Additional extentions could be SSL or codeSigning.
    --->>So the answer is: YES (but task normally done by a CA)

    (**Moeglicherweise gibt es Kryptographietools, die Schluessel generieren
    und dabei Extensions definieren, aber ueblicherweise macht dies die CA.
    Weitere Extensions koennen sein: SSL oder CodeSigning.**)

    > 2) Can this protocol with the TWO keys be applicable in practice?

    If you really want to use 2 pair of keys, they are definitely different:
    each key has it's own number, fingerprint, moduls etc. even if the
    distingushed name is the same.
    TC-Trust offers keycards, that contain 2 keys with diffrerent purposes of
    --->>So the answer is YES too.

    (**Falls tatsaechlich zwei Schluesselpaare verwendet werden, so sind
    diese eindeutig verschieden: jeder Schluessel hat seine eigene
    Seriennummer, Fingerprint, Modulus, etc., auch wenn der Distinguished
    Name derselbe ist. Auch wir stellen Chipkarten aus, die zwei Schluessel
    mit unterschiedlichen Zertifikatszwecken beinhalten.**)



    A certificate is a public key that has been verified and signed by a Certification Authority. A certificate confirms that a key belongs to the person whose name appears in the subject DN and is therefore often referred to as "electronic ID". The most widely spread certificate formats today are PGP and X.509.

    Certification Authority (CA)

    A Certification Authority is the institution that verifies public keys,  thereby issuing digital certificates. This includes the verification of data contained in such certificates, especially the key holder's identity. TC TrustCenter is such a CA.


    Hope this is information is of use for you.



    Author Comment

    >Tolomir: Thank you very much for your prompt reply.

    I will form one last question.

    General info for the topic:
    In version 3 of X.509 certificate format, the extension field was added. This field is used to indicate what particular applications, a particular certificate may be used for.  
    serverAuth = SSL/TLS Web Server Certificate
    clientAuth = SSL/TLS Web Client Certificate
    CodeSigning = code signing
    emailProtection = email protection (signing, encryption, key agreement)

    Last question:
    Is there any software that enables the  U S E R  (not the CA) to create keys and define extensions? If there is such a software should we prefer it rather than buying certificates from trusted third parties? Are there any vulnerabilities when using this software?

    LVL 27

    Accepted Solution

    2 steps to go:

    1st step:

    You webbrowser like firefox or IE got a huge amount of public keys of different CAs (verisign, thawte, TC-trust, aol ;-), visa)

    So if you want to feel secure the normal way would be to communicate with a webshop that has a TLS webcertificate signed by a CA, your browser got a public key from, implemented by default.

    To let the shopowner know, you are really Mr Smith ;-) you would use a TLS certificate yourself, also signed by a, possible different, CA whose public key is included in the shopowners "database".

    TLS, I have recently learned is a better, newer version of SSL (actually SSL 3.0 is almost compatible to TLS 1.0) supporting authentification for both parties : the shopowner and the customer.

    Shopping this way would instantly create a mutual trust, both parties know, the "man" on the other side is real. Sad enough these days, you can no longer trust any CA, since there is a lot of cheap businessmaking: give me money, and I sign you "a lot", see as reference:

    Example SSL Organization Information Web Site Spoofs - As a result of First-Generation Vetting

    The following example web site spoofs demonstrate the vulnerabilities that exist if First-Generation vetting practices for digital certificates are used in combination with new browser enhancements which bring the certificate Organizational information forward and displayed next to the SSL Lock symbol.

    In short, you still have to check the certificate, if the owner is trustworthy, there are 3 examples to give you an idea.

    So final words of step 1: Using a trustworthy CA, but still taking a look at the certificate, should be the easiest way to make trustfull business.
    If you would use some "homemade" certificates, both the customer and the shopowner would have to make certain, the certificate is no fake.
    Your webbrowser would moan: "the certificate is not valid, do you want to trust is anyway?" This might be ok, if it's not about money, but for real business, use of creditcard numbers, home adress etc.  I would rather use the CA signed solution.

    LVL 27

    Expert Comment

    Step 2. Homemade certificates.

    They only software I have dealt with is openssl.

    The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the OpenSSL toolkit and its related documentation.

    > I guess this is bulletproof.

    Here is a windows version:

    The file openssl-0.9.7g.tar.gz\openssl-0.9.7g.tar\openssl-0.9.7g\doc\openssl.txt

    is all about extentions:

            X509v3 extensions:
                X509v3 Basic Constraints:
                X509v3 Subject Key Identifier:
                X509v3 Authority Key Identifier:
                    keyid:73:FE:F7:59:A7:E1:26:84:44:D6:44:36:EE:79:1A:95:7C:B1:4B:15, DirName:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/Email=email@1.address/Email=email@2.address, serial:00
                X509v3 Key Usage:
                    Certificate Sign, CRL Sign
                X509v3 Subject Alternative Name:
                    email:email@1.address, email:email@2.address

    > but there are some constrains:

    Display only extensions.

    Some extensions are only partially supported and currently are only displayed
    but cannot be set. These include private key usage period, CRL number, and
    CRL reason.

    Hope these 2 steps help you well.


    Author Comment

    Why should someone use seperate key pairs for identification and digital signature?
    LVL 27

    Expert Comment

    Quite easy: Your company gives you full access to the digital signature key pair, that has message encryption disabled: it is your property.
    Your real encryption/identification key pair belongs to the company instead, you get just a copy of the private key. If you die or are seriously injured/sick whatever, your company is able to decrypt your business mail to be able to complete an open task.

    I'm not talking about simple pgp encryption, but certificates from a Certificate Authority: Verisign etc...


    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    Find Ransomware Secrets With All-Source Analysis

    Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

    How to sign a powershell script so you can prevent tampering, and only allow users to run authorised Powershell scripts
    Healthcare organizations in the United States must adhere to the guidance of both the HIPAA (Health Insurance Portability and Accountability Act) and HITECH (Health Information Technology for Economic and Clinical Health Act) for securing and protec…
    In this sixth video of the Xpdf series, we discuss and demonstrate the PDFtoPNG utility, which converts a multi-page PDF file to separate color, grayscale, or monochrome PNG files, creating one PNG file for each page in the PDF. It does this via a c…
    Sending a Secure fax is easy with eFax Corporate ( First, Just open a new email message.  In the To field, type your recipient's fax number You can even send a secure international fax — just include t…

    759 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    11 Experts available now in Live!

    Get 1:1 Help Now