「AES」を含む日記 RSS

はてなキーワード: AESとは

2023-03-09

資格バカにするおじさんエンジニア

ITエンジニア業界では資格をとってもなんの意味もないとよく言われる。

あるITエンジニア(インフラバックエンド系)おじさんもその原理主義者のような人でIT系の資格取得をバカにしていた。そんな暇があったら個人開発の一つでもすればいい。資格を持ってるなんてむしろバカアピールすることだという言いようだった。

しかしある時、おじさんと会話しているとSSOシングルサインオン)を知らなかった。またある時は、AES共通鍵暗号の規格だということを知らなかった。どれもAPベンダー資格勉強をしてればよく目にするもののはずだ。

資格はそれ単体では意味がないというだけで、実践資格の両輪で役に立つんだというならわかるけれど。

資格自体バカにするおじさんはその程度なんだなと思った。

2022-09-10

タグ使わないAES GCMってなんか違くねとか

2021-09-14

anond:20210914162445

出来ないよ

量子何とかで解読できるのはRSA暗号だけでAESは無理

anond:20210914141313

AES復元できる鍵が必要、それは理解できる。その鍵をハッシュ化すると、その鍵は「復元できない」何かに置き換わっているので、つまり鍵は失われていて、必要とき復元できない、と思うのだけど。ちゃんと、それは復元できるのか、確認したほうがええよ。

anond:20210914022610

ちょ、SHA は非可逆だから暗号化にないってば。たぶん、AES とかと勘違いしてると思うし、暗号化の再検査なされ。マジで SHA 使っていたら、バックアップになってないyo.

2020-12-06

https://b.hatena.ne.jp/entry/4695196584599683234/comment/knok

PPAPなんてアホやってる奴がAES暗号化使ってるわけねえだろ

Windowsで展開できないのに標準なわけねえだろ

クッソ狭い見識の世界で生きてるこういういっちょ噛みがクソな現状を助長する

消えろ

2020-11-18

Pマークが何故批判されているのか分から

パスワード付きzipメール添付の件。

Pマーク(or ISMS)が批判されているが、皆どんなチェックがされるのか知ってるの? 内容を知らないのでイマイチ批判の波に乗れないんだよね。自分検索能力が低いだけかも知れないけど、公開されていないようで文書が見つからず真偽を確かめられないし。

なので、ここから先は自分の推測。間違っていたら指摘して欲しい。

PマークISMS認定では「パスワード付きzipしろ」と明言されているわけではなく、「メールファイルを送るなら暗号化しなさい」くらいの話だと想像している。

もちろん、「パスワード付きzipで送付します!」に対してダメと言わないPマークが悪いとも言えるが、以下が担保されればセキュリティとしては問題ないように思う。

審査がザルなんだろうとは思うけど、受ける側が嘘ついてたらどうしようもないし、PPAPが手間が掛かる/非効率である点はPマーク側がどうこう言う話ではない(本当はコスト考慮した上でのセキュリティであって欲しいけどね)。

あと、別ソリューションとしてよく挙げられる外部ストレージサービス活用について、Pマーク側が禁止しているわけじゃないよね? 禁止していないなら、それを採用しないお宅が悪いのであってPマーク批判するのはお門違いなのでは?と思っている。

とりとめもなく書いたが、思っていたことをぶち撒けられてスッキリした。

じゃあな。

2020-02-18

新型肺炎消毒(SARS)に洗剤有効 国立感染研が実験

