GitHub の公開鍵でファイルを暗号化する（またはそのスクリプト）

> GitHub に登録している相手の SSH 公開鍵を使ってファイルを RSA 暗号化したい。簡単に。

## TL; DR <sub><sup>（今北産業）</sup></sub>

1. GitHub に公開されている RSA 公開鍵専用ですが、**ユーザとファイルを指定するだけで暗号化できる `bash` スクリプト**を作ってみました。
2. [リポジトリ](https://github.com/Qithub-BOT/QiiCipher/)@ GitHub (自分で実装してみたい方は TS; DR もご覧ください)

1. 使い方。以下は、GitHub ユーザ「KEINOS」宛にファイル「`himitsu.txt`」を暗号化する例です。
    
    ```shell-session:実行例
    $ # Encrypt file for user KEINOS @ GitHub
    $ enc KEINOS himitsu.txt
    ```
    
    ```shell-session:具体的な実行例
    $ ls
    himitsu.txt
    
    $ enc KEINOS himitsu.txt
    KEINOS の GitHub 上の公開鍵を取得中 ... OK
    RSA 形式の公開鍵を PKCS8 形式に変換中 ... OK
    公開鍵でファイルを暗号化中 ... OK
    一時ファイルの削除中 ... OK
    
    暗号化を完了しました。このファイルを相手に送ってください。
    暗号化済みファイル： himitsu.txt.enc
    
    $ ls
    himitsu.txt  himitsu.txt.enc
    ```

> <sup>🐒 &nbsp; デフォルトの状態の macOS HighSierra（OSX 10.13.6）で動作確認済みですが、`bash`, `curl`, `ssh-keygen`, `openssl`, `md5` のコマンドが使える環境であれば **Raspbian や Alpine でも動いた**ので大丈夫だと思います。</sup>
>
> <sup>なお、[秘密鍵をパスフレーズ付きにする](https://qiita.com/KEINOS/items/2abce1e5b15d799ac6d7#comment-b9e8c7727e4d3189efa1)場合はコメント欄もご覧ください。</sup>

### あわせて読みたい

- **Windows 10 の場合**は AES 暗号化を Windows 10 の標準機能だけで実現するバッチコーイな下記記事が参考になると思います。
    - [標準Windowsで追加インストールなしの暗号化ソリューションを作ってみた](https://qiita.com/emadurandal/items/b13ee6a002fa19fb82d7) @ Qiita
- `git-caesar` は、Go 言語で実装されたマルチ・プラットフォームのツールです。Go 使いなら、作り方のすべてが、そこに書いてある。
    - [GitHub 用の公開鍵でパスワードレスの暗号化/復号をしてみる](https://qiita.com/yoshi389111/items/238908e1933a8a4018c6#_reference-400a953e7aa1c42ad326) @ Qiita

### インストール

[パスの通ったディレクトリ](https://www.google.co.jp/search?q=site%3Aqiita.com+path+%E3%83%91%E3%82%B9)で以下のコマンドを実行すると、インストール（ダウンロード＆実行権限変更）できます。

```shell-session
$ curl "https://Qithub-BOT.github.io/QiiCipher/bin/enc" -o enc; chmod +x $_
$ enc --help
```

- 実験的に試したい場合は、パスの通ってない適当なディレクトリで上記を実行し、`$ enc --help` の代わりに `$ ./enc --help` とパスを付けて指定してください。

#### スクリプトのソースとダウンロード

- [ソースを見る](https://github.com/Qithub-BOT/QiiCipher/blob/master/bin/enc) @ GitHub
- [ソースのダウンロード](https://Qithub-BOT.github.io/QiiCipher/bin/enc) @ GitHub Pages （[SHA512チェックサム](https://github.com/Qithub-BOT/QiiCipher/blob/master/bin/checksum.sha512)）
- [暗号・復号コマンドのセット](https://github.com/Qithub-BOT/QiiCipher/) @ GitHub
- 【注意】スクリプトはパスの通ったディレクトリに設置し `chmod +x enc` で実行権限を与えることを忘れないでください。

### 構文

```shell
enc <GitHubユーザアカウント名> <対象ファイルのパス> [ <暗号済みファイルの出力パス> ]
```

第３引数（オプション）が指定されていない場合は、「`<対象ファイルのパス>.enc`」として出力されます。

### 暗号化のフォーマット

以下の仕様で暗号化しています。

- 鍵のタイプ：RSA 公開鍵 を PKCS8 形式に変換したもの
- 鍵の所在： `https://github.com/{$USERNAME}.keys` で公開されている鍵の一番上のもの
- 暗号化のタイプ： RSA
- 強度：公開鍵の強度（長さ）に依存

### 復号

`dec`（`decrypt`）コマンドで復号します。復号には GitHub の SSH 公開鍵とペアとなるローカルの秘密鍵を指定して使います。また `enc` 同様、コマンドをダウンロードして使用します。

```shell-session
dec ~/.ssh/id_rsa himitsu.txt.enc himitsu.txt
```

- ダウンロード: `https://Qithub-BOT.github.io/QiiCipher/bin/dec`
- 詳しくは「[GitHub の公開鍵で暗号化されたファイルを秘密鍵で復号するスクリプト](https://github.com/Qithub-BOT/QiiCipher/blob/master/bin/dec)」をご覧ください。
- 暗号化・復号以外の、電子署名や確認は [GitHub](https://github.com/Qithub-BOT/QiiCipher) をご覧ください。

### 動作検証済み環境

- macOS HighSierra (OSX 10.13.6）
- `openssl version`: LibreSSL 2.2.7

---

## TS; DR （所感と経緯と作り方）

### 機密情報のシェア

Qiita／[Qiitadon](https://blog.qiita.com/161193715974-2/) ユーザの[お遊びサークル](https://github.com/Qithub-BOT/Qithub-ORG)のメンバー間で、センシティブなデータのやり取りが必要になりそうでした。お遊びに使っているサーバや無料ドメインの**アカウント情報などを共有する必要が出てきそうだった**のです。

Google ドキュメントなどでシェアするのもアリですが、メンバー全員が Googler と言うわけではなく、オーナーや管理も手間です。この時、まっさきに思いつくのが**ファイルを暗号化して相手に渡す**方法です。

しかし、ZIP のパスワードなどのように**共通鍵をシェアするのはこのご時世余りよろしくありません**。かと言って、最強の方法である[ハイブリッド暗号](https://ja.wikipedia.org/wiki/%E3%83%8F%E3%82%A4%E3%83%96%E3%83%AA%E3%83%83%E3%83%89%E6%9A%97%E5%8F%B7)（公開鍵・秘密鍵暗号で共通鍵をシェアしてから、共通鍵で暗号化したデータを渡す方法）は、相手側への技術的負荷が高まります。

やはり、１度きりの情報共有なら、使い捨ての公開鍵と秘密鍵を使うのが楽です。（楽か？）

### 公開鍵と秘密鍵暗号とは

「公開鍵・秘密鍵暗号」とは、ペアとなる A と B の２つの鍵があり、**片方の鍵で暗号化したものは、もう片方の鍵でしか復号できないタイプの暗号方式**です。

以下は、Qiita 記事の「hashアルゴリズムとハッシュ値の長さ一覧（＋ハッシュ関数の基本と応用）」の「[ハッシュ関数の基本と特徴](https://qiita.com/KEINOS/items/c92268386d265042ea16#tsdr)」からの抜粋です。

:::note info
<sup>🐒 <strong>【余談】「公開鍵・秘密鍵暗号」とは</strong></sup>
<sub><sup>　「公開鍵・秘密鍵暗号」とは、ペアとなる A と B の２つの鍵があり、<strong>片方の鍵で暗号化したものは、もう片方の鍵でしか復号できないタイプの暗号</strong>です。</sup></sub>
<sub><sup>　つまり <code>A 鍵</code> で暗号化したものは同じ <code>A 鍵</code> では復号できません。ペアとなる <code>B 鍵</code> でしか復号できません。また、その逆も<ruby>しかり<rt>・・・</rt></ruby>です。</sup></sub>
<sub><sup>　この特徴により、片方の鍵を公開しておき、その<strong>公開している鍵で相手に暗号化してもらえれば、もう片方の鍵を持つものでなければ復号できないデータ</strong>が作れます。鍵を公開してるのに、安全に暗号通信やファイルのやりとりが行える魔法が使えます。鍵を公開してるのに、です。</sup></sub>
<sub><sup>　ちなみに「鍵」とは、実質的に、いわゆるパスワードと同じ役割をするものです。ワード（単語）ではなく、覚えられないくらいの長い不規則な文字列、もしくはそれをファイルにしたものを「鍵」と呼びます。そして一般的なパスワードとの違いは自分で決められるものではないことです。伝わるかわかりませんが、「<a href="https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A9%E3%82%B4%E3%83%B3%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88#%E5%BE%A9%E6%B4%BB%E3%81%AE%E5%91%AA%E6%96%87">復活の呪文</a>」をファイルに落としたようなものです。（<a href="https://github.com/KEINOS.keys">具体的な鍵の例</a> @ GitHub）<br>　しかし、本質的には「〜のカギとなる」や「キーポイント」のように「重要な部分を引き出すもの」を「<ruby>鍵<rt>KEY</rt></ruby>」と言います。配列の「<code>key</code>」（鍵）なども、「<code>value</code>」（価値）を引き出す同様の意味です。</sup></sub>
<sub><sup>　公開鍵・秘密鍵暗号で<font color=red>重要</font>なのが <code>A 鍵</code> と <code>B 鍵</code> は「親」と「子」の <code>1:1</code> の関係になっていることです。<strong>「親の鍵」からは同じ「子の鍵」は何度でも作成できますが、その逆（子から親の鍵）は作成できません。</strong></sup></sub>
<sub><sup>　そのため「親」の鍵で暗号化したデータは同じ「親」の鍵では復号できませんが、復号に必要な「子」は作れてしまうということです。つまり、ユーザーは「親の鍵」さえ大切に保管しておけばよく、必要な時に「子の鍵」を作成し、外部に「子の鍵」を公開するのが一般的です。</sup></sub>
<sub><sup>　このことから<strong>親の鍵を「秘密鍵」、子となる鍵を「公開鍵」と呼びます</strong>。秘密鍵は「<ruby>シークレット・キー<rt>Secret Key</rt></ruby>」もしくは「<ruby>プライベート・キー<rt>Private Key</rt></ruby>」、そして公開鍵は「<ruby>パブリック・キー<rt>Public Key</rt></ruby>」とも呼ばれます。</sup></sub>
<sub><sup>　注意点として、「秘密鍵」「公開鍵」は必ずしも暗号化・復号に使うための鍵を指すわけではありません。「value」（価値）を引き出すのに必要な「key」（鍵）のうち、公開するものを「公開鍵」、公開してはいけないものを「秘密鍵」と言います。たまたま、暗号化にも当てはまるというだけです。暗号化に使わないものでも、秘密鍵や公開鍵が存在します。例えば署名鍵など。</sup></sub>
<sub><sup>　また、「公開鍵で暗号化」し「秘密鍵で復号する」といった説明の記事が多いのですが、<a href="https://github.com/Qithub-BOT/QiiCipher">暗号化自体はどちらの鍵でもできますし、反対の鍵で復号できます</a>。ただ、内部的に秘密鍵でやっていることは復号だけです。</sup></sub>
<sub><sup>　この２つの鍵ですが、一般的（？）な方法として素数の概念が活用されています。</sup></sub>
<sub><sup>　例えば、自然数 15 を素因数分解すると 3 と 5 です。しかし、3 という数からは 15 はわかりません。3 を素数とする自然数は無限にあるからです。また、同様に 5 からも 15 はわかりませんが、3 と 5 からは 15 が簡単にわかったり、15 と 3 からは 5 が作成できるような考え方から、さらに工夫されています。もちろん他のアルゴリズムもあり、どれも難しすぎてわかりません。</sup></sub>
<sub><sup>　しかし、「公開鍵・秘密鍵暗号」は欠点も持っています。「大きなデータの暗号化が苦手」なのと「遅い」ことです。特に大きなデータを暗号化する場合は、データをチャンク（ぶつ切り）にしてから各々を個別に暗号化して 1 つにくっ付ける必要があり、復号も逆の手順が必要であるため結構なコストが発生します。サイズも必要以上に大きくなります。</sup></sub>
<sub><sup>　逆に従来の<strong>１つのパスワード（鍵）で暗号化および復号できる暗号方式を「<a href="https://ja.wikipedia.org/wiki/%E5%85%B1%E9%80%9A%E9%8D%B5%E6%9A%97%E5%8F%B7">共通鍵暗号</a>」と呼びます</strong>。決して「共通鍵暗号」が<a href="https://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%AF%E3%82%B3%E3%83%B3">オワコン</a>と言うわけではありません。「共通鍵暗号」は強いアルゴリズムでも処理速度が速く、「公開鍵・秘密鍵暗号」と比べデータサイズが小さいという特徴があります。現在では、大きなファイルの復号や、復号に速度が求められる場合は「共通鍵暗号」で暗号化し、その共通鍵を「公開鍵・秘密鍵暗号でやりとりしておく」もしくは「お互いの公開鍵から生成する」というハイブリッドな手法が多くとられます。</sup></sub>

<sub><sup> （[ハッシュ関数の基本と特徴](https://qiita.com/KEINOS/items/c92268386d265042ea16#tsdr) | hashアルゴリズムとハッシュ値の長さ一覧（＋ハッシュ関数の基本と応用 @ Qiita より）</sup></sub>

:::

### 公開鍵は GitHub のを使おうよ

秘密鍵はローカル（個人の管理の問題）なのでいいのですが、公開鍵をどうするかが問題でした。メールなどで教え合うのも面倒です。

GitHub はユーザー・アカウントページの URL に ".keys" を加えてアクセスすると、ユーザの SSH 用の公開鍵が確認できます。また、`.gpg` を付けると `git push` 時の `verify` を付けるのに必要な GnuPG の公開鍵が確認出来ます。

- 筆者の公開鍵の例
  - https://github.com/KEINOS.keys
  - https://github.com/KEINOS.gpg

幸いメンバー全員が `PR`（プルリク）のために GitHub のアカウントを持っているので、これを利用しつつ、**linux/macOS の標準機能を使って簡単に暗号化できるようにしたい**なと思いました。（WSL2, Windows Subsystem for Linux2, などに OpenSSL を入れれば Windows でも使えるかもしれませんが未検証です）


`git` と GitHub を頻繁に利用している場合、おそらく GitHub に `SSH` の公開鍵を登録していると思いますが、それらが表示されます。SSH キーを登録していない場合は[設定ページ](https://github.com/settings/keys)から「`New SSH key`」で RSA 公開鍵を登録できます。

また、GitHub では `GPG`/`RSA` の２種類の鍵を公開できるのですが、暗号方式は `RSA` 、暗号化には `OpenSSL` を利用することにしました。macOS で `GPG` を使うには別途インストールが必要だったからです。

無事スクリプトを作成することができたのですが、**すべて Qiita 記事にある情報で作成できた**ので、その恩返しとして Qiita にスクリプトの中身を説明したいなと思いました。

また、スクリプトのソースは [GitHub に公開](https://github.com/Qithub-BOT/QiiCipher)しているので TS;DR から最新の全文ソースを見るかダウンロードしてください。

以下は、ソースが何をしているかとポイントの説明です。

### ソースの概略

#### ヘルプの表示

コマンドの必須の引数が指定されていない場合はヘルプを表示させるようにしました。

「アカウント名」と「対象ファイル」の２項目は必須なので、引数の数が 2 より小さい場合はヘルプを表示。また、必須項目が足りないという意味で `exit 1` （エラー）でスクリプトを終了させています。

以後のエラー番号も、すべて `1` で返しているためエラーの追跡にメッセージを頼るしかなく、わかりづらいと感じています。ソースの行数も少ないこともあり、**エラー番号（エラーステータス番号）は `$LINENO` で現在の行番号を返すようにすればよかった**と思いました。

また、ゴリゴリ `echo` するよりはヒアドキュメントを使った方が良かったかもしれません。

```bash:ソース
# ヘルプ表示
# ----------
if [[ $# < 2 ]]; then
  echo
  echo "使い方: $0 <github user> <input file> [<output file>]"
  echo
  echo "- <github user> : 相手の GitHub アカウント名"
  echo "- <input file>  : 暗号化したいファイルのパス"
  echo "[オプション]"
  echo "- <output file> : 暗号化されたファイルの出力先のパス"
  echo "                  指定がない場合は <input_file>.enc として出力されます。"
  echo "[注意]"
  echo "- このスクリプトは 1 ブロックぶんのデータのみ暗号化できます。"
  echo
  exit 1
fi
```

#### コマンド引数の取得

必須項目である、第１引数と第２引数の値を変数に代入しています。

変数名は、個人的には「`NAME_USER`」「`FILE_INPUT`」「`FILE_OUTPUT`」といった、`〜 of 〜` と分けられる大カテゴリ順にスネークケースで分けた方が管理しやすいのですが、今回は読みやすさを優先し、変数は大文字に統一しました。

```bash:ソース
# コマンド引数取得
# ----------------
USERNAME=$1
INPUTFILE=$2
```

#### 出力ファイル名の設定

デフォルトの出力ファイル名を変数「`OUTPUTFILE`」にセットしたのち、第３引数がある場合は上書きするようにしました。

```bash:ソース
# 出力ファイル名設定
# ------------------
OUTPUTFILE=$2.enc
if [[ $# == 3 ]]; then
  OUTPUTFILE=$3
fi
```

#### trap の設定

スクリプトが途中で失敗しても作業中の一時ファイル（`USERNAME.*`）が残らないよう、後処理として `trap` コマンドで終了時の処理を入れました。`trap` はクラスで言うデストラクタのような処理です。

いま思えば、ここはファイルの削除でなく、ランダムに作成した ID のディレクトリを作成し、ディレクトリごと削除した方がより確実だなと思いました。（`rm -rf /` と始まるだけでも心臓に悪いからです）

```bash:ソース
# trap の設定
# -----------
# スクリプト終了後一時ファイルを削除します。
# - 参考URL ： https://qiita.com/m-yamashita/items/889c116b92dc0bf4ea7d
trap "rm -rf /tmp/$USERNAME.*" 0
```

- 参考 Qiita 記事: [初心者向け、「上手い」シェルスクリプトの書き方メモ](https://qiita.com/m-yamashita/items/889c116b92dc0bf4ea7d)



#### 一時ファイルのパス作成

`md5` コマンドでランダムに作成した ID （変数 `TMP`）と、ユーザ名（変数 `USERNAME`）を組み合わせたものを作業ファイルの頭につけるようにしました。（`<ユーザ名>.<ランダムID>.xxx`）

変数 `PATHPUBKEY` は、この後ダウンロードする公開鍵の保存先のファイル・パスです。

ここで `/tmp` ディレクトリを作業ディレクトリと決め打ちしているのですが、[`mktmp` コマンドで今だけ必要なディレクトリを作成する](https://qiita.com/m-yamashita/items/889c116b92dc0bf4ea7d#%E4%BB%8A%E3%81%A0%E3%81%91%E5%BF%85%E8%A6%81%E3%81%AA%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%E3%82%92%E4%BD%9C%E3%82%8B-mktemp)方が確実だなと思いました。今後の改善点です。

```bash:ソース
# 一時ファイル
# ------------
TMP=`md5 -q -s $RANDOM`
PATHPUBKEY=/tmp/$USERNAME.$TMP.pub
```

- 参考 Qiita 記事: [初心者向け、「上手い」シェルスクリプトの書き方メモ](https://qiita.com/m-yamashita/items/889c116b92dc0bf4ea7d)


#### RSA 公開鍵の取得

`curl` で GitHub 上のユーザーの公開鍵を取得し `head` コマンドで１行目のみを抜き出しています。macOS にはデフォルトで入っていない `wget` は使いませんでした。`curl` で正常に取得できなかった場合は `exit 1` のステータスで終了しています。

公開された鍵は登録した順（古い順）に並ぶので、一番上と決めつけずにフィンガープリントなどを指定できれば良かったのですが、まずはシンプルさを優先しました。ここでも、エラーステータス番号は `1` に統一していますが、改善のある箇所だと思います。

```bash:ソース
# RSA 公開鍵の取得
# ----------------
# ユーザの GitHub の公開鍵一覧の１行目を取得
# - 取得先は： https://github.com/<user name>.keys
# - 参考URL ： https://qiita.com/m0r1/items/af16c41475d493ab6774
echo -n "${USERNAME} の GitHub 上の公開鍵を取得中 ... "

curl -s https://github.com/$USERNAME.keys | head -n 1 > $PATHPUBKEY

if [[ $? != 0 ]]; then
  echo "NG：公開鍵を取得・保存できませんでした。"
  exit 1
fi
echo "OK"
```

- 参考 Qiita 記事: [GitHubに登録してる公開鍵を簡単に確認する方法](https://qiita.com/m0r1/items/af16c41475d493ab6774)
- 関連 Qiita 記事: [もう「公開鍵送ってください」というやり取りは不要だった](https://qiita.com/zackey2/items/429c77e5780ba8bc1bf9)

#### 公開鍵のフォーマット変換

GitHub で公開されている鍵のフォーマットが `PEM` でも `PKCS8` 形式でもない `RSA` 形式だったので、`OpenSSL` で使うために `ssh-keygen` コマンドで `PKCS8` 形式に変換しています。

```bash:ソース
# 公開鍵のフォーマット変換
# ------------------------
# - 参考URL ：
#   - https://qiita.com/drobune/items/bf5d689eff7f69ed6866
#   - https://qiita.com/connvoi_tyou/items/3e86b6b68c3f398b3244
echo -n "RSA 形式の公開鍵を PKCS8 形式に変換中 ... "

ssh-keygen -f $PATHPUBKEY -e -m pkcs8 > $PATHPUBKEY.pkcs8

if [[ $? != 0 ]]; then
  echo "NG：RSA -> PKCS8 変換中にエラーが発生しました。"
  exit 1
fi
echo "OK"
```

- 参考 Qiita 記事: [相手のssh公開鍵を使って便利に暗号化する方法](https://qiita.com/drobune/items/bf5d689eff7f69ed6866)
- 参考 Qiita 記事: [sshの公開鍵のフォーマット変更](https://qiita.com/connvoi_tyou/items/3e86b6b68c3f398b3244)

#### データの暗号化

本コマンドの全てと言っていい箇所です。`openssl` コマンドの `rsautil`（`RSA`ユーティリティ）を使って暗号化しています。

この時に渡す引数は３つです。`pkcs8` 形式の公開鍵、対象となるファイルのパス（変数 `INPUTFILE`）と出力先のパス（変数 `OUTPUTFILE`）です。

公開鍵の強度（長さ）によって暗号化できるファイルサイズは異なるため、本来であれば事前にサイズをチェックするのが優しいと思うのですが、エラーを吐き出させる程度にしました。

今後の改善としては、サイズが大きすぎる場合は、[圧縮 & ランダムな共通鍵で AES 暗号化](https://github.com/Qithub-BOT/QiiCipher/blob/master/bin/archive)してから、その共通鍵を暗号化する方法を提案するようにしたいと思います。

なお、[以前までは `-ssl` オプションを付けていた](https://github.com/Qithub-BOT/QiiCipher/commit/aee3c87590f4c5cefdad600b3c1d0e0424f60447)のですが、 OpenSSL のバージョンが `LibreSSL 2.6.5` 以降では廃止されたため、[Mojave ではエラーが出る](https://github.com/Qithub-BOT/Qithub-ORG/pull/179)ので排除しました。

```bash:ソース
# データの暗号化
# ------------
# このスクリプトは 1 ブロックで可能なデータ量のみ暗号化します。そのため長いテキ
# ストや大きいデータは暗号化できません。
# - 参考URL ： https://qiita.com/kunichiko/items/3c0b1a2915e9dacbd4c1
# - RSA鍵のビット長 = 最大暗号化可能バイト数
#        768 =   85
#       1024 =  117
#       2048 =  246
#       4096 =  502
#       8192 = 1018
echo -n "公開鍵でファイルを暗号化中 ... "
openssl rsautl -encrypt -pubin -inkey $PATHPUBKEY.pkcs8 -in $INPUTFILE -out $OUTPUTFILE

if [[ $? != 0 ]]; then
  echo "NG：暗号化に失敗しました。ファイルのサイズなど、エラー内容を確認ください。"
  exit 1
fi
echo "OK"
```

- 参考 Qiita 記事: [OpenSSLコマンドによる公開鍵暗号、電子署名の方法](https://qiita.com/kunichiko/items/3c0b1a2915e9dacbd4c1)
- 参考 [コメント欄](https://qiita.com/KEINOS/items/2abce1e5b15d799ac6d7#comment-b9e8c7727e4d3189efa1) by @emadurandal
- 参考 「[Delete -ssl option from openssl rsautl command](https://github.com/Qithub-BOT/Qithub-ORG/pull/179)」 QiiCipher @ GitHub

#### 一時ファイルの削除

ダウンロードした公開鍵と `pkcs8` 形式に変換した公開鍵を削除しています。

上記で `trap` による同じ後処理を入れているのですが、スクリプト終了表示前に、明示的に作業ファイルを削除していることを表示させたかったので、`trap`はバックアップの削除処理として、あえて同じ作業をさせています。ただ、`DRY` の原則で考えると関数化した方がいいのかもしれません。

```bash:ソース
# 一時ファイルの削除
# ------------------
echo -n "一時ファイルの削除中 ... "
rm $PATHPUBKEY
rm $PATHPUBKEY.pkcs8

if [[ $? != 0 ]]; then
  echo "NG：一時ファイルの削除に失敗しました。 '/tmp/' ディレクトリ内を手動で削除してください。"
  exit 1
fi
echo "OK"
```

#### 終了表示

一連の処理が終了した旨のメッセージを表示し、正常終了ということでステータース「`0`」で　`exit 0` でスクリプトを終了させています。

```bash:ソース
# 終了表示
# --------
echo
echo "暗号化を完了しました。このファイルを相手に送ってください。"
echo "暗号化済みファイル： ${OUTPUTFILE}"
echo
exit 0
```

## おわりに

そもそも、コマンドラインで暗号化する[リテラシー](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%86%E3%83%A9%E3%82%B7%E3%83%BC)を持ち合わせたユーザー同士でないと通じ合えないという悲しいジレンマ。