タグ付けされた質問 「encryption」

休業。この質問はもっと焦点を合わせる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 9か月前に閉鎖。 この質問を改善する AndroidでAESを使用して画像やその他のファイルを暗号化および復号化する方法の良い例はありますか？

105 java  android  encryption  aes 

ここに投稿されたコメントによると、mcrypt-extensionは非推奨になり、PHP 7.2で削除されます。だから私はパスワードを暗号化する別の方法を探しています。 今私は何かを使っています mcrypt_encrypt(MCRYPT_RIJNDAEL_128, md5($key, true), $string, MCRYPT_MODE_CBC, $iv) 私の顧客は新しいパスワードを生成せずにパスワードを「回復」するオプションを望んでいるため、暗号化されたパスワードはもちろんPHP 7.xxでサポートされ、解読可能である必要があります。 1。

103 php  encryption  passwords  php-7  mcrypt 

キーを生成してDBに格納する必要があるので、それを文字列に変換しますが、文字列からキーを取得します。これを達成するための可能な方法は何ですか？ 私のコードは、 SecretKey key = KeyGenerator.getInstance("AES").generateKey(); String stringKey=key.toString(); System.out.println(stringKey); 文字列からキーを取得するにはどうすればよいですか？

102 java  string  encryption 

私がいることを実感OAuthの仕様は、特にトークン（ConsumerKey、ConsumerSecret、AccessToken、RequestToken、TokenSecret、または検証用コードの起源については何も指定しませんが、非常に安全なトークンを作成するための任意のベストプラクティスがある場合、私は好奇心が強いです/秘密の組み合わせ）。 私が見るように、トークンを作成するにはいくつかのアプローチがあります： ランダムなバイトを使用し、コンシューマー/ユーザーに関連付けられたDBに保存します 一部のユーザー/コンシューマー固有のデータをハッシュし、コンシューマー/ユーザーに関連付けられたDBに保存します ユーザー/消費者固有のデータを暗号化する （1）の利点は、データベースが最も安全と思われる唯一の情報源であることです。（2）や（3）よりも攻撃を行うのは難しいでしょう。 実際のデータ（2）をハッシュすると、おそらく既知のデータからトークンを再生成できます。とにかく保存/検索する必要があるので、（1）には実際には何の利点も提供しない可能性があります。（1）よりもCPUに負荷がかかります。 実際のデータを暗号化すると（3）、暗号化を解除して情報を知ることができます。これは、（1）と（2）よりも必要なストレージが少なく、検索数が少ない可能性がありますが、安全性も低くなる可能性があります。 考慮すべき他のアプローチ/利点/欠点はありますか？ 編集：別の考慮事項は、トークンに何らかのランダムな値が存在する必要があることです。これは、新しいトークンを期限切れにして再発行する機能が存在する必要があるため、実際のデータのみで構成されてはならないためです。 続く質問： 暗号的に非常に安全にするための最小トークン長はありますか？私が理解しているように、トークンシークレットが長いほど、より安全な署名が作成されます。この理解は正しいですか？ ハッシュの観点から、特定のエンコーディングを別のエンコーディングよりも使用する利点はありますか？たとえば、16進エンコーディング（GUID文字列など）を使用する多くのAPIが表示されます。OAuth署名アルゴリズムでは、トークンは文字列として使用されます。16進文字列を使用すると、Base64エンコーディングを使用する場合よりも、使用可能な文字セットがはるかに小さくなります（予測可能になります）。同じ長さの2つの文字列の場合、文字セットが大きい文字列ほど、ハッシュ分布が広くなります。これにより、セキュリティが向上すると思われます。この仮定は正しいですか？ OAuth仕様では、この問題が11.10 Entropy of Secretsで発生しています。

100 security  encryption  oauth  hash 