http://www.med.oita-u.ac.jp/infectnet/SARS/SARS_report_00567.html

 効果確認されているのは、食器野菜洗浄用の製品で、成分として直鎖アルキルベンゼンスルホン酸ナトリウム、またはアルキルエーテル硫酸エステルナトリウムを16%以上含むものだという。

 従来のエチルアルコールに加え、台所洗剤の使用を推奨しているのは、臨床的にSARSが疑われるか、あるいはSARSであることが確認された患者が発生した場合患者の部屋などに対して行う消毒処置台所用の合成洗剤を1lのぬるま湯に対して5〜10ml以上加えて用いる。使用するときには、手袋、手術用以上の性能のマスク、ゴーグルガウンなどを着用し、窓を開け放って可能な限り日光が届くようにする。その上で、消毒剤が十分長時間残留するように、清拭することを勧めている。消毒剤を噴霧するとウイルスなどを空気中に舞い上がらせる危険性があるため、拭き取りに限る。体液などが付着した部分には、ティッシュペーパーなどに消毒剤を染み込ませ、5分間以上経過してからから拭きする。

https://medical.nikkeibp.co.jp/inc/all/hotnews/archives/279202.html


直鎖アルキルベンゼンスルホン酸ナトリウムは、LAS

アルキルエーテル硫酸ナトリウムは、AES

と呼ばれる。

ママレモン

除菌JOY

チャーミー マジカ 除菌+、

SARAYA ヤシノミ洗剤

辺りが当該商品に相当するので、消毒液が買えなかった人はどうぞ。


なお、私は洗剤メーカー人間ではありません。

2018-07-05

swift暗号化zipを作りたいだけなのに

なんで作る仕組みがないんだよ。

zlibやCommonCryptoはswift用のライブラリがないので、裏技的やり方でObjective-Cライブラリを引っ張ってこないといけない。

しかもそんな面倒は序の口で、本当に面倒なのはそこから

zlibは何をどうやってもgzipしか作れないし、作ったgzipをCommonCryptoのAES暗号化したら、今度はどうやっても解凍できないし。

あとzlibによる圧縮で、圧縮前の拡張子を覚えさせる手段が見つからなかったので、ファイル名に圧縮前の拡張子を含めさせておかないと、解凍後に手動で拡張子を追加しないといけない。

そりゃ、APIドキュメントをくまなく読み込めば全て解決するんだろうけど、そんなコストは掛けられない。

要するに並のプログラマの手には負えなさそうな話という結論


からなのか、ググってみると9割方SSZipArchive使えって記事が引っかかる。

あのさ、そういう目的特化で作られているんだから、使えば一瞬で目的達成できるのは分かるよ?

そこじゃないんだ。そしたらプラグインみたく必要ライブラリを入れまくって解決した気になるのは違うと思うし、それが無理なケースもあるんだよ。

そもそもの疑問として、タイトルに有る通り「暗号化zipを作りたいだけなのに」なんで最初から仕組みが用意されてないんだ。


あれか、Apple的にはswift暗号化zipを作る時代じゃないと、そういう見解なのだろうか。

2018-02-15

電子通貨は国が管理すれば問題がない。例を示そう。

基本的仕様

プライバシー

セキュリティ


子供

予算

他の政策

教育

メリット



データ形式

{
	'transaction':[
		'key':'some_token_like_SHA-2',
		'descriiption': 'bar',
		'from_wallet': 1234567890,
		'to_wallet': 0987654321,
		'total_amount': 9999999999999,
		'tax_amount': 999999999999,
		'timestamp': yyyymmddhhmmss
	]
}

ブロックチェーン、電子通貨は国がやるメリットが大きい。さよなら仮想通貨

2016-10-17

How the Textsecure Protocol (Signal, WhatsApp, Facebook, Allo) Works

http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html これエキサイト翻訳か?主語が全部theyという支離滅裂英語なんだが。

----

TextSecureの目標は「経路末端までのセキュリティ否認性、前方秘匿性、将来の秘匿性のすべて」を提供することである。具体的には、可能な限り短い時間だけ鍵情報を保持するメッセージストリームを二者の間に構築するということを目指す。将来に鍵の危殆化があっても、現在観測されたトラフィックを復号化できなくするのだ。

以下にSignal Protocolの批評分析を羅列してある。実装構造研究し、発見した欠陥を記述し、上述の目標がどれほど実現されているか評価するものである。まず仕組みの説明をしてから、より詳細な分析を続けることにする。

