問題タブ [blowfish]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
java - IRCボットのblowfish暗号化メッセージを復号化する方法
チャンネルのコンテンツを読み取るために、PHPでIRCボットを作成しています。ボットは正常に実行されますが、メッセージはblowfish暗号化で暗号化されます。私は鍵とすべてを持っています、私は以下のPHPのコードを試しましたが、うまくいきませんでした。
さらにヘルプが必要な場合は、drftpdサイトボットを介して暗号化を行います。
このリンクを見つけることができますhttp://trac.drftpd.org/browser/branches/jpf/src/plugins/org.drftpd.plugins.sitebot/src/org/drftpd/plugins/sitebot/OutputWriter.java?rev=1721
Javaで書かれているので、Javaの人も助けてくれるかもしれません。
php - MCRYPT_DEV_RANDOM always the same
I'm using MCRYPT_DEV_RANDOM
and MCRYPT_DEV_URANDOM
as part of blowfish encryption, but I'm noticing it outputs the same random digit every time. It differs from machine to machine, but it's the same in each machine.
- Is this normal?
- Does it affect the strength of the initialization vector (IV) I generate with it?
java - javaと.netと比較すると、mcryptのblowfish phpの結果はわずかに異なります
キー値とペイロードを変更したコード例を次に示します。
これにより、PHP では問題なく暗号化と復号化が行われますが、Java と .NET では異なる値が生成されます。さらに悪いことに、Java または .NET からの結果を復号化できません。Java から値を復号化しようとすると、最初は正しく文字列が返されますが、途中でゴミになってしまいます。誰かが疑問に思った場合に備えて、私は Windows XP の 5.3x で作業しています。
私が STFW をしている間、いくつかのスレッドに気付きました。最後のコメントでは、入力の問題が原因で base64 が結果を台無しにしていることについて言及しています。結果が非常に近くなり、最初の 50 文字ほどが一致するため、それが起こっているのではないかと考えています。 、その後 @#$! に移動します。
ブロックサイズとパディングに関するいくつかのスレッドも読みましたが、パディングがどうあるべきかについて誰も同意していないようです。Javaがテキストをパディングしているかどうか、デフォルトのブロックサイズはどれくらいか、パッドはどうなるかを本当に知りたいです。下記参照:
Java 開発者は次のことを行っています。
私はすでにこれに多くの時間を費やしてきました。誰かここに何かアイデアがありますか? ありがとう。
random - 高速で安全な乱数
私はこの興味深い一口/dev/urandom
に出くわしたときよりも速い代替手段を探していました:
非常に優れた非ランダムだがほぼランダムなビットを生成するための1つの優れたトリックは、/ dev / randomのエントロピーを使用して高速対称ストリーム暗号(私のお気に入りはblowfish)をシードし、その出力をそれを必要とするアプリケーションにリダイレクトすることです。
これは初心者のテクニックではありませんが、2行または3行のシェルスクリプトといくつかのクリエイティブなパイプを使用して簡単にセットアップできます。
さらなる調査により、セキュリティに関するシュナイアーからのこのコメントが得られました。
「エントロピーを注入」する場合、それを行う方法はいくつかありますが、より良い方法の1つは、高速ストリーム暗号全体に「拡散」し、非決定論的サンプリングシステムと結合することです。
私が間違っている場合は訂正してください。ただし、ランダムビットを生成するこの方法は/dev/urandom
、速度とセキュリティの点で単純に優れているようです。
だから、これが実際のコードについての私の見解です:
この速度テストは400MBのゼロを取り、疑似ランダムで印刷可能な文字で作られた448ビットのキーを使用してblowfishを使用して暗号化します。これが私のネットブックの出力です:
400+0レコードイン400+0レコードアウト419430400バイト(419 MB)コピー、14.0068秒、29.9MB/秒
実際の0m14.025sユーザー0m12.909ssys0m2.004s
それは素晴らしいことです!しかし、それはどのくらいランダムですか?結果を次の場所にパイプしてみましょうent
:
エントロピー=バイトあたり8.000000ビット。
最適な圧縮により、この419430416バイトファイルのサイズが0%削減されます。
419430416サンプルのカイ2乗分布は250.92であり、ランダムにこの値を50.00パーセント超えることがあります。
データバイトの算術平均値は127.5091(127.5 =ランダム)です。Piのモンテカルロ値は3.141204882(エラー0.01パーセント)です。シリアル相関係数は-0.000005です(完全に無相関= 0.0)。
よさそうだ。ただし、私のコードには明らかな欠陥がいくつかあります。
/dev/urandom
初期エントロピーソースに使用します。- 印刷可能な文字のみが使用されるため、キー強度は448ビットと同等ではありません。
- エントロピーを「拡散」するために、暗号を定期的に再シードする必要があります。
それで、私は自分が正しい方向に進んでいるかどうか疑問に思いました。そして、誰かがこれらの欠陥のいずれかを修正する方法を知っているなら、それは素晴らしいことです。また、、、、、またはDBAN以外の場合は、ディスクを安全にワイプするために使用するものを共有していただけ/dev/urandom
ますか?sfill
badblocks
ありがとうございました!
編集:ストリーム暗号としてblowfishを使用するようにコードを更新しました。
delphi - Delphi フグ モード ecb (Delphi への Python コンバーター)
私はプログラマーとして、誰かが行うことはめったにないことを知っていますが、実際にはそれが必要であり、まったくできないので、誰かがこの小さな関数暗号化 python を Delphi 用に変換する必要があります。
-
私はDelphiでやろうとしたが、いつも違う結果を見せてくれるので、何度も人々に会い、より良い結果を出し、python / delphiを理解している人に頼む
ありがとうございます!
php - PHP フグの暗号化
ログイン フォームを外部サイトにポイントするように依頼されました。外部サイトでは、URL にログインとパスが存在し、パスが Blowfish で暗号化されている必要があります。次の形式の「キー」が提供されました。"nnn-nnnssssssssssssssssssssssssnnnnnn"
ここで、n は数字、s は文字 (24 個) です。
PHP ドキュメントから、crypt() で Blowfish 暗号化をトリガーするには、「$2a$」で始まる特定の形式でソルトを提供する必要があるようですが、これは私が提供したキーの形式ではありません。これは、自分の塩を用意する必要があるということですか? はいの場合、提供されたキーのポイントは何ですか?
php - PHP セキュア セッション
phpmyadmin (データベース管理 UI) に似たアプリケーションを作成しています。ユーザーはデータベースに対して自分自身を認証する必要があり、アプリケーションは何らかの方法で資格情報を保存する必要があります。SSL は、すべてのインストールのオプションではありません。
- アイデア 1: ユーザーは資格情報を送信し、アプリケーションはユーザー名を保存し、定義済みのフグの秘密鍵 (config.ini.php) を使用してパスワードを暗号化します - これは phpMyAdmin が行うことです。
- アイデア 2: ログイン フォームがランダムなフグ シークレット (javascript) を作成し、ユーザーがログイン資格情報を送信し、アプリケーションがユーザー/パスワードを暗号化してサーバー側でセッションに保存し、秘密鍵が Cookie に保存され、リクエストごとに送信されます。
アイデア 1: サーバーのセキュリティが侵害された場合の問題。(キーは config にあり、セッション データは /tmp にあります)
アイデア 2: 中間者攻撃の問題。(キー + クレデンシャルが送信されます)
他の提案はありますか?批判?
debugging - 現実の確認が必要です: この VB6 Blowfish バグの私の分析は正しいですか?
最近、Blowfish アルゴリズムを比較する機会がありました。DI Managementのライブラリと PHP のmcryptの出力を比較していました。私は彼らに同意してもらうことができませんでした。
これは私を興味深い追跡に導きました。Bruce Schneier の Web サイトへのこの投稿によると、Blowfish コードの初期バージョンに符号拡張のバグがあり、DI 管理コードはバグ報告前のコードを実装しているようです。
バグレポートの宣伝文には、一部、次のように書かれています。
key[j] の最上位ビットが「1」の場合は常にチョークします。たとえば、key[j]=0x80 の場合、signed char である key[j] は、データと OR される前に 0xffffff80 に符号拡張されます。
blf_Initialise
basBlowfish.bas の関数の同等のコードは次のとおりです。
バグ レポートでは、C コードに対する次の修正が提案されています。
私はVB6で実装しました
実際、両方のメソッドが使用され、値が同じかどうかを確認するアサーションを入れるように記述しました。
aKey(j) に 255 が含まれていると、アサーション エラーが発生します。
私はこの状況を正しく読んでいますか?符号拡張エラーが発生していますか、それとも存在しないバグが発生していますか?
不思議なことに、DI 管理コードに付属するテストは、この変更の有無にかかわらず正しく動作するように見えます (これは、2 つのアルゴリズム間の同等性を求める私の検索が他の何かに依存している可能性があることを意味します)。
php - 最も「正しい」フグのアルゴリズムはどれですか?
私は Windows Server 2k8 を実行しています (おそらくそれが問題の半分でしょうか?) とにかく、さまざまな言語のさまざまな Blowfish モジュールからさまざまな値を取得しています。標準として信頼できるものはありますか?
password
次の例では、キーがで、プレーンテキストが であると想定しています12345678
。
を。アルゴリズムがモードに設定され、チェックされているオンライン暗号化ツールは、 . 私はこれを、賢明かどうかにかかわらず、私の基準点として使用してきました。Blowfish
ECB
Base64 Encode the output
2mADZkZR0VM=
b. 次の Perl コードではCrypt::ECB
、 とMIME::Base64
これ2mADZkZR0VM=
は PADDING_NONE で出力されます (上記の「a.」とよく比較されます)。ただし、パディングが設定されてPADDING_AUTO
いる場合2mADZkZR0VOZ5o+S6D3OZw==
、少なくとも私の考えでは、平文の長さが8文字でパディングが不要なため、これはバグです。
c. Crypt::Blowfish
以下のように使用する場合
次に、2mADZkZR0VM=
「a」に一致するものを取得します。その上。ただし、このモジュールの問題点は、エンコードのために物事を 8 バイトのチャンクに分割する必要があることです。独自のチャンカーはありません。
d. http://linux.die.net/man/3/bf_ecb_encrypt (最近の PHP ext プロジェクトで使用したもの)のソースを使用すると、'a.' と同じ答えが得られます。SSLeay と OpenSSL で使用されているため、このコードを最も信頼する傾向があります。
e. BlowfishEx.EXE
DI 管理のBlowfish :パディング付きの Visual Basic バージョンは、Crypt::ECB の結果と同じものを提供します。Padding を に設定すると、「a.」に一致するものを取得できます。PKCS#5
2mADZkZR0VOZ5o+S6D3OZw==
PADDING_AUTO
None
2mADZkZR0VM=
私はこれを書いて私自身の質問に部分的に答えました.VB6プロジェクトのDI管理のコードを変更する必要があるようです. Crypt::ECB の作成者に同じことを提案するかもしれません。
しかし、疑問が残ります。信頼できるフグのリファレンス プラットフォームはありますか?
java - UDP パケットを暗号化するための暗号は?
UDP を介して時間に敏感な通信を行うアプリケーションがあります (ビデオ ストリーミングやゲームなど)。パケットは失われる可能性があり、再送信する必要はありません。
データグラムの暗号化にはどの暗号を使用すればよいですか?
ECBモードでフグに傾いています。ECB モードに問題があることはわかっていますが、失われたパケットをサポートする必要があるため、暗号化は以前のブロックに依存できません。ECB モードの問題を軽減し、パケットの欠落を許容するために使用できる、より優れた暗号またはモードはありますか?
(すべて純粋な Java のままにしたいので、DTLS は使用できません。)