マジでジグソーパズル解くだけで終わった1日だった

このアカウントは、notestockで公開設定になっていません。

スマートな奴は3回まわってツーと鳴く

OMOTENASHIの異常回転は液体推進剤のリークが原因か？ JAXAが調査結果を報告 (1) | TECH+（テックプラス） https://news.mynavi.jp/techplus/article/20221226-2547320/

2023年早々「雑診断で満点取って『こんなん余裕やん』などと URL を拡散する人類」を見てしまったので、今年一年も人間やっていきましょう

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

本名不明で会ったことのない人の (ハンドルネームによって作成された) OpenPGP 鍵、ちと悩んだが結局署名しない方に傾いている。後から本名とかに変更された場合に「ハンドルネームや諸々のサーバの真正な持ち主」として認知していたのか「該当の実名の真正な持ち主」として認知していたのか識別できなくなるので。

とはいえこれって signing party しても同じことじゃない？ という疑念はあって、実際に会って署名した相手が名前を悪意ある形で変更することはありえるんでないのと

結局のところ本当に紐付けたいのはメールアドレスやアカウントではなくアイデンティティそのものなわけだから、どこまで違いがあるだろうかと。
実際に会うのだって、古くからの知り合いでなければなりすましに騙される可能性はあるわけで、その点では signing party も同じステージでより安全という程度の話でしかない。別格の安全にはなっていない

ちょっと基本に立ち返って考えるべきかなぁ (まあ迷いがあるなら安全側に倒すが)

「パーティーの場で会った実在の誰か」と「事前に認知していた何らかのアカウントの持ち主」が一致していることをその場で確信できるのが本質なわけで、その「実在の誰か」はその後再検証可能になる、というところが重要なんだよな？

一方で、会ったことない人と安全とは限らないチャネルで交換した鍵には、なりすましや MITM のリスクがあると。

なりすまし攻撃者が実際に会った後でなりすまし続けるためには、なりすましオンラインアカウントを継続的に運用する必要があるんだけど、それって普通に可能なんだよな。
だからこそ「公開鍵を様々な経路で露出しろ」という原則が必要になるわけだけど。

PGP が想定する「本人」という概念が実在の物理的人物のみを指す概念なのか、それとも「何らかの排他的な権限やリソースを (本人の意志によって？) 奪われることなく安定して持てる行動者」を指しても良いのか、その辺りが疑問の本質か

https://mastodon.cardina1.red/@lo48576/109617177177903801

全く文脈と関係ない話だけど、 アーカイブの圧縮率が一定以下である (高効率過ぎない) ことの要請って、 zip 爆弾の阻止以外にも「最初から十分高密度なデータがアーカイブされていることを要請する」という意図にもなるので面白いなと思う。
たとえば jpg とか png とかって、 jpegoptim や oxipng 等で圧縮を最適化すると、情報やメタデータの欠落なしで半分とかまでサイズが落ちたりするので、そういう行動にインセンティブを与えることができるかもしれない

もちろんテキストは原理的にスカスカになりがちなのでソースコード系には適用できないし、あるいは zip 内 zip みたいなバッドプラクティスを拒否するようなデザインも必要になるけど

沼研の伝説的なエピソード:沼正作(1929-92) - 日本の科学と技術
http://scienceandtechnology.jp/archives/9655

なんとまぁ……

Rust はかなり最高な言語ですが、それをどこまで活用できるかは、最高でない言語がどう最高でないかを理解できているかどうか次第な面は多少ある

C++ の地雷原でタップダンスをすることに慣れている人なら、 Rust 使ったらもう戻れなくなりますよ

4294967296回 arp 投げて

ループバックのアドレス範囲を除いてもいい (焼け石に水)

OpenPGP の電子署名は「ユーザーの身元を保証し」ない | text.Baldanders.info
https://text.baldanders.info/openpgp/web-of-trust/

ふーむ