用語

TextSecureは、今ではSignalと呼ばれているアプリに与えられた名の一つだ。コード文書も一貫してTextSecureという名を使っている。一貫性を保つため、システム全体をTextSecureと呼ぶことにする。

ただ実際には数々の異なるものが含まれている:

構造

TextSecureは、非同期整合性に焦点を当ててOff-The-Recordというチャットプロトコルを改造したものだ。OTRが対話ハンドシェイク必要とする一方、TextSecureは不確定な遅延を認めない。メッセージを送れるようになるまでアプリを表示したままにしてハンドシェイク遂行しなければならないというのであれば、ユーザ体験はひどいことになる。

そうではなく、通常の鍵交換においてサーバが果たす役割の部分だけ、将来のクライアントが取得しに来るよう中央サーバに格納される。このサーバは、すべてを復号化できる鍵情報は預けておかない、信用なし経路となる。すべての暗号化は末端どうしだ。

暗号

TextSecureは暗号学の基礎のほんの一部を使うものである公開鍵暗号は楕円Diffie-Hellmanを通し、Curve25519を用いて実行される。AESがパディングなしカウンター(CTR)モードサイファーブロックチェーン(CBC)モードの双方で対称暗号に使われる。HMAC-SHA256がメッセージ認証に使われる。これらが信頼の基礎(TCB)である

ダブルラチェット:

TextSecureの暗号化エンジン中心部はAxolotlダブルラチェットアルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。

受信ラチェットメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化メッセージ認証に使う対称鍵の生成に用いられる。

送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。

ここで注目すべきは、メッセージ送信するために送信者が待つ必要は一切ないということだ。いつでも送信第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイスのものであっても、過去送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)

プロトコル

フェーズ1: TextSecure登録

登録は、クライアントに言って、連絡用の電話番号サーバに教えてもらうことから始まる。また同時に、トークン通話SMSどちらで受け取りたいか希望登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報登録できるようにしてくれる。

クライアントメッセージ認証暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。

また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。

他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。

クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントSMSを受け取りたいかデータだけにしたいか情報も含まれる。

フェーズ2: 鍵の比較

TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリント比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。

フェーズ3.1: 最初メッセージ送信

送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報ルート鍵と呼ぶ。

このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化MACの鍵を生成するのに使われる。

最後AESカウンター初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターメッセージ送信ごとに増える一方で、pctrカウンターは、最後既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。

これらを使って相手メッセージ暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイク完了できるだけの必要情報が含められている。

SignalサーバGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージ送信元を知らずにいることが保障される。

フェーズ3.2: メッセージ受信

信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイク完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。

フェーズ4: 追伸メッセージ送信

相手が返信する前に、もとの送信から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。

フェーズ5: 返信の送信

信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化認証の鍵を得る。これを使ってメッセージ暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。

既知の問題

鍵の提出

TextSecureは、サーバクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロード認証する。これは送信メッセージ認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージ送信も鍵アップもそのユーザなりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップデバイスSDカードに置かれていたので、他のアプリから読むことができたのだ。

この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティ問題ではなく、現実問題であり、それに対する後ろ向きな対策なのである

未知の鍵共有 (UKS) 攻撃

この攻撃は偽配送一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃から別の人(標的)へのメッセージとして送信される。

これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分公開鍵を、標的の公開鍵に変えればいい。これは自分電話番号を再登録すればできる。送信者はQRコードを使って、相手フィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである

それから、今度は送信者のアカウントを再登録して、その検証SMS確認通話送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージ送信できるようになる。

この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。

できることがあるとすれば、送信者と受信者の双方がメッセージ暗号化された本文内で言及されるようにすることなどだ。

目標達成率

TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破限定的時間範囲しか有効でないとする。新しいラチェットのそれぞれに公開鍵必要であることから、これは達成されている。

