問題タブ [encryption]

私たちが持っているUATデータベース内のすべてのユーザーの名前とログインをスクランブルする必要があります。（データ保護法のため）

ただし、落とし穴があります。

テスターは、ハッシュされたログイン名を使用してログインできる必要があります

したがって、ユーザーログインが「Jesse.J.James」の場合、ハッシュは次のようになります。

Ypois.X.Qasdf

つまり、ほぼ同じ長さで、同じ場所にドットがあります

したがって、MD5、sha1などは、非常に長い文字列を作成し、検証正規表現で許可されていない+や=などの独自の特殊文字を追加するため適切ではありません。

だから私はこれを達成する方法についていくつかの提案を探しています

私は自分のハッシュアルゴリズムをロールする必要があると思います

誰かが似たようなことをしましたか？

私はc＃を使用していますが、それはアルゴリズムにとってそれほど重要ではないと思います

どうもありがとう

追加した -

すべての答えをありがとう。「ハッシュ」という言葉を使う必要がない場合は、混乱の原因になっていると思います。

SQL Server 2000 に次のクエリがあります。

「AAAA」の暗号化された文字列を出力します。

出力元 (「AAAA」) からの出力を変換 (復号化) するにはどうすればよいですか?

Cookie にデータ (ユーザー名、電子メール アドレスなど) を保存したいのですが、ユーザーが簡単に読み取ったり変更したりできません。データを読み戻せるようにする必要があります。どうすればphp 5.2+でそれを行うことができますか?

「おかえりボブ」のような機能に使用されます。永続化またはセッション ストレージに代わるものではありません。

JKS（Java Key Store）ファイルは暗号化されていますか？それらは暗号化キーを完全に保護しますか、それともアクセス制御のみに依存する必要がありますか？
キーが保護されていることを確認する方法はありますか？

アルゴリズム、キー管理などの詳細に興味があります。これは構成可能ですか？

最近、 で奇妙な問題に遭遇しましたRSACryptoServiceProvider.VerifyHash。

復号化に使用する Web アプリケーションがあります。Web サービスを実行しているユーザーが VPN 経由で実行すると、非常に遅くなりました。接続がない場合やインターネット接続がない場合は、問題ありませんでした。

掘り下げた結果、 が呼び出されるたびRSACryptoServiceProvider.VerifyHashに、チェックする LDAP 要求が行われることがわかりましたMyMachineName\ASPNET。

これは、現在のユーザーとして実行されている WebDev (cassini ベースの) サーバーでは発生せず、VPN 経由でのみ非常に遅くなりますが、まったく発生しないはずです.

これはいくつかの理由で間違っているようです:

• ローカル マシン ユーザーのドメイン コントローラーをチェックするのはなぜですか?
• なぜそれが気にするのですか？暗号化/復号化は関係なく機能します。

なぜこれが発生するのか、それを回避する最善の方法を知っている人はいますか?

C/C++ で最高の暗号化ライブラリは何ですか?

• エントロピ
• 品質
• 使いやすさ
• 可読性
• 携帯性
• パフォーマンス

あなたのお気に入りは何ですか？なぜ好きですか？

私はスタック オーバーフローについて知ったばかりで、プロジェクトの友人と一緒に持っている制約のアイデアがあるかどうかを確認しているだけですが、これは私が見つけようとしてきた理論的な質問です。しばらくの間の答え。

私は暗号化にはあまり詳しくありませんが、十分に明確でない場合は、質問を明確にするために編集/コメントを試みます。

簡単に言うと、環境は次のようなものです。

• キーの暗号化/復号化へのアクセスとしてのフロントエンドと、ストレージとクエリにのみ使用されるバックエンドを持つアプリケーション。

• たとえば、いくつかのフィールドにアクセスできないデータベースがある場合、通常どおり「アドレス」が text/varchar であるとします。

• 情報を復号化するためのキーにアクセスすることはできず、すべての情報は既に暗号化された状態でデータベースに到着します。

主な問題は、このようなものです。データベースに対して一貫してクエリを作成する方法、「'%F§YU/´~#JKSks23%' のような場所のアドレス」のようなことを行うことは不可能です。（これに対する答えを感じている人がいる場合は、遠慮なく撃ってください）。

しかし、それは大丈夫ですwhere address='±!NNsj3~^º-:'か？それとも、データベースを完全に使い果たしてしまうのでしょうか?

適用される可能性のあるもう 1 つの制約は、フロント エンドに利用できる処理能力があまりないため、既に情報の暗号化/復号化が限界に達し始めていることです。（これは、「テーブルの結合をフロントエンドにエクスポートしてそこでクエリを実行する」などの返信を避けるためだけに言っています。）

誰かがそれについて考え続ける方向に私を向けることができますか?

午前 4 時の非常に迅速な返信に感謝します。初めての使用で、このコミュニティに感銘を受けました。（または、タイムゾーンが違うだけなのかもしれません）

いくつかの情報を提供するだけです：