職場では、塩に関して2つの競合する理論があります。私が取り組んでいる製品は、ユーザー名や電話番号などを使用してハッシュをソルトします。基本的にユーザーごとに異なりますが、すぐに利用できます。他の製品はユーザーごとにランダムにソルトを生成し、ユーザーがパスワードを変更するたびに変更されます。ソルトはデータベースで暗号化されます。 私の質問は、2番目のアプローチが本当に必要かどうかです。純粋に理論的な観点からは、最初のアプローチよりも安全であることは理解できますが、実用性の観点からはどうでしょうか。現在、ユーザーを認証するには、ソルトを暗号化せずにログイン情報に適用する必要があります。 それについて考えた後、私はこのアプローチから実際のセキュリティの向上を見ることはありません。アカウントごとにソルトを変更すると、攻撃者が各アカウントのハッシュをすばやく特定する方法を知っていたとしても、ハッシュアルゴリズムをブルートフォースにしようとする試みが非常に困難になります。これは、パスワードが十分に強力であることを前提としています。（明らかに、すべてが2桁のパスワードのセットの正しいハッシュを見つけることは、8桁のパスワードの正しいハッシュを見つけるよりもはるかに簡単です）。私の論理が間違っていますか、それとも私が見逃しているものはありますか？ 編集：わかりましたので、ここで、ソルトを暗号化するのは本当に難しいと思う理由です。（私が正しい軌道に乗っているかどうかはわかります）。 以下の説明では、パスワードは常に8文字、saltは5文字で、すべてのパスワードが小文字で構成されていると仮定します（計算を簡単にするためです）。 エントリごとに異なるソルトがあると、同じレインボーテーブルを使用できません（実際には、十分なサイズの1つがあれば実際には技術的に使用できますが、今のところは無視します）。これは私が理解していることから、ソルトの本当の鍵です。すべてのアカウントをクラックするには、それぞれについて話すために、車輪を再発明する必要があるためです。ハッシュを生成するために正しいソルトをパスワードに適用する方法を知っている場合、ソルトはハッシュされたフレーズの長さ/複雑さを実際に拡張するだけなので、そうします。したがって、ソルトとは何かを知っているので、パスワードとソルトを "知っている"ために生成する必要がある組み合わせの数を13 ^ 26から8 ^ 26に削減します。今ではそれが簡単になりますが、それでも本当に難しいです。 ソルトの暗号化に移ります。ソルトが暗号化されていることがわかっている場合は、最初にそれを解読しようとはしません（十分なレベルの暗号化があることを前提として）。無視します。それを解読する方法を理解する代わりに、前の例に戻って、13 ^ 26のすべてのキーを含むより大きなレインボーテーブルを生成します。ソルトを知らないと間違いなく私は遅くなりますが、ソルトの暗号化を最初に解読しようとするという記念すべき仕事が増えるとは思いません。だからそれだけの価値はないと思います。考え？ 以下は、ブルートフォース攻撃を受けた場合のパスワードの保持期間を説明するリンクです。http： //www.lockdown.co.uk/？pg = combi

99 security  encryption  hash  brute-force 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ Stack Overflowのトピックとなるように質問を更新します。 7年前休業。 この質問を改善する 先週、宿題用の小さなGUIを作成する必要がありました。私の学校の仲間は誰もそれをしませんでした。彼らは私たちがそれをアップロードしなければならなかった場所から私のものを盗み、それから彼らは彼らのものとして再びそれをアップロードしました。私が先生に言ったとき、それはすべて私の仕事でした、彼は私を信じていませんでした。 だから私はそれをコード化した証拠を使って、役に立たないメソッドか何かを中に入れることを考えました。暗号化について考えました。これまでの私の最高のアイデア： String key = ("ZGV2ZWxvcGVkIGJ5IFdhckdvZE5U"); //My proof in base64 他にもっと良い方法を考えられますか？

96 encryption 

任意の長さの文字列を取り、10文字未満のハッシュを生成できる暗号化の方法はありますか？合理的に一意のIDを生成したいが、ランダムではなく、メッセージの内容に基づいています。 メッセージを整数値に制限しても問題ありませんが、任意の長さの文字列は不可能です。ただし、その場合、ハッシュは2つの連続した整数で類似していてはなりません。

96 encryption  uniqueidentifier 

ユーザー名とパスワードの組み合わせを使用してサードパーティのサービスから定期的に情報を取得する小さなPythonスクリプトを書いています。100％防弾のようなものを作成する必要はありませんが（100％も存在しますか？）、十分なセキュリティ対策を講じたいので、少なくとも誰かがそれを壊すのに長い時間がかかります。 このスクリプトにはGUIがなく、によって定期的に実行されるcronため、実行するたびにパスワードを入力して復号化することは実際には機能せず、ユーザー名とパスワードを暗号化されたファイルまたは暗号化されたファイルに保存する必要がありますSQLiteデータベースでは、とにかくSQLiteを使用するので、これが望ましいでしょう。ある時点でパスワードを編集する必要があるかもしれません。さらに、現時点ではWindows専用であるため、プログラム全体をEXEでラップすることになります。 cronジョブを介して定期的に使用するユーザー名とパスワードの組み合わせを安全に保存するにはどうすればよいですか？