完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイスにのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットステート対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェット使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージ暴露である

否認性(アリバイ)はさらあやふやだ。ある特定メッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバ認証メッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。

Sources

Analysis Whitepaper:

http://ieeexplore.ieee.org/document/7467371/

Marlinspike, Moxie (30 March 2016). "Signal on the outside, Signal on the inside". Open Whisper Systems. Retrieved 31 March 2016. https://whispersystems.org/blog/signal-inside-and-out/

Posted by Alexander Kyte at 11:47 PM

2016-07-24

http://anond.hatelabo.jp/20160724075916

AESファイル暗号化している限り、firestorage等ファイルアップロードサービス使っても別に問題無いだろ。

だいたいインターネットを介してファイルをやり取りする限り、

ファイルデータは必ず第三者保有するルーター機器の中を通過するんだぜ?

ルータに何か仕掛けられていたら、見放題なわけ。

そういう電子盗聴からデータを守るために、SSLで暗号化するわけだけど、

暗号化の強度は、AESファイル暗号化しても大差ないよ。

2016-01-09

翻訳vvvウィルス(TeslaCrypt)の削除と復旧手順

原文:https://community.spiceworks.com/how_to/125475-teslacrypt-2-2-0-removal-and-decryption

原題:TeslaCrypt 2.2.0 Removal and Decryption

原著者:Isaac Rush's (hewhowearsascarf) Portfolio of IT Projects - Spiceworks 氏 (Thank you for your contribution! This article is a translation of your post.)

翻訳日:2016年1月9日

はじめに

私たちワークステーションのうちの一つがTeslacryptランサムウェア感染しました。すべての文書暗号化され、拡張子vvvに変えられました。マルウェア感染のにおいて最も安全回復方法コンピューターワイプしてバックアップから復元させることです。しかし、それは場合によっては選択肢にならないことがあります私たち場合ユーザローカルコンピュータに何のバックアップもとっていませんでした。それで、私たちランサムウェアを取り除く方法ファイルを復号する方法確認する必要がありました。復号を達成させてくれたPythonスクリプトの作者であるGoogulatorに大きな感謝を送りますhttps://github.com/Googulator/TeslaCrack

そこに書いてある説明に従うといいです。引用していくつか説明を付けたものを以下に用意しました。元の記事にはたくさんの指示が書いてありますが、私たちが行った手順は以下の通りです。

手順(全25ステップ)

1. コンピュータからTeslaCryptランサムウェアを取り除く

セーフモード再起動し、Malwarebytes scanを走らせて、見つかったすべてのマルウェアを削除します。私は複数の信頼できるマルウェアクリーナーを使ってこれが消えたか確認することをお勧めします。必要だと言われたら再起動します。これでウィルスはきれいになったはずです。次はドキュメントを復号します。

2. この説明を見よう: https://github.com/Googulator/TeslaCrack.

私たちPythonスクリプトを使って、AES公開鍵特定して、その数値を因数分解して、それから秘密鍵特定して、そしてファイルを一つ復号します。一度復号に成功したら、コンピュータすべてを対象に実行できます。できるなら、多く速く処理するために他のコンピューターを使ってください。

3. https://github.com/Googulator/TeslaCrack/archive/master.zipダウンロードして「C:\decrypt」に展開する
4. VVV暗号化されたドキュメントを一つ、このフォルダ「C:\decrypt」にコピーする
5. Python 2.7 64-bit release をダウンロードする。 https://www.python.org

インストール管理者権限で行ってください。また、インストール中の操作で、Pythonパスに追加するオプションを必ず選択すること。

6. 管理者権限コマンドプロンプトを開き、以下のコマンドを実行する:

python -c "import urllib2; print urllib2.urlopen('https://bootstrap.pypa.io/ez_setup.py').read()"; | python easy_install pip