context: https://mastodon.cardina1.red/@lo48576/109617102969454564

What is not WoT? (In Japanese: WoT とはなんでないか)
https://www.gniibe.org/memo/software/gpg/what-is-not-wot.html

鍵の有効性の文脈での「人」とはなんだ？

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

ダムハブ見たことない (まあ見た目が同じだけで見たことあった可能性もあるけど)

10年弱前あたりの時点で、既に8ポートのスイッチングハブが高校生のお小遣いで躊躇なく買える程度のお値段だったはず

ちゃんと調べてないけど、その頃すでに結線自動判別みたいなのは当たり前になってたのではと思うし、そういう機能がついてたらもうだいたいスイッチしかないのではという偏見がある (しらんけど)

イーサネットかけて、 git と解く。その心は？

想定解ではない

想定解ではないが、これでも正解っぽいな。作問失敗だ

ニンテンドー ダム
#適当

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

Buffalo とか NEC とかで散々な目に遭っていたので、あれでも十分崇められるレベル

スイッチ2つ持ってるけど設定を別々でやるのはダルい (でもサブスク加入したくはない)

あれ必須だったのか

クロスケーブルの方が安く売ってたからクロス買ってハブにつなぐなどしていた

㍂、物理層の知識仕入れるべきか……

根本的なセキュリティ強化をしたがらない人、「ここまですれば大丈夫やろ」という程度問題としてしか問題を評価できていない傾向があるように思う。「100%なんてない」を考えなしにあらゆる事柄に適用するせいで原理的な安全という概念を認知できなくなってるのかね

「100%なんてない」自体は100%適用可能だと信じているわけだ

お得情報ですが、大学によっては学内ネットから IEEE の論文無料で読めるプラン加入してることがあって、その場合 IEEE754 は読める可能性がある (オタク大は読めた)

2008ならﾀﾞｳﾝﾖｯﾖしたんだけど、2020だかその辺のやつは間に合わなかったんだよな……

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

実家から踏み台サーバ経由で自宅マシンを WoL 起動することを考えたが、 LUKS で full disk encryption してるのでそういえば無理だったわ。起動したらリモートでは落とせなくなるので試す前に気付けてよかった

このアカウントは、notestockで公開設定になっていません。

PGP Key Signing - Phil's PGP Docs
https://www.phildev.net/pgp/gpgsigning.html

encryption - GnuPG/KGpg Sign PGP Key - Sign User ID : What is the difference? - Information Security Stack Exchange
https://security.stackexchange.com/a/40630

なるほど、他人の公開鍵への署名は鍵そのものというより「UID への署名」が最小単位だから、 UID を変更すると他人による署名が無効になって「後から名前を変更してなりすまし」みたいな問題は発生しないのか

理解した

このアカウントは、notestockで公開設定になっていません。

メジャージャンルのおこぼれトラフィックこそが大きな価値、言われてみると確かにそうなんだろうな。考えたことなかったわ

「こそが」とまでは言ってないだろうけど、私がわざわざ書店に行ってひととおり棚を舐めるのと同じで、目的のエリアの近くとか通り道で目に付くというのはかなり大事な機会なんだろう。納得感はある

https://mastodon.cardina1.red/@lo48576/109617102969454564

これに対する回答としては

「(推奨はしないが) ハンドルネームな UID であっても、本当にそれを名乗る当人の鍵であると確信できる/確認したのなら署名しても問題はない」

ということになりますね。理解しました

「本当にそれを名乗る当人の鍵であると確認する」を本人に会わず行うことにどの程度の信頼性があるのか、というのはまた少し別の議論になるし、保守的な価値観ではそのような真似は認めないわけですが。まあ実際私もその方が良いだろうとは思う

ｲﾝﾀﾈｯﾂのみによって “本人のものと確認した” 場合、 validity は none として設定すべきでしょうね。たぶん。
で、そもそもそのような「ｲﾝﾀﾈｯﾂのみによって “本人のものと確認” してしまうようなユーザ」は、他の人々からは trust level を none として登録されそうだけど、それはまた別の話 (つまり、モデルがそのような運用に対応しているかと、その運用が望ましいものかは、別の話)

