パスワードを忘れた? アカウント作成

スラドのストーリを選ぶための補助をお願いします。

13483200 comment

dodaのコメント: Re:hmac (スコア 1) 2

by doda (#3331817) ネタ元: Tera Term 4.97

この辺りは全体としてどの程度の安全性を求めるかという話になります。

鍵長には等価安全性という考え方があって、例えばハッシュ関数のsha2-512は暗号化のaes256と同じくらいの強度と考えられています。
一つの要素だけ極端に強くしても全体の強度には繋がらないので、例えば256ビット安全性を目指すのならばsha2-512を優先し、
128ビット安全性でもいいとするのならばsha2-256を優先するのがいいと思います。

256ビット安全性の方が確かに安全ではありますが、その分負荷等がかかります。
例えばssh通信で1バイトを送る時(例えば何かキーを押したとか)にはsshパケット本体は32バイト(AES使用時)になりますが、
hmac-sha2-256では32バイト、hmac-sha2-512では64バイトのMACがさらに付加されます。

OpenSSH はこの辺り割り切っていて、現時点ならば128ビット安全性があれば十分としてデフォルト値が決められています。

13483187 comment

dodaのコメント: Re:どんだけミスリードさせたいんだ (スコア 1) 2

by doda (#3331810) ネタ元: SSH での AES-GCM の利用

> AES-GCMは危険が危ないからどうたら、という話ではなく

このIVの再利用の話を挙げてSSHで使用する暗号方式からAES-GCMを外している人が居たので、実際に危険だと誤解している人はいるようですよ。

> 登場早々、なにやら早速ケチがつき始めているようなので、

これが誤解だという話をしています。
問題の本質は「TLS 1.2の特定の実装でIVを再利用する場合がある」という事で、
AES-GCMの安全性に問題が見つかったという話ではないので。

> 一気にchacha20-poly1305@openssh.com行こうずって人が多いだけの話だろ

chacha20-poly1305はこの話には関係ないのですが。
AES-GCMよりchacha20-poly1305を優先して使おうというのならば特に問題はありませんが、
誤解が元でAES-GCMを使わないように設定して、その結果、より劣る方式を使ってしまうのは
本末転倒なので避けた方がいいよという事で書いています。
# EtMなMACが使えるのならば AES-CTR + EtM MAC というのもいい選択肢だとは思います

> TeraTermがChaCha20未対応で、未だ有志パッチすら存在しないからといって

Tera Termでは次のバージョンでchacha20-poly1305をサポートする予定ですが、
たとえ現時点でサポートしていてもこの話は書いていました。
せっかく安定した複数の方式があるのに、誤解が原因で選択肢を狭めるのは問題だと思いますので。

13479416 journal
日記

dodaの日記: SSH での AES-GCM の利用 2

日記 by doda

一つ前の日記で、SSH 接続での AES-GCM の利用を勧めましたが、一部では AES-GCM は危険だと誤解している人がいるみたいなので、
少なくとも SSH での AES-GCM の利用は安全だという事を書いてみようと思います。

AES-GCM が危険だという誤解は、どうも『本当は怖いAES-GCMの話』というページの影響を受けているように思います。
この『本当は怖いAES-GCMの話』に書かれている内容自体には問題は有りません。
# タイトルが AES-GCM 全般が危険なように思わせる物になっているのは気に入りませんが
しかし、『本当は怖いAES-GCMの話』は殆どが TLS 1.2 での AES-GCM の利用について書かれており、
AES-GCM 全般、特に SSH での AES-GCM にはそのまま当て嵌められません。

13479277 journal
ソフトウェア

dodaの日記: Tera Term 4.97 2

日記 by doda

既に2週間前ですが、Tera Term 4.97 をリリースしました。
全ての変更点はリリースページの変更履歴をみてください。

今回の変更内容の内、お気に入りの物として以下が有ります。

13467410 comment

dodaのコメント: Re:次は何を探して欲しい? (スコア 3, 興味深い) 53

朝雲も見つかったらしいですね。
https://www.facebook.com/rvpetrel/photos/a.1513624485339694.1073741830.1510752248960251/1526752557360220/?type=3

最上が自沈処分になったのは離れた場所なんでしたっけ?

13003207 journal
ソフトウェア

dodaの日記: Chocolatey のパッケージ 2

日記 by doda

Windows 用のパッケージ管理システムとして Chocolatey という物があります。
この Chocolatey に誰かが Tera Term のパッケージを登録していたのですが、2 年前のバージョンのまま更新が行われていませんでした。
この状態はあまり望ましくないので、最新版に更新してみました。
https://chocolatey.org/packages/teraterm/

使い方ですが、Chocolatey 自体のインストール方法は省略します。
使った事がない人は https://chocolatey.org/install を見たり、"chocolatey インストール" で検索したりしてインストールして下さい。

12851664 comment

dodaのコメント: Re:新Poderosaはオープンソースではなく有償のソフトウェアですが、 (スコア 1) 87

なんか事実誤認や誤った意訳とかが酷いなあ。

cygwin連携が素晴らしく、将来性も期待してGuevaraを買ったら、

Guevara は無償です。有償でライセンスがあったのは VaraTerm ですね。
続く記述を見ても、認識が1世代ずれているようです。

VaraTermのやり取りをみていたら、
途中 でcygwin連携が無くされ、 それに物言いを付けた人に

cygwin対応が廃止された事は有りません。
SFU対応が廃止された事とごっちゃになっていませんか?
以下はそうだと仮定して、

「俺がVaraTermだ!

そんな事言ってないようですが。

文句あるならフォークすれば?」(意訳)

これもかなり違いますね。
作者は、「利用者がいない」とか「不安定」だとか「残すにしてもサポートコストがかかる」などの
廃止する理由を挙げて、その上で、オープンソースなのだから自分で開発する事もできるよ、
その場合は自分もサポートするよと言ってます。おそらくちゃんと開発してパッチが送られれば
取り込まれていたんじゃないかと思います。
決して「文句があるならばフォークすれば?(自分はそれに関わらないけれど)」なんて事は言ってないです。

とか、未踏 ?なんで?バカンス?なんで?とか、

未踏に応募/採択された事がおかしいですか?
未踏で採択されたのには他にも有名どころで ruby とか GRUB2 とか色々ありますが、これらもおかしいのでしょうか?

12851564 comment

dodaのコメント: Re:既存のPuttyとかTeratermで十分だと思うのだけど (スコア 1) 87

別にタブ化されてなくてもキーボードショートカットでの切り替えは(プログラムが対応していれば)出来ると思いますが。
例えば Tera Term ならば Window メニューからウィンドウの切り替えが行えますし、デフォルトではされていませんが設定次第でショートカットへ割り当てる事も出来ます。
また、Control-Tab で Tera Term のウィンドウ間での切り替えも行えます。

12851560 comment

dodaのコメント: Re:既存のPuttyとかTeratermで十分だと思うのだけど (スコア 1) 87

タブにも向き不向きがあって、なんでもかんでもタブ化すればいいってもんじゃないと思います。
自分は以下の理由から端末エミュレータはタブ化に向いていないと思っています。

  • 複数の端末の内容を見比べたり、片方の端末の表示を見ながら別の端末に入力したりする事がよくある。
  • 画面分割は端末サイズが変わるので、分割した時に表示が欠けたり崩れたりする。
12851548 comment

dodaのコメント: Re:元に戻った? (スコア 1) 87

Guevara は無償でしたね。商用化(有償化)したのはVaraTermになった時です。
あと開発者が独立(退職)したのはVaraTermになった時のはずです。VaraTermへの移行の案内メールでその事が書かれています。

12851328 comment

dodaのコメント: Re:そのPoderosaが放置だったので (スコア 1) 87

PoderosaはPutty形式の秘密鍵には対応していないのでそのせいとか?
その場合はOpenSSH形式に変換すれば使えたはずです。

Poderosa のネイティブの秘密鍵の形式はSECSH形式(ssh.com形式)です。
Poderosa 4.1ではSECSH形式の秘密鍵しか使えません。

Poderosa 4.3系のどこかのバージョンでOpenSSH形式の秘密鍵への対応が追加されましたが、同時にPuTTY形式への対応も追加されたはずです。

12851324 comment

dodaのコメント: Re:そのPoderosaが放置だったので (スコア 1) 87

何の環境だったかな……Poderosaだと接続に失敗したんだけど

思いつく原因は幾つかありますね。

まず一つ目は“共通鍵暗号(通信経路の暗号化)方式としてCTRモードのAESに対応していない”というもの。
まず背景として、8年前に“CBC モードのブロック暗号で脆弱性が発見”されました。
この問題を受けて CBC モードの暗号をデフォルトでは無効にする事が一部の Linux Distribution 等で独自に行われたようです。
この時は OpenSSH 公式の配布物では行われなかったのですが、2013/10 に出た OpenSSH 6.7 でサーバのデフォルト設定では CBC モードの暗号が無効になりました。
そのようなサーバに対しては Poderosa 4.1.0 では接続出来ませんでした。
それに対して、2008/12 に AES-CTR に対応した非公式パッチ版が出て、2010/12 の Poderosa 4.3.0b に取り込まれたので、これらのバージョンを使っていれば問題ありませんでした。
初期に CBC モードの暗号が無効かされたのが一部のサーバだけ & OpenSSH のデフォルトで無効化されたのがかなり遅かった事、またそれまでに対策版が出ていた事から
この問題に引っかかっていた人はそれ程多くない印象です。

次の問題として“鍵交換方式として diffie-hellman-group1-sha1 にしか対応していない”というのがあります。
OpenSSH 6.7 では主にサーバ側でデフォルトで有効にする暗号関連の方式が見直され、比較的安全でない方式が無効化されました。
その無効化された方式の中に diffie-hellman-group1-sha1 鍵交換が有ります。
Poderosa では鍵交換方式として diffie-hellman-group1-sha1 にしか対応していなかったので、 デフォルト設定の OpenSSH 6.7 以降のサーバに接続出来ませんでした。
これに対して、2015/05 の Poderosa 4.3.13b で diffie-hellman-group14-sha1 への対応が追加されました。
ただ、OpenSSH 6.7 以降が結構普及した後だったので、この問題に引っかかった人は結構いるように思います。

最後に思いつく問題は“サーバ側が Dropbear の時に接続出来ない”という物です。
この問題はまだ原因が追いきれていないので、少なくとも Poderosa 4.3 系では今も接続出来ないはずです。
ただ Dropbear 自体があまり使われていないので、この問題に引っかかる人はあまりいないと思います。

# 時系列を書いてるのは、開発が止まっていたという認識の人が多いけれど、実際には(ゆっくりだけど)開発が進んでいたんだよというアピールだったり

typodupeerror

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

読み込み中...