pip install http://www.voidspace.org.uk/python/pycrypto-2.6.1/pycrypto-2.6.1-cp27-none-win_amd64.whl

pip install ecdsa

7. コマンドを実行する: python teslacrack.py .

私の実行結果は以下の通りです:

Cannot decrypt ./VENDOR LISTING BY CATAGORY.xlsx.vvv, unknown key

Software has encountered the following unknown AES keys, please crack them first using msieve: A1373BCF4EDB39BCFEDD44FA86A82498410A7E83456D8E80E52966F6717CB8B8E5846BBC7A540647AE770FEDEAA0E7F8A0466082156DB332A757407A12C9FB0 found in ./VENDOR LISTING BY CATAGORY.xlsx.vvv

Alternatively, you can crack the following Bitcoin key(s) using msieve, and use them with TeslaDecoder: 5ECA19D475A313AC3DEF915CE6FA37BE012CD1676590C8F253135A3AD92345B78C32C46DB3246ED84A7B9A8C62F1A13D2AF08F09FFB3551701E7B75CCC79457C found in ./VENDOR LISTING BY CATAGORY.xlsx.vvv

8. 最初の数値をクリップボードコピーする

私の場合は以下の値をコピーしました。 A1373BCF4EDB39BCFEDD484FA86A82498410A7E83456D8E80E52966F6717CB8B8E5846BBC7A540647AE770FEDEAA0E7F8A0466082156DB332A757407A12C9FB0

9. http://www.mobilefish.com/services/big_number/big_number.php に行って、16進数から10進数に変換する

さっきの数値はこのようになります: 8443554284208758706290725803426642738777516291375882082881197977752270634322152168104703798454983966849000112082164921264407639940139993317228747401502640

10. 因数分解のためにまず http://factordb.com/ で数値を入力する。

私の場合だと、8443554284208758706290725803426642738777516291375882082881197977752270634322152168104703798454983966849000112082164921264407639940139993317228747401502640 を入力して「Factorize!」を押してみました。もしあなたラッキーなら、画面の左端には「FF」と表示されるでしょう。これは完全に因数分解されていて、すべての因数がリストされていることを意味します。この場合あなたは以下のyafuを使う手順を行う必要はありません。unfactor.pyのところ(訳者注:手順19)までスキップできます

もし「CF」や「C」と表示された場合私たちはまず因数分解をするためにyafuを実行する必要があります因数分解ができたら、 factordb.com に戻ってその整数を下のほうにあるレポートフィールドからレポートしましょう。そうすることで、その数値が「FF」で表示されるようになります因数分解は数値の複雑さによって数時間・数日間・数週間かかります因数分解が終わったら、私たち秘密鍵を得るのに使用するたくさんの数値(因数)を得ていることでしょう。私はmsieve, yafuとこれらのバリエーションを試しました。これを動かすのは結構大変でした。いくつかの問題説明が不完全で、すべての構文を与えられていませんでした。しかし、ついに私はyafuを動かしました。私が何をしたか、以下に書きます

11. http://www.mersenneforum.org/showthread.php?t=20779 から「GGFNS.zip」をダウンロードし、「C:\ggnfs-bin」に展開する
12. http://sourceforge.net/projects/yafu/ から「yafu-x64」をダウンロードし、「C:\ggnfs-bin」に展開する
13. コマンドプロンプトを開き、「C:\ggnfs-bin」に行く
14. 「yafu-x64.exe "tune ()"」を実行する
15. 「yafu.ini」を編集する。「ggnfs_dir=../ggnfs-bin/」「ggnfs_dir=C:/ggnfs-bin/」へ変更し、保存して閉じる。
16. 「yafu-x64.exe "factor(あなた10進数の数値)" –v –threads 4」を実行する

例: yafu-x64.exe "factor(8443554284208758706290725803426642738777516291375882082881197977752270634322152168104703798454983966849000112082164921264407639940139993317228747401502640)" –v –threads 4

