✅ GitHub の SSH 公開鍵でファイルを暗号化およびローカルの秘密鍵で復号・署名・検証するスクリプトのリポジトリです。
Home Page: https://qiita.com/KEINOS/items/2abce1e5b15d799ac6d7
License: Creative Commons Attribution Share Alike 4.0 International
#44 でディスカッションしていた、外部ファイル化の件です。
外部ファイルを本体に還元する OlioSource を作りました。開発時は各関数や共通処理を外部ファイル化して src 下で行い、oliosource でマージしたものを bin に配置するスタイルです。
以下のように、あちこちにスクリプト一覧の定義が分散されているので、いつか更新漏れのポカをしそう。
.github 下に外部ファイル化した方がいいと思われます。
Line 19 in 3bda474
QiiCipher/.github/update-checksum.sh
Line 13 in 3bda474
追記：
この Issue は POSIX 準拠のための 1 歩目として if [ -e 'path/to/file']; then を if type 'path/to/file'; then に統一するための Issue に変更します。
オリジナル：
Bash メインでなく POSIX 準拠メインにしたいです。
shellspec が POSIX 準拠なので理屈では可能だと思います。
v1.1.0 現在、SSH 公開鍵（https://github.com/<user name>.keys）のみが対象となっています。
GPG 公開鍵も https://github.com/<user name>.gpg で取得可能です。
macOS ユーザの場合は別途インストールが必要な鍵のタイプではあるものの、セキュリティ意識が高いユーザに GPG を好む人が多いのも事実です。
仕様ですが、デフォルトで SSH 公開鍵とし、Issue #8 のフィンガープリント指定した場合、サーチ先に https://github.com/〜.gpg も含めるなどすれば、使用感は変わらないと思います。（できるとは言ってない
ShellSpec の Qiita 記事 @ Google./.github/run-lint.sh で shfmt の lint チェック時に検知漏れがある。shfmt のバージョンにも関係していそう
shfmt v3.3.0 -> 検知しないshfmt v3.2.1-0 -> 検知しないshfmt v3.1.1-0 -> 検知するshfmt のバージョンによって .editorconfig が反映されないケースがあるっぽい以下の 40 行目のインデントにスペースが 1 つ余計に入っています。
Lines 31 to 41 in 6d0cf1e
しかし、テスト結果はパスしています。
===============================================================================
Requirement Check for Linting and Static Analysis
===============================================================================
- ShellCheck version: 0.7.0
- shfmt version: v3.3.0
-------------------------------------------------------------------------------
Running linters
-------------------------------------------------------------------------------
- Shellformat ... OK
- ShellCheck ... OK
これは少し古いローカルの shfmt v3.2.1-0 でも同じ現象でした。
shfmt -i=4 ./.github/run-tests.sh とインデントをオプションで指定すると検知することから、.editorconfig が反映されないパターンがあるようです。
$ shfmt --version
3.2.1-0
$ shfmt -d ./.github/run-test.sh
$ echo $?
0
$ shfmt -i=4 -d ./.github/run-test.sh
--- ./.github/run-test.sh.orig
+++ ./.github/run-test.sh
@@ -37,7 +37,7 @@
return $FAILURE
}
- echo "$(echo "$result" | head -n 2 | tail -n 1)" 'OK'
+ echo "$(echo "$result" | head -n 2 | tail -n 1)" 'OK'
}
# -----------------------------------------------------------------------------問題は、さらに古い shfmt のバージョンだと検知することです。shellspec の Alpine Docker イメージ に shfmt を入れると shfmt v3.1.1-0 が入るのですが、その場合は検知します。
#14 0.278 ===============================================================================
#14 0.278 Requirement Check for Linting and Static Analysis
#14 0.278 ===============================================================================
#14 0.283 - ShellCheck version: 0.7.1
#14 0.289 - shfmt version: 3.1.1-0
#14 0.290 -------------------------------------------------------------------------------
#14 0.290 Running linters
#14 0.290 -------------------------------------------------------------------------------
#14 0.290 - Shellformat ... --- ./.github/run-test.sh.orig
#14 0.305 +++ ./.github/run-test.sh
#14 0.305 @@ -1,71 +1,71 @@
#14 0.305 #!/bin/sh
#14 0.305 # =============================================================================
#14 0.305 # ShellSpec による動的／単体テストの実行スクリプト
#14 0.305 # =============================================================================
#14 0.305
...（略）...
#14 0.306 # -----------------------------------------------------------------------------
#14 0.306 # Functions
#14 0.306 # -----------------------------------------------------------------------------
#14 0.306
#14 0.306 runShellSpec() {
#14 0.307 printf "%s" '- ShellSpec '
#14 0.307
#14 0.307 result=$(shellspec 2>&1) || {
#14 0.307 printf >&2 ": NG\n%s" "$result"
#14 0.307
#14 0.307 return $FAILURE
#14 0.307 }
#14 0.307
#14 0.307 - echo "$(echo "$result" | head -n 2 | tail -n 1)" 'OK'
#14 0.307 + echo "$(echo "$result" | head -n 2 | tail -n 1)" 'OK'
#14 0.307 }
...（略）...
ただ、このバージョン（shfmt v3.1.1-0）は shellspec のテスト構文を正しく解釈できないため、とんでもない数のエラーを吐き出します。そのため、shfmt v3.2 以降での対策が必要です。
FROM shellspec/shellspec:latest AS testbuild
# Install miminum requirements for QiiCipher
RUN apk add --no-cache \
openssl \
openssh \
ca-certificates && update-ca-certificates
# Install requirements for testing
RUN apk add --no-cache \
git \
shellcheck \
shfmt
# Copy the hole repo
COPY . /app
WORKDIR /app
# Run tests
RUN \
/app/.github/run-lint.sh \
&& /app/.github/run-test.shOpenSSH 7.8 以降では、デフォルトの秘密鍵のフォーマットが変更になり、現状の OpenSLL では扱えないと思います。
（手元のはちょっと古いのですけど、現在の最新版の OpenSLL でも使えないですよね？）
参考: 【OpenSSH 7.8】秘密鍵を生成する形式が変更になった件について
この件について、注意書きを追加したほうが良いと考えました。
また、OpenSSHでの合わせてPEM形式（旧型式）での秘密鍵の作り方や、変換方法などを追記するのはどうでしょうか？
そのうち OpenSSL 側で対応すれば不要になる内容ではあるのですが。
以下は、メモです。
秘密鍵をテキストエディタなどで確認して1行目を確認する
-----BEGIN OPENSSH PRIVATE KEY----- とあれば、OpenSSH形式（新形式）-----BEGIN RSA PRIVATE KEY----- とあれば、PEM形式(旧型式)（RSA 以外でも使えるんでしたっけ？）
ssh-keygen -t rsa -b 4096 -m pemssh-keygen -p -m pem -f id_rsa wget でも動くようにmacOS はデフォルトで cURL（v7.64.1）が入っているので、curl で組みました。しかし、Linux の場合は wget がデフォのものが大半だと思います。
別途 curl を入れればいいだけなのですが、openssl 以外はなるべくインストールをさせたくありません。
特に、最新の安定版 Alpine Linux の Docker イメージはデフォルトで wget が入っているので、微々たるものですが、wget でも動くようにしたい。
下記は引数の順番を間違えているのに、公開鍵のアクセス権に問題があるように見えます。
$ verify ~/.ssh/github hello.txt emadurandal
/home/emadurandal/.ssh/github を電子署名 emadurandal で検証します
- hello.txt の GitHub 上の公開鍵を取得中 ... OK
- RSA 形式の公開鍵を PKCS8 形式に変換中 ... @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0664 for '/tmp/verify-/hello.txt.pub' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/tmp/verify-/hello.txt.pub": bad permissions
NG：RSA -> PKCS8 変換中にエラーが発生しました。（Issue #31 より）
引数の順番の検知、もしくはエラー内容に引数の順番に間違いがないかなど、もう少しユーザに優しくてもいいと思います。
v1.1.0 現在、公開鍵の指定はSSH 公開鍵一覧（https://github.com/<user name>.keys）の一番上の鍵が使われます。
しかし、この一覧は登録順に並んでいます。何かしらの理由で公開鍵・秘密鍵のペアを新規作成 or 登録する必要がある場合に不便が予想されます。
例えば --finger xxxxxxx のようなオプションで、マッチした公開鍵が使えるといいなと思います。
bin/archive の openssl の暗号/復号でワーニングが出力されている。
-iterや-pbkdf2を指定すると、互換性のない仕様変更となると思われるので、現状はワーニングを出力する旨のテストを記載している。すべての環境で同じワーニングがでるのかは未確認。*** WARNING : deprecated key derivation used. Using -iter or -pbkdf2 would be better.( #47 (comment) より)
この Issue は、WARNING の英語表記を日本語にするだけとします。
-iter の回数や、相手が -pbkdf2 に対応していない場合などの仕様も決まっていませんが、セキュリティリスクがあることは明確なので、日本語で表示させることで QiiCipher の不具合ではないことを明確化するためです。
OpenSSH 7.2 以降で -pbkdf2 は使えるらしいので、#23 でディスカッションしている OpenSSL と OpenSSH の minimum バージョンの方向性が見えてきたら -pbkdf2 をデフォルトにしてもいいかもしれません。
deprecated key derivation used.
openssl enc などで -salt オプションを有効（デフォルトで有効）にした状態かつ -pbkdf2 オプションが指定されていない、つまり古い関数（pbkdf1 = function 1）が使われている状態で OpenSSH が呼び出されると表示される。Using -iter or -pbkdf2 would be better
-iter オプションでキーストレッチ回数を指定するか、-pbkdf2 でパスワード・ハッシュに function 2（RSA SHA-2）を使わせる設定をすることをオススメしている。key derivation
salt 値を付けてハッシュ化した値をパスコードとすることで強度を強くさせる手法があり、「パスワード・ハッシュ関数」は専用（パスワード専用）のハッシュ関数のことを言う。その際のアルゴリズムに、デフォルトで SHA-1 を使うが -pbkdf2 オプションを使うと SHA-2 のアルゴリズムを使う。
VSCode 1.18 から URL スキームに DevContainer が対応したので、Open in VSCode バッジが使えるようになりました。
このリポジトリは Dev Container に対応しているので、設置した方が .devcontainer ディレクトリを掘らなくてもわかりやすいかな、と。
[](https://open.vscode.dev/organization/repository)つまり、こう。
[](https://open.vscode.dev/Qithub-BOT/QiiCipher)そして、こう。
Open in VS Code badge | June 2021 (version 1.58) @ VSCode 公式実は、先程ちょいとこんなの作りまして。
.batファイルとPowershellコードを組み合わせた簡素なものではありますが、Windowsのエクスプローラーからドラッグ＆ドロップで利用できる感じです。
暗号化するのにちょっと大きなサイズのファイルが必要だと思って、試しに３D系のファイル（42.5 MB）でやってみました。暗号化＆復号しても元通り使えることをデモしています。
発想的には以前Qiitaでリンクいただいた以下の記事と同じです。
https://qiita.com/emadurandal/items/b13ee6a002fa19fb82d7
GUI対応は色々と方針というか、皆様と話し合って進めていくのがいいのかな、と思っているのと、まだコードも荒削りなのでまだPRは作らずにおきます（別件のPRの修正もありますし💦）
あとは、署名と検証もそれぞれarchive.shとdearchive.shでやるようにすると言うことなしかも笑
復号時の秘密鍵については、環境変数で場所を示していれば（図中のQIICIPHER_GITHUB_KEYNAME）、いちいちダイアログで聞かずに環境変数の方を見てくれるようにしています。
（他、.bat->powershell->wsl呼び出しだとPATH環境変数が普通にやるとうまく継承されないっぽく、現状はQIICHIPHER_BINでbinフォルダを教えてあげている感じです）
似たような感じでMacとかも対応できそうですね（.commandとか、あとはAutomatorでもいいかも）
ecdsaの公開鍵でも、ecdh鍵交換をして暗号・復号はできるみたいですね。
ちょっと面倒な感じなので本当にやるかどうかはおいといて、とりあえず方法をメモしておきます。
Alice が SSH 用の秘密鍵と公開鍵を生成。例として、521bit の楕円曲線を使う。（※512bit じゃない）
ssh-keygen -t ecdsa -b 521 -f ./id_ecdsa -C comment
id_ecdsa - Alice の秘密鍵id_ecdsa.pub - Alice の公開鍵公開鍵を GitHub で公開しておく
Bob は、Alice の公開鍵を curl 等でゲットする。
curl https://github.com/【aliceのアカウント】.keys > id_ecdsa_alice.pub
OpenSSH 形式の公開鍵( ecdsa-sha2-nistp521 で始まる1行)を PEM 形式( -----BEGIN PUBLIC KEY----- みたいなやつ )に変換
ssh-keygen -f id_ecdsa_alice.pub -e -m PKCS8 > pub_alice.pem
Bob は使い捨ての秘密鍵・公開鍵のペアを生成する。Alice の公開鍵に合わせて 521bit の secp521r1 で生成。
openssl ecparam -name secp521r1 -genkey -noout -out key_bob.pem
openssl pkey -in key_bob.pem -pubout -out pub_bob.pem
key_bob.pem - 使い捨ての Bob の秘密鍵pub_bob.pem - 使い捨ての Bob の公開鍵生成した使い捨ての秘密鍵と、Alice の公開鍵をもとに、交換する鍵を生成する。
openssl pkeyutl -derive -inkey key_bob.pem -peerkey pub_alice.pem -out shared.bin
生成された交換鍵 shared.bin はバイナリなので、これをもとに共通鍵暗号の鍵をいい感じに生成する。
（ハッシュ化するとか、base64にしてパスワードにするとか、そのまま使うとか？）
Bob が Alice に送りたいデータを、（上記の鍵を使って）共通鍵暗号アルゴリズムで暗号化する。
Bob は、暗号化したファイルと、使い捨ての公開鍵 pub_bob.pem をアーカイブして、Alice に送付する。
Alice は、自分の秘密鍵 id_ecdsa （OpenSSH の新形式の場合には旧型式に変換要）と、送られてきた Bob の使い捨ての公開鍵 pub_bob.pem で、交換鍵 shared.bin を生成する。
秘密鍵の変換が必要なら（ -----BEGIN OPENSSH PRIVATE KEY----- みたいなやつなら）
cp id_ecdsa id_ecdsa.copy
ssh-keygen -p -N "" -m pem -f id_ecdsa.copy # 上書きされる
openssl pkeyutl -derive -inkey id_ecdsa.copy -peerkey pub_bob.pem -out shared.bin
rm id_ecdsa.copy
変換不要なら（ -----BEGIN EC PRIVATE KEY----- みたいなやつなら）
openssl pkeyutl -derive -inkey id_ecdsa -peerkey pub_bob.pem -out shared.bin
shared.bin （Bob が生成したものと同じバイナリになるはず）をもとに、 Bob と同じ方法で共通鍵を生成して、送られてきた暗号ファイルを復号する。
奥村先生のサイトの「ECDH鍵交換」を参考にしました。
PR #5 の md5sum/md5 のラッパー関数が空の値を返します。
if [ -e md5sum ] でコマンドの検知に失敗しているようです。
#shellcheck shell=bash
# This file: tests/md5s_test.sh
# md5s は md5sum/md5 のラッパー関数です.
md5s() {
if [ -e md5sum ]; then
echo "$1" | md5sum
elif [ -e md5 ]; then
md5 -q -s "$1"
fi
}
# md5s のユニットテスト
Describe 'md5s'
It 'should return MD5 hash of the arg 1'
When call md5s 'hoge'
The output should equal 'c59548c3c576228486a1f0037eb16a1b'
The status should be success
End
End
$ # 期待するハッシュ値の確認
$ echo 'hoge' | md5sum | awk '{ print $1 }'
c59548c3c576228486a1f0037eb16a1b$ # テスト実行と結果
$ shellspec --shell '/bin/bash' ./tests/md5s_test.sh
Running: /bin/bash [bash 5.1.0(1)-release]
F
Examples:
1) md5s should return MD5 hash of the arg 1
When call md5s hoge
1.1) The output should equal c59548c3c576228486a1f0037eb16a1b
expected: "c59548c3c576228486a1f0037eb16a1b"
got: ""
# tests/md5s_test.sh:16
Finished in 0.34 seconds (user 0.17 seconds, sys 0.06 seconds)
1 example, 1 failure
Failure examples / Errors: (Listed here affect your suite's status)
shellspec tests/md5s_test.sh:13 # 1) md5s should return MD5 hash of the arg 1 FAILEDcheck コマンドに以下のような記述があります。
RESULT=`enc ${USERNAME} ${PATHFILE} 2>$1`RESULT=`dec ${SECRETKEY} ${PATHFILE}.enc ${PATHFILE}.dec 2>$1`このコマンドの場合、第一引数 $1 はgithubのユーザー名なので、ユーザー名のファイルに標準エラー出力が出力されてしまいます。
おそらく 2>&1 （標準出力と合わせる）あるいは 2>&- （標準エラー出力を閉じる）のどちらかが正しいのではないかと思います。
（個人的には、削除して画面に出力してもよい気がしますが）
e9bac1e で試しておりますが、verifyがうまくいかないようです。
signはうまくいきますが。
╰─ sign emadurandal ~/.ssh/github hello.txt
ファイル hello.txt の署名ファイルを生成中 ... Enter pass phrase for /home/emadurandal/.ssh/github:
OK
✅ hello.txt の電子署名が作成されました。
電子署名の検証を行います
emadurandal の GitHub 上の公開鍵を取得中 ... OK
RSA 形式の公開鍵を PKCS8 形式に変換中 ... OK
ファイル hello.txt の署名ファイルを検証中 ... Verified OK
✅ 電子署名ファイルの検証が完了しました
✅ 署名を完了しました。このファイルを対象ファイルとセットでご利用ください。
対象ファイル ： hello.txt
電子署名ファイル： hello.txt.sigverifyでパーミッションについておこられ、
╰─ verify ~/.ssh/github hello.txt emadurandal
/home/emadurandal/.ssh/github を電子署名 emadurandal で検証します
- hello.txt の GitHub 上の公開鍵を取得中 ... OK
- RSA 形式の公開鍵を PKCS8 形式に変換中 ... @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0664 for '/tmp/verify-/hello.txt.pub' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/tmp/verify-/hello.txt.pub": bad permissions
NG：RSA -> PKCS8 変換中にエラーが発生しました。86行目あたりに試しにパーミッション600にしてみても、
invalid formatとなってしまいます。
╰─ verify ~/.ssh/github hello.txt emadurandal
/home/emadurandal/.ssh/github を電子署名 emadurandal で検証します
- hello.txt の GitHub 上の公開鍵を取得中 ... OK
- RSA 形式の公開鍵を PKCS8 形式に変換中 ... Load key "/tmp/verify-/hello.txt.pub": invalid format
NG：RSA -> PKCS8 変換中にエラーが発生しました。ちょっと自分で調べた限りでは原因がよくわかりませんでした。
環境はWindows10のWSL2、Ubuntu20.04です。キーはkeygenスクリプトで生成しています。
POSIX 準拠の準備として echo -n（改行なし echo）を printf "$s" に代替するリファクタ。
（echo -n は bash を履いている人向けのため）
QiiCipher は、もともとシェル・スクリプト初心者の @KEINOS が、勉強として得た知見を Qiita 記事にまとめたものです。
そのため、コントリビュートにも初心者・未経験者歓迎ムードを作って行きたいです。
そのためには、なんちゃって TDD であることと、Docker コンテナを使った開発が可能であることを記載した CONTRIBUTE.md があるといいなと思いました。
dde7df6 現在、shellspec のテストはパスしているもステータスが "no status" のままです。
手動でテストを走らせてパスするも、NG。CDN のキャッシュかなと思ったのですが、強制リロードでも変わらず。
なぜだ ...
Lines 22 to 28 in b90eaa7
上記 md5r() で使われている $RANDOM は POSIX 環境では定義されないので、必須である openssl にまかせてしまおうというリファクタです。
下記、参考先にサンプルとテストがあるので、流用してください。
bin/checksum.sha512.sig）はリリースに設置（リポジトリ内に置かない）gh コマンドのリリース機能を使って .sig 及び公開鍵を添付（公開鍵の添付は後日秘密鍵が変更された場合に備えて）QiiCipher v2（次期バージョン）では、スクリプト内の処理を関数化して各々テストを設けたいが、その前に shellcheck による静的解析と、shfmt による lint チェック環境を用意したい。
sign コマンドで、引数のパスが間違えていても *.sig ファイルが作成されてしまいます。（Issue #31 (comment) より）
#shellcheck shell=sh
Describe 'sign with unexisting key'
name_file_to_sign="dummy.txt"
path_file_sig_out="${SHELLSPEC_TMPDIR}/${name_file_to_sign}.sig"
It 'should print err with status 1 and should not create .enc file'
When call sign KEINOS '/path/to/unknown/key.pub' "$name_file_to_sign" "$path_file_sig_out"
The stdout should include '署名ファイルを生成できませんでした'
The stderr should include 'No such file or directory'
The status should be failure # status is 1-255
Path file_sig="$path_file_sig_out"
The path file_sig should not be exist
End
End- 実行結果
$ shellspec ./tests/issue31_test.sh
Running: /bin/sh [sh]
F
Examples:
1) sign with unexisting key should print err with status 1 and should not create .enc file
When call sign KEINOS /path/to/unknown/key.pub dummy.txt /tmp/dummy.txt.sig
1.1) The path file_sig should not be exist
The specified path exists
path: /tmp/dummy.txt.sig
# tests/issue31_test.sh:13
Finished in 0.37 seconds (user 0.10 seconds, sys 0.08 seconds)
1 example, 1 failure
Failure examples / Errors: (Listed here affect your suite's status)
shellspec tests/issue31_test.sh:7 # 1) sign with unexisting key should print err with status 1 and should not create .enc file FAILED
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.