I want to use e-ID number for performing Encryption/Decryption and Digital Signing - and in order to do so, I've opted a PGP-oriented approach which goes a bit like this.

  • Generating PGP key-pair using e-ID Number (pass-phrase protected)
  • Digital Signing using e-ID Number (private-key) - and verifying the signature legitimacy by matching the sender's e-ID public-key fingerprint/key-id which has been pre-shared (via telephone/meeting) with the recipient.
  • Encrypting using e-ID Number (pre-shared) public-key of the recipient - and will then be Decrypted by using his/her private-key.

There will be a use of 'Random Session Key' for each session - as per the PGP concept and the implementation of classical (RSA, Elgamal) for Encryption/Decryption and (RSA or DSA) for Digital Signatures will be realized.

This is still a quite rogue approach - and therefore I would like you to share your view-point concerning the feasibility and the possible weaknesses of such a mechanism.

I will also appreciate other possible (effective) ways to use the e-ID card features for performing the Encryption/Decryption and Digital Signing - excluding the fact that card's electronic chip itself is equipped with a key-pair (by the reason of not being supported/compatible/encouraged for encryption and just for digital signing).


The number of your ID card is not really a secret, and probably shouldn't even considered one. You could use it as a key for symmetric encryption (but for this purpose you'd have to share it with your communication partners, and everybody knowing the ID could read the communication), but not for public/private key cryptography.

This is the reason why the cards often are (or can be) equipped with public/private key pairs, at least when they provide any cryptographic features.

An interesting way to work around the fact the basic key pair stored on the card is not really released to general usage is available for the German "Neuer Personalausweis" (the digital ID card issued for some years now): you can use the card to prove your identity to an OpenPGP key signing service (German website), which again will sign your key as certificate authority.

Generating PGP key-pair using e-ID Number (pass-phrase protected)

Specifically discussing this point: If you want to use the card's identifier for generating the key, be aware that likely the key space is much smaller than necessary, which will heavily reduce the key's security. Brute-forcing the key might boil down to simply enumerating all possible IDs (which might be made harder using repeated hashing like often done for passwords). Also, everybody getting hold of the ID will be able to calculate the key without problems: the government, possibly also private entities getting hold of your ID card for verification purposes (hotels, airlines, ...).

  • $\begingroup$ Thanks for your response. Agreed (the number of e-ID) is not a secret - but each and every PGP created key-pair is unique (that's the point here). Since, I'm looking to establish a likely close-loop system - where PGP Key-Pair will be generated by the user (on his/her local machine) and the related Public Key will then be distributed (by any personal means). True - using e-ID number (as-it-is) will reduce the key security on a great level and my plan is to use its hash (having a strong padding scheme). How do you see such a system on feasibility and operational grounds ? $\endgroup$ – MSalman Jan 20 '16 at 10:59
  • $\begingroup$ OpenPGP (RSA, ...) keys are only unique for different random seeds. If I understand your plan correctly, you want to use the ID as seed for generating the key pair (but now it is not random any more). You cannot use random numbers, otherwise others would not be able to reproduce the same keys to verify the key belongs to the ID card. But when using the (publicly known) ID as a seed, everybody else can also generate the keys. Am I getting you wrong anywhere? $\endgroup$ – Jens Erat Jan 20 '16 at 11:40
  • $\begingroup$ It will not be the ID as a seed - but its (randomly salted) hash that will be used to generate a Key-pair. Now, there's no need to reproduce anything by anyone - the user will perform the key-generation on his/her local machine (by entering the ID card number - which will then be randomly salted for hashing and the resulting value will be used to generate a key-pair). Everything is being done locally here (public key will also be distributed by the user) - the notion is limited to using just an e-ID number (as a source for creating a PGP key-pair). $\endgroup$ – MSalman Jan 20 '16 at 13:56
  • $\begingroup$ So if you use a randomly salted hash, which ends up in a random result, why use the ID in first place? There's no gain any more, any no reason to do so. $\endgroup$ – Jens Erat Jan 20 '16 at 14:07
  • $\begingroup$ Reason of using ID number at the first place - is having a sense of association - an affiliation which will help in grouping/ or organizing/ or managing identities and authenticating them as well (say there is a national key-server and you put your public-key over there which will then be used by all public/private institutions for communicating with you - and to validate your authenticity by matching the related fingerprint). The benefit here - can be stretched into many contexts, but the question still remains - that how feasible and strong such a system would be ? $\endgroup$ – MSalman Jan 20 '16 at 14:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.