17. これはひどく時間がかかる部分です。終われば、「factor.log」に因数がリストされます。このファイルを開きます

因数分解を始めると、小さな因数は素早く見つかり、このようにリストされるでしょう : 「div: found prime factor = x」。ログファイルの中から「found prime factor」を検索します。

さらに「prp」も検索します。このような行が見つかるでしょう。: prp32 = 25647545727466257054833379561743

18. http://factordb.comあなたの数値を因数分解した結果をレポートする。 あなたがすべての因数をレポートしておけば、それは「FF」表示に変わる。あなたはすべての因数を知っている。
19. コマンドプロンプトで「C:\decrypt」に行く。
20. 「python unfactor-ecdsa.py 暗号化されたファイル名 前の手順で得た素数をスペースで区切ったもの」を実行する

すると、AES秘密鍵が出力されます

これが私の実行結果です:

unfactor-ecdsa.py VENDOR.xlsx.vvv 2 2 2 2 3 5 367 12757 25647545727466257054833379561743 75938537910569673895890812481364802067167 3858259146292441335085163995598583072203543699186432807503634945432314399

Found AES private key: b'\xbd\xa2\x54\x3a\x21\x75\xb9\xf3\x0d\xf6\xf3\x09\x60\xec\x08\x2f\x3e\xc5\xef\x61\xd4\x03\xa3\x5b\xc1\x47\x7e\x10\x47\x0a\x7c\x88' (BDA2543A2175B9F30DF6F30960EC082F3EC5EF61D403A35BC1477E10470A7C88)

21. 「teslacrack.py」 の 「known keys」にあなた公開鍵(訳者注:手順8の値)と秘密鍵(訳者注:手順20の値)を追記する。

私は24行目に追記しました:

'A1373BCF4EDB39BCFEDD484FA86A82498410A7E83456D8E80E52966F6717CB8B8E5846BBC7A540647AE770FEDEAA0E7F8A0466082156DB332A757407A12C9FB0': b'\xbd\xa2\x54\x3a\x21\x75\xb9\xf3\x0d\xf6\xf3\x09\x60\xec\x08\x2f\x3e\xc5\xef\x61\xd4\x03\xa3\x5b\xc1\x47\x7e\x10\x47\x0a\x7c\x88',

22. 「python teslacrack.py .」を実行する。

ファイルが復号されるはずです。

23. ドライブ全体を復号するために「python teslacrack.py C:\」を実行する。
24. 終わったら、すべての「*.vvv」と「howto_restore*」を検索し、移動または削除する。

これでもうクリーンかつ復号済みの状態になりました。

25. Backup, Backup, Backup!

あなた重要ファイルバックアップしましょう!できればすべてのシステムで。同じようなことが起こった場合でも、回復するために無数の時間を使うかわりに、バックアップから復元できるようになるから

まとめ

きっとこれらの追加の手順は皆さんを助けます自分がこの手順を行ったときはたくさんの問題がありました。それでもしあなたがこれを不完全だと思うなら、手順を更新するのでお知らせください。たぶん私たちはいっしょにこの手順をより完璧にすることができますありがとう

参照

https://community.norton.com/en/forums/how-decrypt-teslacrypt-vvv-files

http://factordb.com/

http://www.mobilefish.com/services/big_number/big_number.php

http://gilchrist.ca/jeff/factoring/nfs_beginners_guide.html

http://www.mersenneforum.org/showthread.php?t=20779

https://github.com/Googulator/TeslaCrack

2015-10-15

LINE Engineers' Blog掲載された記事を読み解こうとして力尽きた

http://developers.linecorp.com/blog/ja/?p=3591

Letter Sealing って何でしょうか。私気になります

必要範囲で、原文を引用しています。原文は先に引用元アドレスと閲覧日時を記し、引用記法によって地の文識別できるようにしています

長すぎ;読まない

ECDHAES256-CBC 使ってみた。通信相手の認証については読み取れない。