96 python  security  encryption 

1つは他よりも安全ですか？

91 encryption  ssh  rsa  public-key-encryption  dsa 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ Stack Overflowのトピックとなるように質問を更新します。 7年前休業。 この質問を改善する SHA暗号化とAES暗号化の違いは何ですか？

90 encryption  aes 

この質問をする理由： Androidであっても、AES暗号化について多くの質問があったことは知っています。また、Webを検索すると、多数のコードスニペットがあります。しかし、すべてのページ、すべてのStack Overflowの質問で、大きな違いがある別の実装を見つけました。 そこで、「ベストプラクティス」を見つけるためにこの質問を作成しました。最も重要な要件のリストを収集し、本当に安全な実装をセットアップできることを願っています！ 初期化ベクトルとソルトについて読みました。私が見つけたすべての実装にこれらの機能があったわけではありません。それであなたはそれが必要ですか？セキュリティは大幅に向上しますか？どのように実装しますか？暗号化されたデータを復号化できない場合、アルゴリズムは例外を発生させる必要がありますか？または、それは安全ではなく、単に読み取り不可能な文字列を返す必要がありますか？アルゴリズムはSHAの代わりにBcryptを使用できますか？ 私が見つけたこれらの2つの実装についてはどうですか？彼らは大丈夫ですか？完璧またはいくつかの重要なものが欠けていますか？これらのうちどれが安全ですか？ アルゴリズムは、暗号化のために文字列と「パスワード」を受け取り、そのパスワードで文字列を暗号化する必要があります。出力は文字列（hexまたはbase64？）である必要があります。もちろん、復号化も可能であるべきです。 Androidに最適なAES実装は何ですか？ 実装＃1： import java.security.MessageDigest; import java.security.NoSuchAlgorithmException; import java.security.NoSuchProviderException; import java.security.SecureRandom; import javax.crypto.Cipher; import javax.crypto.SecretKey; import javax.crypto.SecretKeyFactory; import javax.crypto.spec.IvParameterSpec; import javax.crypto.spec.PBEKeySpec; import javax.crypto.spec.SecretKeySpec; public class AdvancedCrypto implements ICrypto { public static final String PROVIDER = "BC"; public static final int SALT_LENGTH = 20; public …

89 android  encryption  aes 

背景：上司がパブリックパーツとプライベートパーツを使用してASCキーをエクスポートしようとしましたが、ファイルを取得するたびにプライベートパーツが読み込まれず、ファイルが復号化されません。 以下を使用して、ASCキーのエクスポートを試みました。 WindowsアプリケーションKleopatra 2.1（gpg4winに含まれる） WindowsアプリケーションGNUプライバシーアシスタント（gpg4winに含まれる） Error: "Decryption failed. Secret Key Not available." シークレットまたはプライベートのascキーを適切にエクスポートしてgpgファイルを復号化するにはどうすればよいですか？

88 encryption  gnu  gnupg  private-key 

整数IDを別の整数に暗号化/難読化する方法を探しています。もっと正確に言えば、私は関数が必要なint F(int x)ので、 x <-> F（x）は1対1の対応です（x！= yの場合、F（x）！= F（y）） F（x）が与えられると、xを見つけるのは簡単です-したがって、Fはハッシュ関数ではありません xとF（x）が与えられると、F（y）を見つけるのは困難/不可能であり、次のようなものx ^ 0x1234は機能しません 明確にするために、私は強力な暗号化ソリューションを探していません。それは難読化だけです。以下のようなURLを使用したWebアプリケーションを想像しexample.com/profile/1、example.com/profile/2自身が秘密でないなどのプロファイルを、私は、私のようなものの後ろにそれらを隠すというと思いますので、すべてのプロファイルを次々にフェッチ/ビューにカジュアル覗きを防ぐしたいexample.com/profile/23423、example.com/profile/80980234などが、データベースに保存されたトークンは非常に簡単に仕事をすることができます、これに利用できるいくつかの簡単な数学があるかどうか私は興味があります。 私が明確にしなかった重要な要件の1つは、結果が「ランダム」に見える必要があることです。つまり、シーケンスが与えられた場合x,x+1,...,x+n、F(x),F(x+1)...F(x+n)いかなる種類の進行も形成しないようにする必要があります。

85 algorithm  encryption 

.pem、.cerとの違いは何.derですか？ 私の知る限り、.cer公開鍵が含まれています。この公開鍵を使用してデータを暗号化するために使用できるオープンフレームワークはありますか？

84 encryption  cryptography  rsa 

多くの不幸なiPhoneユーザーから、iTunesバックアップからデータを復元するのを手伝ってくれるように頼まれました。これは、暗号化されていない場合は簡単ですが、パスワードがわかっているかどうかに関係なく、暗号化されている場合は簡単ではありません。 そのため、暗号化されたときにmddataファイルとmdinfoファイルで使用される暗号化スキームを理解しようとしています。それ以外の場合はこれらのファイルを読み取るのに問題はなく、そのための堅牢なC＃ライブラリをいくつか構築しました。（あなたが助けることができれば、私はあなたがどの言語を使うかは気にしません。それは私がここで求めている原則です！） Appleの「iPhoneOSEnterprise展開ガイド」には、「iTunesのデバイス概要ペインで[iPhoneバックアップの暗号化]オプションを選択すると、デバイスのバックアップを暗号化された形式で保存できます。ファイルは256ビットキーのAES128を使用して暗号化されます。キーはiPhoneのキーチェーンに安全に保管されています。」 これはかなり良い手がかりです。iPhoneAES / Rijndaelの相互運用性に関するStackoverflowには、128のキーサイズとCBCモードを使用できることを示唆するいくつかの良い情報があります。 他の難読化とは別に、キーと初期化ベクトル（IV）/ソルトが必要です。 キーは、ユーザーがiTunesによって入力を求められ、CBCによって指示された方法で埋め込まれた「AppleMobileBackup.exe」に渡される「バックアップパスワード」の操作であると考える人もいるかもしれません。ただし、iPhoneキーチェーンへの参照を考えると、「バックアップパスワード」がX509証明書または対称秘密鍵のパスワードとして使用されないのではないか、証明書または秘密鍵自体が鍵として使用されるのではないかと思います。（AESとiTunesの暗号化/復号化プロセスは対称的です。） IVは別の問題であり、それはいくつかのことかもしれません。おそらく、それはiTunesまたはデバイス自体にハードコードされたキーの1つです。 上記のAppleのコメントは、キーがデバイスのキーチェーンに存在することを示唆していますが、これはそれほど重要ではないと思います。暗号化されたバックアップを別のデバイスに復元できます。これは、復号化に関連するすべての情報がバックアップとiTunesの構成に存在し、デバイス上にあるものだけがこのコンテキストでは無関係で置き換え可能であることを示しています。では、鍵はどこにあるのでしょうか。 以下にWindowsマシンからのパスをリストしましたが、どのOSを使用する場合でもかなりの量になります。 「\ appdata \ Roaming \ AppleComputer \ iTunes \ itunesprefs.xml」には、「Keychain」dictエントリを含むPListが含まれています。「\ programdata \ apple \ Lockdown \ 09037027da8f4bdefdea97d706703ca034c88bab.plist」には、「DeviceCertificate」、「HostCertificate」、および「RootCertificate」を含むPListが含まれており、これらはすべて有効なX509証明書のようです。同じファイルには、非対称キー「RootPrivateKey」と「HostPrivateKey」も含まれているようです（私の読書では、これらはPKCS＃7エンベロープである可能性があります）。また、各バックアップ内には、Manifest.plistファイルに「AuthSignature」と「AuthData」の値がありますが、これらは各ファイルが段階的にバックアップされるにつれてローテーションされているように見えますが、実際に何かがない限り、キーとしてはそれほど有用ではないことを示唆していますかなり関与しています。 暗号化されたバックアップからデータを取得するのが簡単であることを示唆する誤解を招くものがたくさんあります。そうではなく、私の知る限り、それは行われていません。バックアップ暗号化をバイパスまたは無効にすることはまったく別の問題であり、私がやろうとしていることではありません。 これは、iPhoneなどをハッキングすることではありません。私がここで求めているのは、暗号化されていないものと同じように、暗号化されたiTunesバックアップからデータ（写真、連絡先など）を抽出する手段だけです。上に書いた情報を使ってあらゆる種類の順列を試しましたが、どこにも行きませんでした。私が見逃したかもしれない考えやテクニックをいただければ幸いです。

84 iphone  backup  itunes  encryption