正確度と信用の輪について理解する
https://linuxjf.osdn.jp/JFdocs/mutt-gnupg-howto/understand-validity.html

実際のところ、現代においては E2E 暗号化の恩恵で「改ざんされている」可能性はかなり排除しやすくなった (とはいえ完全ではない) が、ｲﾝﾀﾈｯﾂのアカウントは「想定していた本人がその瞬間にアカウントを利用している」ことの確信を得ることが極めて困難なんだよね。なので本人確認のブートストラップには使えない

たとえば Mastodon にしてみても、サーバ間で暗号化通信してみたところでサーバ上のデータは平文だから、 VPS などであればサーバ上のマルウェアや攻撃者がデータベースを覗き見したり割り込んで書き換えたりしているリスクは排除できない。攻撃者にメリットや動機があるかは問題ではない。

Keybase や Keyoxide はこの辺りをどうやって解決しているのか。「秘密鍵の所有」を起点とする信頼の伝播で十分ということなのかな？

「登録した瞬間のアカウント操作者」と「秘密鍵の所有者」の対応は “確認できた” として良いと思うのだが、署名は UID に対して行うものであると考えるなら、本来はメールアドレスとの確認は真っ先に取れないといけない気がするし、署名するには確認が足りてない気もする

このアカウントは、notestockで公開設定になっていません。

アイデンティティにダックタイピングは草

このアカウントは、notestockで公開設定になっていません。

https://mstdn.maud.io/@unarist/109619381427804790

言われてみるとその点べつに email account でも事情は変わらんよな…… 単に UID は名義に過ぎないと考えるべきか

ちなみに Tails OS に入ってる鍵 A490D0F4D311A4153E2BB7CADBB802B258ACD84F が結構面白くて、同じメールアドレスに対して

* Tails developers (offline long-term identity key) <tails@boum.org>
* Tails developers <tails@boum.org>

の2つの UID が同時に存在している

Tails - Transition to a new OpenPGP signing key
https://tails.boum.org/news/signing_key_transition/

このアカウントは、notestockで公開設定になっていません。

https://twitter.com/DockerCon/status/666188361456091136

おすすめ素材です

このアカウントは、notestockで公開設定になっていません。

アイデンティティとは何なのか、というモデルが email 一強時代の世界観をベースに作られていそうなので、 SNS アカウント等の話をするときはちゃんと考えないといけなそう。しらんけど。

主に email は「クライアント側で一度受信したら、 (クライアントにマルウェアがない前提では) 改ざんは発生しない」というのがいい感じの特性で、後発の SNS にはこの特性がないのが特徴かもしれない。たとえば Mastodon はサーバへの侵入で過去に発信・受信した投稿が改ざんされかねない。

もっとも、 matrix など例外もありそうだけど (サーバサイドの履歴に依存せず E2E 通信ができる、はず……？)

本人であるとは何なんでしょうね

このアカウントは、notestockで公開設定になっていません。

https://mstdn.maud.io/@unarist/109619473675029318

アイデンティユーでしょ

このアカウントは、notestockで公開設定になっていません。

突然のギリシャ文字に混乱した (???)

このアカウントは、notestockで公開設定になっていません。

個人的に考える「同一人物である」とは、振る舞いの等価性や互換性よりは「過去から蓄積してきた信頼・信用をいま引き出して適用するかどうか」あたりが本質だと思いますね

あるアカウントでほぼ同じように振る舞う「新しい “中の人”」が現れたとき、過去の “中の人” の言動への信用をそのまま移行して良い文脈では同一存在であると看做し、そうでない文脈では別存在と看做す。
典型的には「企業としての信用か担当者個人に対しての信用か」などによってこれら2つは性質が変わるけど