暗号通信の流れ

図2 において、 Server のところで Re-Encryption (一度復号されて、再度暗号化されている) ことが明示されています

この図を素直に読むと、送信者からサーバーまでの通信路は暗号化されているものLINEサーバーが受信したところで復号されて平文で保存され、サーバーから信者までの通信路は暗号化されていると理解できます文脈から、この流れを変えたいのであると推測できます

SSL公開鍵暗号

http://developers.linecorp.com/blog/ja/?p=3591 より引用2015年10月14日 22時40分に閲覧:

加えて、LINEでは、仮に通信ネットワークの傍受が行われたとしてもメッセージを覗くことができないように、公開鍵暗号(public key encryption)方式を使っていますユーザーに対してLINEアプリ提供する際、暗号化ができる公開鍵のみをアプリに入れて提供し、ユーザー端末とサーバ接続されたときだけLINEサーバでのみ解析できる暗号化された安全チャネルを作ります。こうすることで、SSL(Secure Socket Layer)より軽く、LINEの全バージョンで使用できる安全暗号化を実現できます

SSL はすでに時代遅れの代物で、 2015年現在は皆さん TLS を利用されていることでしょう。 Web ブラウザSSL 2.0SSL 3.0 を有効にしているそこのあなた、今すぐ無効しましょう。

TLS では、公開鍵暗号方式共通鍵暗号方式電子証明書暗号学的ハッシュ関数といった複数暗号技術要素を組み合わせて安全通信路を確保しています

RSA代表される公開鍵暗号方式一般的AES代表される共通鍵暗号方式と比べて計算量が大きい、つまり重たい処理となります

このため TLS では、通信路を流れるデータ暗号化に共通鍵暗号を用いて、共通鍵の共有や相手の認証のために公開鍵暗号方式を用いるのが一般的です。

仮にメッセージ暗号化に RSA を用いているとしたら、 SSL より軽いという点をどのように実装しているのか気になります

http://developers.linecorp.com/blog/ja/?p=3591 より引用2015年10月14日 22時40分に閲覧:

ユーザー側のLINEアプリ(クライアント)には、サーバが発行したRSA鍵を使用してデータ暗号化に使う暗号化鍵値を共有します。この鍵を利用してデータ暗号化すると、第三者メッセージを見ることができなくなります

これは上で説明したとおり SSLTLS でも行っていることです。

RSA を用いているので安全であるという主張をしていますが、メッセージ暗号化に用いられている暗号スイートアルゴリズムの種類、鍵の長さ、ブロック暗号場合暗号利用モード、そしてハッシュアルゴリズムの種類)は、その通信路が安全である判断できるか否かを決める大切な情報です。

http://developers.linecorp.com/blog/ja/?p=3591 より引用2015年10月14日 22時40分に閲覧:

既存RSA方式秘密データの共有に使う安全方式ではありますが、鍵管理の面から見ると、ユーザー側の端末でそれぞれのRSA鍵をすべて管理しなければならないという問題があり、その代替手段としてDHを使用するようになりました。

DH および ECDH による共通鍵暗号に用いる鍵の交換は SSLTLS でも実装されており近年では広く使われていますSSL より軽いと主張し、 SSLTLS公開鍵暗号方式以外の要素によって担保している安全性をどのように確保しているか不明実装に比べると、大きな改善です。

なお SSLTLS においては通信相手の公開鍵を全て管理する必要がないように、上で説明した電子証明書による公開鍵基盤 (PKI) の仕組みを利用しています

まり共通鍵暗号に用いる鍵の交換にどのような手段を用いるかは、鍵管理とは(ほぼ)独立です。

共通鍵暗号暗号利用モード

http://developers.linecorp.com/blog/ja/?p=3591 より引用2015年10月14日 22時40分に閲覧:

ここでメッセージ暗号化に使用している暗号アルゴリズムAES-CBC-256という方式で、現在一般に使われている暗号アルゴリズムの中で最も強度が高いと評価されています

