update doc for new passphrase process

This commit is contained in:
NIIBE Yutaka
2013-10-24 16:02:50 +09:00
parent 9b6e2bd160
commit 1b1cf7f0e3
12 changed files with 178 additions and 124 deletions

View File

@@ -27,7 +27,7 @@ consumes more power for nomal usages. These days, many people has
enough computational resource, that would be true, but less is better
for power consumption.
For security, the key length is a single factor. We had and will have
For security, the key length is just a single factor. We had and will have
algorithm issues, too. It is true that it's difficult to update
our public keys, but this problem wouldn't be solved by just have
longer keys.
@@ -37,6 +37,7 @@ device computation power and host software constraints.
Thus, the key size is 2048-bit in the examples below.
Generating keys on host PC
==========================
@@ -95,7 +96,7 @@ Then enter user ID. ::
and enter passphrase for this **key on host PC**.
Note that this is a passphrase for the key on host PC.
It is different thing to the password of Gnuk Token.
It is different thing to the passphrase of Gnuk Token.
We enter two same inputs two times
(once for passphrase input, and another for confirmation). ::
@@ -289,8 +290,9 @@ Backup the private key
======================
There are some ways to back up private key, such that backup .gnupg
directory entirely, use of paperkey. Here we describe backup by ASCII
file. ASCII file is good, because it has less risk on transfer.
directory entirely, or use of paperkey, etc.
Here, we describe backup by ASCII file.
ASCII file is good, because it has less risk on transfer.
Binary file has a risk to be modified on transfer.
Note that the key on host PC is protected by passphrase (which