複数人で (分割された鍵などによって) 管理している秘密鍵への信用は、その構成員ではなく組織としての体制やポリシーに対しての信用を使うすることが多くて、それを正当化するのは「過去に組織が積み上げてきた言動を現時点での組織の信用度評価に使っても良い」という判定であると説明できる

「過去にちんこの写真を上げなそうだった、だから今後もちんこの写真は上げないだろう」と言えるならおkで、そうでないならどれだけ下ネタのセンスが似ていようがアウト (???)

まあでも私の考える本質はマジでこれですね

存在の連続性の仮定と呼ぶならそうかもしれない

このアカウントは、notestockで公開設定になっていません。

画像は加工・改竄されているかもしれないので実物を確認することが強く推奨されますが、大丈夫ですか？ (???)

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

本人に会って物理的に確認することの重要性だ (????)

このアカウントは、notestockで公開設定になっていません。

陰茎、何とは言わないけどバッファとして機能しているので実際フラッシュせず取り外すと大変なことになりそう (?)

取り外せなくてもいいからフラッシュさせてほしいが？

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

入れ替えに限らないが、内心を描写するには読者が理解できる意識構造をしていることは不可欠であり、結果として人間や互換な生物としか意識は入れ替われない

内心を描写しないなら任意の入れ替えや狂人あるいはそれに準ずるものの描写ができるが、それはもはや神の視点からの観察日記になってしまうのでジャンルがね

このアカウントは、notestockで公開設定になっていません。

裁判所に駆け込むしかないやつだ (?)

このアカウントは、notestockで公開設定になっていません。

OpenPGP に詳しい人に聞きたいんですが、 primary key に expiration date を設定した状態で他人から certificate (鍵への署名) を貰ったとして、その certificate 自体が自分の primary key の expiration date と同時に失効するよう作成されていた場合って、 primary key の expiration date 変更は certificate の expiration date に影響を与えますか？

与えそうにない (独立している) 気はするんだけど、それだと primary key の expiration date を短期間に設定して定期更新している人に対する certificate は素早く失効してしまうので、 Web of Trust を作る目的であまり機能しなくなってしまうのでは？ という疑問があります

[2023-01-02 21:58 訂正]: 与えそうな→与えそうにない

特に、ベストプラクティスとして「primary key に expiration date が設定されている場合、それと同時に鍵への署名も失効するようにしましょう」と「鍵サーバにゴミが永遠に残らないよう、 primary key にも expiration date を設定しましょう」の両方があるようなので、それって両立するものなのか？ という疑問が……

+11℃ を C++11 に空目した、末期

蛮殻コーデ

USB 警察です！！！

このアカウントは、notestockで公開設定になっていません。

How does PGP web of trust handle certificate expiration? - Information Security Stack Exchange
https://security.stackexchange.com/questions/219027/how-does-pgp-web-of-trust-handle-certificate-expiration

情報ないな……

まずググっても key が expire する話ばかり出てきてノイズが多すぎる。次点で HTTPS の証明書の期限切れの話が多い ("pgp" つってんだろうが！)

OpenPGP Web of Trust
https://sequoia-pgp.gitlab.io/sequoia-wot/

> Internet-Draft: draft-nhw-web-of-trust-00
> Published: 3 February 2022
> Intended Status: Informational
> Expires: 7 August 2022

うーん、 draft だし expire しているうえ欲しい情報ではなかった

https://mastodon.cardina1.red/@lo48576/109619721402927767

「certify するときは対象の鍵の primary key の expiration date と同じ日付を設定しよう」というのがあまりに過激ポリシーすぎる気がしてきた。毎年 signing party に参加しまくる前提なのか？

しかしそういうパーティ出まくりの強者が書いた †ベストプラクティス† に追従して certificate の期限を1年とか2年にされると困るのはこっちだし、かといって作業者は私ではないんだよな。どうすりゃいいんだ

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。