メッセージ認証と組み合わせない CBCビット反転攻撃に弱いことが知られていますGCM ではデータ暗号化と認証を同時に行うためビット反転攻撃に耐性がありますAESGCM で利用するのは、 最近TLS実装では広く用いられており、 Googletwitter も利用しています

CBCCBC-MAC のようにメッセージ認証と組み合わせることでビット反転攻撃に強くなります

解決されない鍵管理問題

図6 のとおり、 ECDH共通鍵暗号に用いる鍵の交換を行うにしても通信相手の公開鍵必要です。 上で説明したとおり鍵管理という問題への解決策になりません。また公開鍵が本当に通信相手のものであることをどのように検証するのかについても不明です。通信相手の検証は、送信側では秘密の話を他の人に知られないように、受信側では他の人になりすまされないように、双方にて必要です。

ここから安易パターン想像ですが、通信相手の公開鍵情報LINE ユーザー情報の一部として LINE サーバー管理されており、必要に応じて安全通信路を用いて LINE サーバーから取得するようなものではないかと思います公開鍵情報のやりとりに用いられる通信路に正しく実装された TLS が用いられていて、サーバークライアントの両方が認証されていて、現在の水準から見て妥当レベル暗号スイートが用いられていることを願うばかりです。

公開鍵秘密鍵がどこでどのように保管されているのか気になります。各端末で保管するのが安全ですが、サービス要求として端末を乗り換えてもメッセージが読めるという条件を安易に満たすために秘密鍵LINE サーバーに預託していないことを祈るばかりです。

ECDH 鍵の生成は計算量が大きい処理であり質の良い乱数必要します。 PC に比べると非力なスマートフォンで生成した鍵の質をどのように担保しているのか気になります

2015年10月17日 10時16分追記

先ほど閲覧したところ、上記引用箇所の多くは削除されていました。公開鍵が本当に通信相手のものであることをどのように検証するのかについては明らかではないようです。 LINE サーバーが介在する形であれば、鍵をすり替えることで別のユーザーになりすますことが可能でしょう。または、 LINE アプリに何か細工をする方がより簡単でしょう。

ECDH 鍵はその場限り (ephemeral) という説明がないので Perfect Forward Secrecy ではないと考えられ、望ましくないという意見もあるようです。 LINE サーバーとの間に安全通信路を確立する目的で ECDH 鍵を用いる場合LINE サーバーが用いる秘密鍵漏洩は全てのユーザーに影響を与えうるため PFS は非常に重要です (TLS を用いた Web サーバーでも同様です) 。一方ユーザー間でメッセージ暗号化する場合ユーザー所有の ECDH 鍵についてはそのユーザーに影響が限定されます通信相手ごとに必要なその場限りの鍵生成とユーザー所有の ECDH 鍵を利用した鍵交換にかかる計算量と ECDH漏洩リスクを天秤にかけて PFS を採用しないという判断かもしれません。

通信の秘密という観点ではメッセージの内容だけではなく誰と通信たか (または、していないか) という情報も守りたくなります。宛先を LINE サーバー確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます

2015-01-29

http://anond.hatelabo.jp/20150128005248

詳しく、ありがとうございます

参考にさせて、頂きます

ネットから身バレしたくないので、私の分野については、詳細は明かすことが出来ませんが。

パターン学習

「わかパタ」とか「続パタ」とかは定番でよい。

ぱっと見で、分かりやすそうですね。参考にさせて頂きます

R のggplotですが。

ggplotについては、独特ですが、データフレームを取り扱うところが、それ以前のRのbaseと異なるのだと、思います

aes記述に慣れるのに、時間が掛かりました。

私がマスターしてるとは、言えませんが。

見ず知らずの者の愚痴を聞いてもらいありがとうございました。

 
ログイン ユーザー登録
ようこそ ゲスト さん