主な問題は、部分一致に関するものです。ほとんどのデータベースで必須要件として、部分一致を許可する必要があります。主な制約は、実際にはデータベースの所有者がデータベース内の情報を参照することを許可されないことです。最後の 10 分間で、考えられるデータベースの問題にまで拡張する解決策を思いついたので、ここに追加します。

部分一致を許可する解決策:

• パスワード + ユーザーのいくつかの公開フィールドは、実際には暗号化の鍵です。認証のアイデアは、静的な値を暗号化し、データベース内で比較することです。
• 情報が解析された方法で格納されるテーブルの新しいセットを作成します。つまり、「4th Street」は 2 つの暗号化された行になります (「4th」用に 1 行、「Street」用に 1 行)。これにより、別のテーブルで検索が既に実行されている可能性があるため、部分的な一致が可能になります。

新しい質問:

• これはおそらくデータベースサーバーを再び食い尽くすのでしょうか、それとも部分一致の問題に対する実行可能な解決策であると誰かが考えていますか?

Post Scriptum: 私は Cade Roux からの回答を受け入れませんでした。これは、さらなる議論と、特に新しい質問に対する可能な回答を可能にするためです。

ユーザーのパスワードをソルトおよびハッシュする場合は、ソルトがあれば明らかに役立ちます。塩の長さに関するベストプラクティスはありますか？ソルトをユーザーテーブルに保存するので、ストレージサイズとセキュリティの間の最良のトレードオフが必要です。ランダムな10文字の塩で十分ですか？それとももっと長いものが必要ですか？

たくさんのファイルがあるとしましょう。これらのファイルにメタデータを保存できるとします。たとえば、これらのメタ属性の1つは「暗号化」と呼ばれていました。誰もがこれらのファイルを見ることができたとしましょう。ただし、これらのファイルは暗号化されているため、復号化の方法を知っている人だけが実際にコンテンツを読み取ることができます。たとえば、「暗号化」の特定の値ごとに、人々のグループがその値でマークされたファイルを復号化する方法に関する知識を共有します。OSにとらわれない方法で、プログラムでこれを実行できるようにしたいとします（可能な場合）

「暗号化」に使用する値は何ですか？キーをどのように保存しますか？キーへのアクセスをどのように整理しますか？

私は現在、次の実装に傾いています：

• フィールド「encryption」の値にはキーの名前が含まれており、使用されるアルゴリズムも示している可能性があります
• 各ユーザーは、一連のキーにアクセスできます。これは、LDAP / ActiveDirectoryのような構造でユーザーが持つ役割によって定義することも、ユーザープロファイル/ホームディレクトリの安全なディレクトリにあるファイルにすることもできます。
• ファイルを表示すると、ビューア（ドキュメント管理システムを構築しようとしています）はユーザーキーをチェックし、一致するキーが見つかった場合はファイルを復号化します。

どの暗号化を使用しますか？対称（AES）？または非対称（良いものは何ですか）？

非対称キーを使用すると、ファイルの読み取りと書き込みを区別できるという追加の利点があります。ファイルの書き込みには秘密キーへのアクセスが必要であり、公開キーへのアクセスが必要です（特定の役割のみがアクセスできるため、半公開のみ）。 it）ファイルの読み取りを許可します。私はここで完全に間違っていますか？

中小企業で使用されるこれらの問題を解決するための一般的なシステムは何ですか？

編集：普遍的な解決策はないようです。それで、私が解決しようとしている問題をもう少し明確に述べます：

分散方式で動作するドキュメント管理システムを想像してみてください。各ドキュメントは、（会社が管理するプライベートな）P2Pネットワークのさまざまなノードにコピーされます。ドキュメントの冗長性を保証するためのアルゴリズムを使用して、すべてのドキュメント（リビジョンを含む）のバックアップを確保します。このシステムは、バックグラウンドでサービス/デーモンとして機能し、ドキュメントを前後にシャベルで移動します。

これは、ユーザーがローカルワークステーション（会社が管理するPCやラップトップなど）で表示することを意図していないドキュメントになってしまうことを意味します。この設定では、SME IT担当者がこれをすべて設定し、誰が参加するかを管理します。 P2Pネットワークの）。

これにより、ユーザーはおそらくデータにアクセスできるため、ディレクトリアクセスベースのスキームが除外されます。私はここで間違っていますか？ドメインユーザーのみがアクセスできるようにローカルフォルダを暗号化できますか？それはどれくらい安全ですか？

私は、ユーザーが復号化されたバージョンのファイルを共有していることを知っています-そしてそれを技術的に抑制するのは難しいです。これは私が解決しようとしている問題ではありません。

難読化、ハッシュ、暗号化の違いは何ですか?

ここに私の理解があります：

• ハッシュは一方向のアルゴリズムです。元に戻すことはできません
• 難読化は暗号化に似ていますが、理解するために「秘密」を必要としません (ROT13 はその一例です)。
• 暗号化は元に戻すことができますが、そのためには「秘密」が必要です