Concepts/OpenPGP Getting Started/bn: Difference between revisions
Created page with "ধারণা/ওপেনপিজিপি শুরু করা" |
Created page with "Category:শুরু_করা Category:ইন্টারনেট Category:সুরক্ষা Category:টিউটোরিয়াল Category:নতুন ব্যবহারকারী" |
||
| (11 intermediate revisions by the same user not shown) | |||
| Line 18: | Line 18: | ||
ক্রিপ্টো জগতে স্বাগতম! | |||
== | <span id="Key_security"></span> | ||
== সুরক্ষা চাবি == | |||
If keys are involved then the main question is: How secure / reliable are they and their usage? The most important rule in cryptography is not "Make it even more secure" but "(1) Think about how much security you need. (2) Decide which technical effort seems necessary (lower limit) and reasonable (upper limit) to fulfill these requirements. (3) Strictly observe the rules you have determined (write them down). (4) If other people are involved (which usually is the case) let them know precisely and securely what the usage limits and the security level of this key are." Most of the following considerations are about the security and the transparency of their security and meaning. | If keys are involved then the main question is: How secure / reliable are they and their usage? The most important rule in cryptography is not "Make it even more secure" but "(1) Think about how much security you need. (2) Decide which technical effort seems necessary (lower limit) and reasonable (upper limit) to fulfill these requirements. (3) Strictly observe the rules you have determined (write them down). (4) If other people are involved (which usually is the case) let them know precisely and securely what the usage limits and the security level of this key are." Most of the following considerations are about the security and the transparency of their security and meaning. | ||
| Line 30: | Line 31: | ||
== | <span id="Main_key_and_subkeys"></span> | ||
== প্রধান চাবি এবং উপ-চাবি == | |||
Most OpenPGP keys have at least one subkey (all have exactly one main key). You usually need not care about this difference; your application (or rather the base application, usually '''GnuPG''') selects the right one automatically. The main key is the one which the key fingerprint refers to and only the main key can certify: your own subkeys and user IDs and the user IDs of other keys. The subkeys can do everything else (mainly decryption and signing) if you configure them so. The reason the difference between these key types is mentioned here is that this is very important for key generation: You can separate the secret main key from the secret subkeys (with GnuPG; this is not part of the OpenPGP standard!). The subkeys can be replaced later, the main key cannot (that would be a new key not just a modified key). Thus if you create an offline main key at key generation which you protect by a very hard passphrase, store at least the passphrase securely and use the main key (and its passphrase) in secure environments only then you can keep this key "forever" (say 20 years). This is important for everyday keys. High security keys don't really need this separation (usually don't need subkeys at all). You should create one subkey for each capability you need: encryption, signing, and maybe authentication (for SSH). | Most OpenPGP keys have at least one subkey (all have exactly one main key). You usually need not care about this difference; your application (or rather the base application, usually '''GnuPG''') selects the right one automatically. The main key is the one which the key fingerprint refers to and only the main key can certify: your own subkeys and user IDs and the user IDs of other keys. The subkeys can do everything else (mainly decryption and signing) if you configure them so. The reason the difference between these key types is mentioned here is that this is very important for key generation: You can separate the secret main key from the secret subkeys (with GnuPG; this is not part of the OpenPGP standard!). The subkeys can be replaced later, the main key cannot (that would be a new key not just a modified key). Thus if you create an offline main key at key generation which you protect by a very hard passphrase, store at least the passphrase securely and use the main key (and its passphrase) in secure environments only then you can keep this key "forever" (say 20 years). This is important for everyday keys. High security keys don't really need this separation (usually don't need subkeys at all). You should create one subkey for each capability you need: encryption, signing, and maybe authentication (for SSH). | ||
== | <span id="Secure_environment"></span> | ||
== নিরাপদ পরিবেশ == | |||
The key shall be generated in a secure environment and the secret main key shall never be used in an insecure environment. But what is a secure environment? That depends on the security level of the key. If you want to secure nuclear weapons release codes you will have higher requirements to the hardware and software involved than if you just want to keep your affair secret. | The key shall be generated in a secure environment and the secret main key shall never be used in an insecure environment. But what is a secure environment? That depends on the security level of the key. If you want to secure nuclear weapons release codes you will have higher requirements to the hardware and software involved than if you just want to keep your affair secret. | ||
| Line 44: | Line 47: | ||
== | <span id="User_IDs"></span> | ||
== ব্যবহারকারী আইডি == | |||
User IDs are formally just arbitrary strings but expected to consist of a name, an optional comment, and an email address. This structure allows email software to find the suitable key for a recipient address (which most programs require you to confirm for obvious reasons). An OpenPGP public key (more precise: certificate) must have a user ID but can have as many as you like. Thus you can use the same key for several email addresses (which makes sense only if these addresses shall be used at the same security level). Combining addresses has advantages and disadvantages. The main advantage is that you need less keys and thus you and others have less work with certifications. The main disadvantages are that you can revoke user IDs but they keep visible forever and that such a combined key allows to make a trivial connections between different roles of you which you may not want connected: private person, business, other organizations (associations, political parties, whatever). You may want to keep these groups separate. And there are even reasons to keep addresses from the same group separate: reputable addresses (firstname.lastname@example.com), anonymous addresses (heejei7u@example.org), fun addresses (superman17@example.org). It also may be that you have no reason to ever use OpenPGP with certain addresses; such addresses should not be part of a user ID, of course. The decision to add an address to a key and publish that key is forever. But it is easy to add an address later. Thus consider this well before you generate the key. In case of doubt start with fewer addresses. | User IDs are formally just arbitrary strings but expected to consist of a name, an optional comment, and an email address. This structure allows email software to find the suitable key for a recipient address (which most programs require you to confirm for obvious reasons). An OpenPGP public key (more precise: certificate) must have a user ID but can have as many as you like. Thus you can use the same key for several email addresses (which makes sense only if these addresses shall be used at the same security level). Combining addresses has advantages and disadvantages. The main advantage is that you need less keys and thus you and others have less work with certifications. The main disadvantages are that you can revoke user IDs but they keep visible forever and that such a combined key allows to make a trivial connections between different roles of you which you may not want connected: private person, business, other organizations (associations, political parties, whatever). You may want to keep these groups separate. And there are even reasons to keep addresses from the same group separate: reputable addresses (firstname.lastname@example.com), anonymous addresses (heejei7u@example.org), fun addresses (superman17@example.org). It also may be that you have no reason to ever use OpenPGP with certain addresses; such addresses should not be part of a user ID, of course. The decision to add an address to a key and publish that key is forever. But it is easy to add an address later. Thus consider this well before you generate the key. In case of doubt start with fewer addresses. | ||
| Line 51: | Line 55: | ||
== | <span id="Key_type_and_length"></span> | ||
== চাবি প্রকার এবং দৈর্ঘ্য == | |||
ভালো সমর্থিত চাবির প্রকারগুলি হল ডিএসএ (শুধুমাত্র স্বাক্ষর), এলগামাল (কেবলমাত্র এনক্রিপশন), আরএসএ (উভয়) এবং ইসিডিএসএ (উভয়)। গ্নুপিজি ১০২৪ থেকে ৪০৯৬ বিট পর্যন্ত দৈর্ঘ্য সহ চাবি তৈরি করার প্রস্তাব দেয়। (০৮-২০২০ অনুযায়ী) | |||
The differences in security, execution time, signature size, and being required or just considered optional by the standard (rfc4880) are irrelevant for most scenarios. The one relevant difference is: The g10 smartcard supports RSA only. Thus generate an RSA key unless you have concrete and good reason for a different decision. 1024 bit keys are considered breakable by certain well known government agencies today or in the near future. 2048 bit keys are considered safe for decades. But remember: These well known agencies would not waste their time and money by computing your key. They would steal your key. Thus if you want a larger key in order to be safe against this kind of opponent then make sure that they cannot steal it. This obviously requires profound knowledge, discipline and probably some money. The practical reasons against very long keys are: Commonly used versions of GnuPG do not support keys with more than 2048 or 3072 bit respectively length. Operations with asymmetric keys are costly in general. To make it worse: Operation with twice the key size take eight times as long. And it takes long to generate huge keys. For mobile devices this CPU load can become a problem. | The differences in security, execution time, signature size, and being required or just considered optional by the standard (rfc4880) are irrelevant for most scenarios. The one relevant difference is: The g10 smartcard supports RSA only. Thus generate an RSA key unless you have concrete and good reason for a different decision. 1024 bit keys are considered breakable by certain well known government agencies today or in the near future. 2048 bit keys are considered safe for decades. But remember: These well known agencies would not waste their time and money by computing your key. They would steal your key. Thus if you want a larger key in order to be safe against this kind of opponent then make sure that they cannot steal it. This obviously requires profound knowledge, discipline and probably some money. The practical reasons against very long keys are: Commonly used versions of GnuPG do not support keys with more than 2048 or 3072 bit respectively length. Operations with asymmetric keys are costly in general. To make it worse: Operation with twice the key size take eight times as long. And it takes long to generate huge keys. For mobile devices this CPU load can become a problem. | ||
| Line 59: | Line 64: | ||
Thus: Unless you have concrete and good reason for a different decision stick to 2048 bit (at least for everyday keys). | Thus: Unless you have concrete and good reason for a different decision stick to 2048 bit (at least for everyday keys). | ||
== | <span id="Key_expiration"></span> | ||
== চাবি মেয়াদ == | |||
The main key can set (and change) the expiration date for itself and its subkeys. The only "disadvantage" of an expiration date for others is that they have to update the key to keep it usable. But keys shall be updated regularly anyway so you may consider that an advantage as well. The main advantage of an expiration date (for the main key, too) is that keys which are not used any more can easily be recognized as such. The "official" way is another, of course. If a key is abandoned then a revocation certificate should be published. But this may be impossible (key or passphrase lost and no certificate created before (or lost, too)) or you may simply forget to do so (or to publish it everywhere). The "right" validity period is a compromise between reducing disturbance by expired keys (on both sides; remember that you need a secure environment to change the expiration date with an offline main key) and the time which a key still appears valid. One year may be a good choice. | The main key can set (and change) the expiration date for itself and its subkeys. The only "disadvantage" of an expiration date for others is that they have to update the key to keep it usable. But keys shall be updated regularly anyway so you may consider that an advantage as well. The main advantage of an expiration date (for the main key, too) is that keys which are not used any more can easily be recognized as such. The "official" way is another, of course. If a key is abandoned then a revocation certificate should be published. But this may be impossible (key or passphrase lost and no certificate created before (or lost, too)) or you may simply forget to do so (or to publish it everywhere). The "right" validity period is a compromise between reducing disturbance by expired keys (on both sides; remember that you need a secure environment to change the expiration date with an offline main key) and the time which a key still appears valid. One year may be a good choice. | ||
== | <span id="Revocation_certificate"></span> | ||
== প্রত্যাহার শংসাপত্র == | |||
A revocation certificate is a file (or print-out) which you may create preventively to later revoke a whole key in case you have no access to the secret main key any more. This is a huge advantage if you have not just lost access to the key but someone else has! The disadvantage is: You should protect this file / print-out similarly well as the secret main key itself. It can be serious damage if you have only one (suitable) key, need it urgently and someone else destroys it right then. Obviously a main key revocation is forever (cannot be superseded by a newer self-signature). | A revocation certificate is a file (or print-out) which you may create preventively to later revoke a whole key in case you have no access to the secret main key any more. This is a huge advantage if you have not just lost access to the key but someone else has! The disadvantage is: You should protect this file / print-out similarly well as the secret main key itself. It can be serious damage if you have only one (suitable) key, need it urgently and someone else destroys it right then. Obviously a main key revocation is forever (cannot be superseded by a newer self-signature). | ||
| Line 71: | Line 78: | ||
== | <span id="Passphrase,_safe_storage,_and_backup"></span> | ||
== পাসফ্রেজ, নিরাপদ সঞ্চয়স্থান, এবং ব্যাকআপ == | |||
You should think about where you will store the passphrase for the main key and the revocation certificate file or print-out. Secure passphrases are hard to remember. You will most probably have to write it down. You really should not use a passphrase you have ever typed on an insecure system (and, of course, you really should not ever do so in the future). You should choose something like rsbBwNl137LcWP33RI: 18 chars consisting of lower and upper case letters and digits. Don't use special chars or umlauts. You gain little security (if you cannot remember 18 random chars then you probably cannot remember 15, too) but may get problems if you are ever forced to use the key on a rescue system (text mode Linux) with "wrong" keyboard settings. You improve security if you memorize a part of the passphrase and write down just the rest or if you write down both halves of it separately and store them in different places (one in your wallet, the other one at home). But if you store an 18 chars passphrase in two parts and an attacker gets one of them then the remaining 9 chars are not a secure protection any more. If you have created a revocation certificate then you have to store that in a safe place, too. | You should think about where you will store the passphrase for the main key and the revocation certificate file or print-out. Secure passphrases are hard to remember. You will most probably have to write it down. You really should not use a passphrase you have ever typed on an insecure system (and, of course, you really should not ever do so in the future). You should choose something like rsbBwNl137LcWP33RI: 18 chars consisting of lower and upper case letters and digits. Don't use special chars or umlauts. You gain little security (if you cannot remember 18 random chars then you probably cannot remember 15, too) but may get problems if you are ever forced to use the key on a rescue system (text mode Linux) with "wrong" keyboard settings. You improve security if you memorize a part of the passphrase and write down just the rest or if you write down both halves of it separately and store them in different places (one in your wallet, the other one at home). But if you store an 18 chars passphrase in two parts and an attacker gets one of them then the remaining 9 chars are not a secure protection any more. If you have created a revocation certificate then you have to store that in a safe place, too. | ||
| Line 78: | Line 86: | ||
== | <span id="Key_policy_and_policy_URL"></span> | ||
== মূল নীতি এবং নীতি URL == | |||
You should write a document (plain text or HTML) which describes the intended usage and security of your key and (maybe added later) your criteria for certifying the keys of other people. You can write one or more URLs at which this document can (later) be found into the key and in every signature you make. This key component is called a policy URL. It is a good idea to publish only user ID signatures which contain this policy URL(s). It is important that the users of your key can check whether a certain document belongs to a policy URL (the web server download is not safe, not even over HTTPS). Thus you should change the policy URL every time you change the document and mention the URL well visible in the document. You may use this pattern: <tt><nowiki>http://yourdomain.example.org/openpgp/0x12345678__policy.1.htm</nowiki>l</tt> This document should have a detached signature (or a cleartext signature if it is plain text) by the offline main key. You should link the detached signature from the document. | You should write a document (plain text or HTML) which describes the intended usage and security of your key and (maybe added later) your criteria for certifying the keys of other people. You can write one or more URLs at which this document can (later) be found into the key and in every signature you make. This key component is called a policy URL. It is a good idea to publish only user ID signatures which contain this policy URL(s). It is important that the users of your key can check whether a certain document belongs to a policy URL (the web server download is not safe, not even over HTTPS). Thus you should change the policy URL every time you change the document and mention the URL well visible in the document. You may use this pattern: <tt><nowiki>http://yourdomain.example.org/openpgp/0x12345678__policy.1.htm</nowiki>l</tt> This document should have a detached signature (or a cleartext signature if it is plain text) by the offline main key. You should link the detached signature from the document. | ||
== | <span id="Preferred_key_server"></span> | ||
== পছন্দের চাবি সার্ভার == | |||
Like the policy URL a key server URL can be written into the key. You should decide which key server shall be authoritative for your key so that the users of your key know where they have to search for the "officially current version" of your key. This should be the key server which you upload key updates to first. This should be the one you configure in the GnuPG config file (<code>--keyserver</code>) for key searches and uploads. This address should mainly be available for a long time and have only few and short outages. You may even use your own web site: <tt><nowiki>http://yourdomain.example.org/openpgp/0x12345678.asc</nowiki></tt> | Like the policy URL a key server URL can be written into the key. You should decide which key server shall be authoritative for your key so that the users of your key know where they have to search for the "officially current version" of your key. This should be the key server which you upload key updates to first. This should be the one you configure in the GnuPG config file (<code>--keyserver</code>) for key searches and uploads. This address should mainly be available for a long time and have only few and short outages. You may even use your own web site: <tt><nowiki>http://yourdomain.example.org/openpgp/0x12345678.asc</nowiki></tt> | ||
| Line 90: | Line 100: | ||
== | <span id="Algorithm_preferences"></span> | ||
== অ্যালগরিদম পছন্দসমূহ == | |||
You can also write into your key (for others) and into your config file (for your actions) in which order you prefer the cipher and digest algorithms. You should do this before you generate the key (this is easier than changing it afterwards). It makes sense to avoid SHA-1. Please be aware that you cannot prevent that GnuPG creates SHA-1 signatures with your key (because that is the only digest required by the standard). You may want to put lines like these in your <tt>gpg.conf</tt>: | You can also write into your key (for others) and into your config file (for your actions) in which order you prefer the cipher and digest algorithms. You should do this before you generate the key (this is easier than changing it afterwards). It makes sense to avoid SHA-1. Please be aware that you cannot prevent that GnuPG creates SHA-1 signatures with your key (because that is the only digest required by the standard). You may want to put lines like these in your <tt>gpg.conf</tt>: | ||
| Line 101: | Line 112: | ||
</nowiki>}} | </nowiki>}} | ||
== | <span id="Further_reading"></span> | ||
== আরও পড়ুন == | |||
* [[Special:myLanguage/KGpg| | * [[Special:myLanguage/KGpg/bn|কেজিপিজি]] | ||
* [[Special:myLanguage/KMail/PGP_MIME| | * [[Special:myLanguage/KMail/PGP_MIME/bn|কে-মেইল পিজিপি/মাইম]] | ||
* [[Special:myLanguage/KMail/gpg| | * [[Special:myLanguage/KMail/gpg/bn|কে-মেইল জিপিজি]] | ||
* [[Special:myLanguage/Concepts/OpenPGP_For_Beginners| | * [[Special:myLanguage/Concepts/OpenPGP_For_Beginners/bn|নতুনদের জন্য ওপেনপিজিপি]] | ||
* [[Special:myLanguage/Concepts/OpenPGP_For_Advanced_Users| | * [[Special:myLanguage/Concepts/OpenPGP_For_Advanced_Users/bn|উন্নত ব্যবহারকারীদের জন্য ওপেনপিজিপি]] | ||
[[Category: | [[Category:শুরু_করা]] | ||
[[Category: | [[Category:ইন্টারনেট]] | ||
[[Category: | [[Category:সুরক্ষা]] | ||
[[Category: | [[Category:টিউটোরিয়াল]] | ||
[[Category: | [[Category:নতুন ব্যবহারকারী]] | ||
Latest revision as of 08:02, 19 November 2023
ভূমিকা
When creating a key you make several technical and organizational decisions (whether you are aware of that or not) which heavily influence the security and usability of your key, as a result the operating life of the key. Some of these decisions cannot be changed afterwards. For several reasons it is desirable that normal keys – even rather insecure ones – (at least their core) have a long operating life.
Thus this article shall make you familiar with the important aspects of key generation and help you generate a good key which you can use for many years. This article covers just the concepts you should be familiar with, it does not contain a step by step tutorial for key generation because these should be separate phases: First understand and plan what you are going to do and make the necessary preparations. If you have finished that have a look at the OpenPGP key generation article.
How to get started
You can easily create a key for playing around. But if you let others verify such a key you risk throwing work away later. Your aim should be to create one or more long term keys. The best advice is: Don't try on your own if you can avoid it. Ask experts if you can, people who already have replaced a key of their own and learnt from that. Use a secure system to create a key, use an offline main key and give both the main key and the subkeys an expiration date (not more than a year). Select a key policy (describing the security and usage of main key and subkeys) and stick to it. If you certify other keys before you have a certification policy, do not certify them for the public (web of trust), make local signatures instead (just for yourself). Avoid doing new things before you understand well what they mean.
এবং এটা মনে রাখবেন:
- What is comfortable (at least nearly) always threatens your security.
- More secure is not always better for the given task. Just be aware of the consequences (in both directions).
ক্রিপ্টো জগতে স্বাগতম!
সুরক্ষা চাবি
If keys are involved then the main question is: How secure / reliable are they and their usage? The most important rule in cryptography is not "Make it even more secure" but "(1) Think about how much security you need. (2) Decide which technical effort seems necessary (lower limit) and reasonable (upper limit) to fulfill these requirements. (3) Strictly observe the rules you have determined (write them down). (4) If other people are involved (which usually is the case) let them know precisely and securely what the usage limits and the security level of this key are." Most of the following considerations are about the security and the transparency of their security and meaning.
Nobody cracks keys by brute force attacks. That is (even for rather short keys, say 1024 bit) simply impossible for everyone beneath the level of a government agency of a "rich" country within the next decades. And it would not make sense: It's so easy to just steal them. With a huge probability the system which you are just using to read this text (if not printed...) is not very secure. De facto no system which is used for reading email or reading web pages is safe. Don't argue, just accept this. If you don't you probably just compromise yourself. A key is never more secure than the least secure system on which it has been used (this, of course, includes: created). And it is more secure than the least secure system on which it has been stored just by its passphrase which is no protection against a brute force attack if it is either not really random or less than about 16 characters long (for small and capital letters and digits).
It is perfectly OK to use OpenPGP on such insecure systems (i.e. normal computers). You and your communication partners(!) just have to be aware of the security level. The next security level are smartcards. You cannot steal a key from a smartcard (you can abuse it nonetheless if you control the system to which the smardcard is connected). The next level after smartcards are secure systems: Unconnect your harddisk, all USB sticks (and the like) and the network, boot from a secure medium like a Linux live DVD (from a trusted source, of course!). Use high security keys in such a secure environment only (and maybe even limited to safe document formats like plain text or HTML).
প্রধান চাবি এবং উপ-চাবি
Most OpenPGP keys have at least one subkey (all have exactly one main key). You usually need not care about this difference; your application (or rather the base application, usually GnuPG) selects the right one automatically. The main key is the one which the key fingerprint refers to and only the main key can certify: your own subkeys and user IDs and the user IDs of other keys. The subkeys can do everything else (mainly decryption and signing) if you configure them so. The reason the difference between these key types is mentioned here is that this is very important for key generation: You can separate the secret main key from the secret subkeys (with GnuPG; this is not part of the OpenPGP standard!). The subkeys can be replaced later, the main key cannot (that would be a new key not just a modified key). Thus if you create an offline main key at key generation which you protect by a very hard passphrase, store at least the passphrase securely and use the main key (and its passphrase) in secure environments only then you can keep this key "forever" (say 20 years). This is important for everyday keys. High security keys don't really need this separation (usually don't need subkeys at all). You should create one subkey for each capability you need: encryption, signing, and maybe authentication (for SSH).
নিরাপদ পরিবেশ
The key shall be generated in a secure environment and the secret main key shall never be used in an insecure environment. But what is a secure environment? That depends on the security level of the key. If you want to secure nuclear weapons release codes you will have higher requirements to the hardware and software involved than if you just want to keep your affair secret.
At any rate you should not boot from your harddisk (ideally disconnect it) but from some trustworthy read-only medium. This is usually a Linux CD/DVD. You should pay attention to getting this from a safe source. Just downloading some image from the Internet and burning it to a blank doesn't make a secure environment up. In general a pressed CD/DVD (e.g. from a magazine or bought on its own) seems more trustworthy.
Hardware is important, too. If you use a system which was known in advance to be used for the generation of valuable keys somebody might like the idea to add a hardware keylogger. Pay attention to rather trivial attacks: Prevent everybody else from seeing you typing your passphrase (even through windows) and from seeing your slip of paper with the passphrase. Reboot the system after key creation or (better) power it off and keep it so for three minutes.
ব্যবহারকারী আইডি
User IDs are formally just arbitrary strings but expected to consist of a name, an optional comment, and an email address. This structure allows email software to find the suitable key for a recipient address (which most programs require you to confirm for obvious reasons). An OpenPGP public key (more precise: certificate) must have a user ID but can have as many as you like. Thus you can use the same key for several email addresses (which makes sense only if these addresses shall be used at the same security level). Combining addresses has advantages and disadvantages. The main advantage is that you need less keys and thus you and others have less work with certifications. The main disadvantages are that you can revoke user IDs but they keep visible forever and that such a combined key allows to make a trivial connections between different roles of you which you may not want connected: private person, business, other organizations (associations, political parties, whatever). You may want to keep these groups separate. And there are even reasons to keep addresses from the same group separate: reputable addresses (firstname.lastname@example.com), anonymous addresses (heejei7u@example.org), fun addresses (superman17@example.org). It also may be that you have no reason to ever use OpenPGP with certain addresses; such addresses should not be part of a user ID, of course. The decision to add an address to a key and publish that key is forever. But it is easy to add an address later. Thus consider this well before you generate the key. In case of doubt start with fewer addresses.
It makes sense to have a special user ID without an email address. With most email addresses you cannot be sure to have them forever. If you revoke a User ID because you don't use the address any more then you lose all the certifications for this user ID. But you will never lose your name (even if you marry or the like there is usually little reason to revoke that user ID). So you keep the certifications for this ID at any rate. And you can use the comment for this ID for a statement about the key itself: "everyday key with secure offline main key and key policy"
চাবি প্রকার এবং দৈর্ঘ্য
ভালো সমর্থিত চাবির প্রকারগুলি হল ডিএসএ (শুধুমাত্র স্বাক্ষর), এলগামাল (কেবলমাত্র এনক্রিপশন), আরএসএ (উভয়) এবং ইসিডিএসএ (উভয়)। গ্নুপিজি ১০২৪ থেকে ৪০৯৬ বিট পর্যন্ত দৈর্ঘ্য সহ চাবি তৈরি করার প্রস্তাব দেয়। (০৮-২০২০ অনুযায়ী)
The differences in security, execution time, signature size, and being required or just considered optional by the standard (rfc4880) are irrelevant for most scenarios. The one relevant difference is: The g10 smartcard supports RSA only. Thus generate an RSA key unless you have concrete and good reason for a different decision. 1024 bit keys are considered breakable by certain well known government agencies today or in the near future. 2048 bit keys are considered safe for decades. But remember: These well known agencies would not waste their time and money by computing your key. They would steal your key. Thus if you want a larger key in order to be safe against this kind of opponent then make sure that they cannot steal it. This obviously requires profound knowledge, discipline and probably some money. The practical reasons against very long keys are: Commonly used versions of GnuPG do not support keys with more than 2048 or 3072 bit respectively length. Operations with asymmetric keys are costly in general. To make it worse: Operation with twice the key size take eight times as long. And it takes long to generate huge keys. For mobile devices this CPU load can become a problem.
Thus: Unless you have concrete and good reason for a different decision stick to 2048 bit (at least for everyday keys).
চাবি মেয়াদ
The main key can set (and change) the expiration date for itself and its subkeys. The only "disadvantage" of an expiration date for others is that they have to update the key to keep it usable. But keys shall be updated regularly anyway so you may consider that an advantage as well. The main advantage of an expiration date (for the main key, too) is that keys which are not used any more can easily be recognized as such. The "official" way is another, of course. If a key is abandoned then a revocation certificate should be published. But this may be impossible (key or passphrase lost and no certificate created before (or lost, too)) or you may simply forget to do so (or to publish it everywhere). The "right" validity period is a compromise between reducing disturbance by expired keys (on both sides; remember that you need a secure environment to change the expiration date with an offline main key) and the time which a key still appears valid. One year may be a good choice.
প্রত্যাহার শংসাপত্র
A revocation certificate is a file (or print-out) which you may create preventively to later revoke a whole key in case you have no access to the secret main key any more. This is a huge advantage if you have not just lost access to the key but someone else has! The disadvantage is: You should protect this file / print-out similarly well as the secret main key itself. It can be serious damage if you have only one (suitable) key, need it urgently and someone else destroys it right then. Obviously a main key revocation is forever (cannot be superseded by a newer self-signature).
If you (or someone else you really trust) have another key which is secure enough then you may add this key as a designated revoker to yours (you need not publish this). A designated revoker can revoke another key. Of course, the signature for the designated revoker must be available when this shall be used. If you have not given it to the other person and lost it together with your key then this is useless. If you prefer security over availability then you may make friend A your designated revoker, encrypt this signature for friend B and ask friend C to store it.
পাসফ্রেজ, নিরাপদ সঞ্চয়স্থান, এবং ব্যাকআপ
You should think about where you will store the passphrase for the main key and the revocation certificate file or print-out. Secure passphrases are hard to remember. You will most probably have to write it down. You really should not use a passphrase you have ever typed on an insecure system (and, of course, you really should not ever do so in the future). You should choose something like rsbBwNl137LcWP33RI: 18 chars consisting of lower and upper case letters and digits. Don't use special chars or umlauts. You gain little security (if you cannot remember 18 random chars then you probably cannot remember 15, too) but may get problems if you are ever forced to use the key on a rescue system (text mode Linux) with "wrong" keyboard settings. You improve security if you memorize a part of the passphrase and write down just the rest or if you write down both halves of it separately and store them in different places (one in your wallet, the other one at home). But if you store an 18 chars passphrase in two parts and an attacker gets one of them then the remaining 9 chars are not a secure protection any more. If you have created a revocation certificate then you have to store that in a safe place, too.
And, of course, you should have reliable backups of your key. It is nice if you need not be afraid that somebody has stolen your key but it is probably very unpleasant if you cannot decrypt your data any more. If you have a secure passphrase then you may even put a backup of your secret main key on your web site.
মূল নীতি এবং নীতি URL
You should write a document (plain text or HTML) which describes the intended usage and security of your key and (maybe added later) your criteria for certifying the keys of other people. You can write one or more URLs at which this document can (later) be found into the key and in every signature you make. This key component is called a policy URL. It is a good idea to publish only user ID signatures which contain this policy URL(s). It is important that the users of your key can check whether a certain document belongs to a policy URL (the web server download is not safe, not even over HTTPS). Thus you should change the policy URL every time you change the document and mention the URL well visible in the document. You may use this pattern: http://yourdomain.example.org/openpgp/0x12345678__policy.1.html This document should have a detached signature (or a cleartext signature if it is plain text) by the offline main key. You should link the detached signature from the document.
পছন্দের চাবি সার্ভার
Like the policy URL a key server URL can be written into the key. You should decide which key server shall be authoritative for your key so that the users of your key know where they have to search for the "officially current version" of your key. This should be the key server which you upload key updates to first. This should be the one you configure in the GnuPG config file (--keyserver) for key searches and uploads. This address should mainly be available for a long time and have only few and short outages. You may even use your own web site: http://yourdomain.example.org/openpgp/0x12345678.asc
Availability is improved if a server pool (with the same DNS address) is used. If you have no better idea then you may use hkp://pool.sks-keyservers.net or one of the more local pools hkp://eu.pool.sks-keyservers.net (Europe), hkp://na.pool.sks-keyservers.net (North America) or hkp://sa.pool.sks-keyservers.net (South America). See http://sks-keyservers.net/overview-of-pools.php
অ্যালগরিদম পছন্দসমূহ
You can also write into your key (for others) and into your config file (for your actions) in which order you prefer the cipher and digest algorithms. You should do this before you generate the key (this is easier than changing it afterwards). It makes sense to avoid SHA-1. Please be aware that you cannot prevent that GnuPG creates SHA-1 signatures with your key (because that is the only digest required by the standard). You may want to put lines like these in your gpg.conf:
personal-cipher-preferences AES256,AES192,AES,CAST5,3DES personal-digest-preferences SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1 cert-digest-algo SHA512 default-preference-list AES256,AES192,AES,CAST5,3DES,SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1,ZLIB,BZIP2,ZIP