- ベストアンサー
暗号化しないほうが安全なのはなぜですか？
backy0175の回答
- backy0175
- ベストアンサー率87% (102/116)
参考になさっている情報は、 1) 符丁を決めて情報交換する = 暗号化 2) 符丁は平易な言葉を使用する 3) 実際の通信は平文で行う 4) 平文かつ通信が暗号化されていないので見過ごされる 5) だから安全だ という流れですね。 でも暗号化していないわけじゃので質問のタイトルと説明が適切ではないと思います。 スパイ映画ではありませんが、いわゆる情報機関ではすでにかなりな部分がIT化されておりやる気(動機)と予算があれば符丁も解析の対象になっていると思いますよ。
関連するQ&A
- ＪａｖａからVBScriptへのＡＥＳ暗号化によるデータ渡し
javaで作られたサイトからVBScriptで作られたサイトへサイレントログインするシステムを構築しています。 その際にログインIDをAES(キー長128bit、ECBモード)で暗号化し渡そうと考えています。 javaではCipherクラスで暗号化し、aspではCAPICOMで復号化しようとしているのですが、うまくいきません。 そもそも同じ平文と鍵で暗号化しても同じ暗号文になりません。（javaはbase64に変換しています。CAPICOMが間違っているような気はしているのですが、参考になるものが少なくて困っています。） CAPICOMはhttp://apis.jpn.ph/fswiki/wiki.cgi?page=ScrapCode%2FVBS%2FConvertのサンプル通りにやっています。 CAPICOMでもjavaでも同じ暗号化方式ならば同じ結果が返ってくるべきだと思うのですが、認識違いますか？ どうすれば、同じ暗号文が取得できるのでしょうか？ また、java-VBScript間のAES暗号でのデータ渡しについて、 違う方式で可能ならば教えてください。 よろしくお願いします。
- 締切済み
- Microsoft ASP
- Java(AES)多重の暗号化・復号化、安全？
メンタル・ポーカー・アルゴリズム↓をJavaで実装したくて http://en.wikipedia.org/wiki/Mental_poker まず、暗号化について調べました。 AESという暗号化の方法を使ってみたのですが、 これなら、多重に暗号化したとして、順番に関わらず、 復号化できるようなので、メンタル・ポーカー・アルゴリズムが実装できると思いました。 しかしながら、私はこのAESという暗号化の方法について、詳しく知りません。 この暗号化方法は、安全なのでしょうか。たとえば、カギがなくとも、暗号前のデータの見当がつく かのようなことが、スーパーコンピュータの手にかかれば一時間もあれば分かってしまう、 というようなことはないでしょうか。 下記は、ランダムな順番で暗号化・復号化してみたコードです↓ 参考になればと思い乗せてみます static void shuffle(int[] array) { for (int i = 1; i < array.length; i++) { int n = random.nextInt(i + 1); int t = array[i]; array[i] = array[n]; array[n] = t; } } public void testAES() throws Exception { String alg = "AES"; byte[] orgData = "abcdefghhijklmno".getBytes(); KeyGenerator keygen = KeyGenerator.getInstance(alg); int keyCount = 16; Key[] keys = new Key[keyCount]; int[] encryptOrder = new int[keyCount]; int[] decryptOrder = new int[keyCount]; for (int i = 0; i < keyCount; i++) { keys[i] = keygen.generateKey(); encryptOrder[i] = i; decryptOrder[i] = i; } shuffle(encryptOrder); shuffle(decryptOrder); byte[][] ivs = new byte[keyCount][]; Cipher cipher = Cipher.getInstance(alg + "/OFB/NoPadding"); byte[] data = orgData.clone(); for (int i = 0; i < keyCount; i++) { int idx = encryptOrder[i]; cipher.init(Cipher.ENCRYPT_MODE, keys[idx]); ivs[idx] = cipher.getIV(); data = cipher.doFinal(data.clone()); } for (int i = 0; i < keyCount; i++) { int idx = decryptOrder[i]; cipher.init(Cipher.DECRYPT_MODE, keys[idx], new IvParameterSpec(ivs[idx])); data = cipher.doFinal(data); } assertTrue(new String(data), Arrays.equals(orgData, data)); }
- ベストアンサー
- Java
- データの暗号化について
次の二つはデータの暗号化について説明していますが 私の理解で合っているか教えていただけますか。 １送受信されるファイルは、「ユーザーとサーバーの間で暗号化」されており 「サーバー上でも同様である」 ２ユーザーのコンピュータ上でもデータを暗号化している 私とサーバーの間で暗号化されるというのは 私が入力したデータはサーバーに到着すると同時に暗号化されるということ。 一方で、コンピューター上で暗号化されるというのは、 私のコンピューターにそういう機能がついていて、暗号化されたデータをサーバーに 送信しているとういこと。 １と２は下記のリンクから抜粋しました。 http://jp.techcrunch.com/2014/10/13/20141011edward-snowden-new-yorker-festival/ 現在は、１の方が主流でしょうか。 その場合、２の方が安全だと思いますが、２が主流にならない理由は何でしょうか。 ありがとうございます。
- ベストアンサー
- ネットワーク
- これは、安全対策になっていますか？
メールでの情報交換の安全性に興味を持って調べていたら、 山口県では安全のため、電子メールで送信する添付ファイルのうち重要なものについては暗号化（パスワード付きZIPファイル化）を行っています。 暗号化された添付ファイルを開くには、別に送信される「添付ファイル情報 お知らせメール」の本文中に記載されている「添付ファイル解凍パスワード」を使用する必要があります というのがありました。 疑問点 １．最初のメールと、次のメールの両方を盗聴すれば、暗号化は解除されてしまう。 ２．二つのメールが、プロバイサーのメールボックスの中にある時に情報を盗めば暗号化の意味が 無い。 ３．2つのメール情報を盗聴することが困難ならば、一つのメール情報を盗聴することも困難。 ４．よって、安全対策をとるなら、鍵は封書で郵送する必要がある。 と考えますが、情報を2つに分けるとどの程度安全性が向上するのでしょうか？ 単なる気休めのような気がしますが、安全性の根拠がお分かりの方、 教えていただければ幸いです。
- ベストアンサー
- その他（メールサービス・ソフト）
- AES と Rijndael
Rijndaelの参考文献（下記）では、AESとして採用されているものよりも鍵およびブロックの長さの種類が多く、鍵長、ブロック長は、それぞれ128,160,192,224,256ビットの5通りです。AESのものは、鍵長、ブロック長は、128,192,256ビットです。 128,160,192,224,256の最小公倍数は26880ですが、128,192,256の最小公倍数は768です。より広範囲のデータに対して暗号化の操作が行われるほうが解きにくくなると思います。より大きな最小公倍数を持つ複数の鍵で多重暗号化したほうがよいと思うのですが、最小公倍数が768のものを公式にAESとして採用して、最小公倍数が26880の参考文献にあるRijndaelを利用しなかったのは、どんな理由なのでしょうか？ それとも、安全性はあまり変わらないのでしょうか？ よろしくお願いします。 参考文献：The Design of Rijndael， AES - The Advanced Encryption Standard，Springer
- ベストアンサー
- ネットワーク
- MacOSX iOS バックドア パスワード無意味
ップル、法執行機関から「iPhone」パスコードロック解除要請 http://japan.cnet.com/news/service/35031942/ Apple製品の暗号化機能で利用されてるAESは数学的には数千年時間が無いと解読できないはずだったのに、 解除要請で解除できるってことは公式にバックドアが用意されてるんでしょうか？ TruecryptもMac版だけOS丸ごとの暗号化機能が削除されてるし、Macでは安全な暗号化ソフトを作ってはいけない決まりとか契約があるんでしょうか？ 詳しい方がいたら教えてください。
- ベストアンサー
- Mac
- 総当り攻撃と電力消費
暗号化されているデータを総当り攻撃で解くとします。 256ビット長の鍵についての総当り攻撃が消費電力100wのコンピュータで1秒で解けるとする。 このとき、2段階の暗号化したものを総当りで解くには、 １００W*1秒 ＋ １００W*１秒＊２＾２５６ ＞ １．１５＊１０＾７７Ws このとき、３段階の暗号化したものを総当りで解くには、 １００W*1秒 ＋ １００W*１秒＊２＾２５６ ＋ １００W＊1秒＊２＾５１２ ＞ １．３４＊１０＾１５４Wｓ 世界の発電量は ２０２８２１５５ (100万ｋWh) ＝ ７．３＊１０＾１９ Ws くらいなので、 3段階の多重暗号化をしておけば、消費電力の面から見て安全であるといえますか？
- ベストアンサー
- ネットワーク
- LAMPを使用したログインシステムの暗号化について
LAMPを使用したログインシステムの暗号化についてご教授ください。 アマゾンのような会員制ネットショップの開発を考えております。 DB（MYSQL5）へ会員情報を保存し、会員がログインできる仕様予定です。 要件 **************************** ．MYSQLへ保存する会員情報は「会員番号以外」の全フィールドをBlowfish方式,salt使用で暗号化して保存したい （安全であれば暗号化方式にはこだわりません。） 目的：万が一会員情報データが流出した場合の被害を軽減したい ・会員テーブルのフィールド構成は5列 「会員番号、ログインパスワード、クレジットカード番号、住所、電話番号」 質問 *************************** 会員(仮に鈴木さん)は前月にログインパスワード「1234」で会員登録しました。 鈴木さんがログインパスワード「1234」を忘れた場合の手順は以下の手順で新パスワードに変更します。 (処理１) システム側が仮パスワード「tmp0000」を作成し、会員テーブル内の鈴木さんのログインパスワードを「tmp0000」で上書きします。 (処理２) 鈴木さんへ仮パスワード「tmp0000」をメールで送信 (処理３) 鈴木さんが「tmp0000」でログインして会員テーブル内の鈴木さんのログインパスワードを新パスワード[new1111]で上書きします。 この場合、会員テーブル内の鈴木さんレコードのログインパスワード以外の列(クレジットカード番号、住所、電話番号) は「1234」で暗号化されたままです。 【質問１】 処理１と処理３のタイミングでパスワード以外のフィールドは一旦復号化して再度暗号化、保存の手順が必要と思うのですが、元の復号キーが不明でも可能でしょうか？ 復号しないと鈴木さんは住所、電話番号等の再入力が必要になってしまうと思いますので・・・ 【質問２】 質問１の回答が可能な場合、どのような処理が必要でしょうか？ 【質問３】 質問１の回答が不可能な場合、データが流出した場合の被害を軽減する代替え案は何かありますでしょうか？ 住所、電話番号等は平文で保存すれば問題ないのかもしれませんが、リスキーなので躊躇します。 アマゾンや楽天等でパスワードを変更したときも住所等の再入力は必要なかったように記憶しています。 【質問４】 予想でも結構なのですがアマゾンや楽天等は住所などのフィールドは平文で保存しているのでしょうか？ 【質問４】 ログインシステム開発時のDB暗号化の実装方法・概念等、のわかる 書籍やWEBページ等ありましたら教えてください。 また、この質問全体をとおして私に諸先輩方からアドバイス等あれば宜しくお願いします。
- 締切済み
- PHP
- ＬＩＮＥは安全なアプリ？？
韓国製 アプリ＜ＬＩＮＥ＞ですが、 韓国の国家情報院（旧KCIA）が、 無料通話・メールアプリ「LINE」を傍受し、 収拾したデータを欧州に保管、分析していると、 韓国政府のサイバーセキュリティ関係者が、 日本の内閣情報セキュリティセンター（NISC）との 協議の場であっさり認めたとありました。 ＜ニュースソース＞ http://facta.co.jp/article/201407039.html 上記に対して 韓国のIT企業ネイバーの 日本法人（子会社）のLINE代表の森川氏は、 ・通信内容を傍受は、事実無根！ ・国際基準を満たした最高レベルの暗号技術を 使っているから傍受は不可能！ ＜森川氏 コメント＞ http://moriaki.blog.jp/archives/1988243.html ・本当に安全なのでしょうか？ ・事実無根なら 何故、「抗議」だけで済ますのでしょうか？ ・訴えたりしない理由でもあるのでしょうか？
- ベストアンサー
- LINE
- sendmailにより送信されるメールの暗号化
この度はお世話になります。 早速ですが、私の所属する会社では、業務の一環として、 SSL対応のレンタルサーバに設置されたcgiを用いて、 下記の方法で当社ウェブサイト利用者の個人情報を取得しております。 (1)サイト利用者によりブラウザ上の入力フォームからwebサーバへ送信される。 (2)webサーバのsendmailを用いてサイト運用担当者へ送信される。 上記(1)は、SSLを利用することにより、送信されるデータの暗号化がなされていますが、 この度、プライバシーマークの現地審査結果として、 (2)にて平文で送信されるメールが盗聴されるリスクを回避するよう指摘を受けました。 つきましては、前述のメール盗聴リスクを回避する手立てとして、 どのような対応方法があるのか、ご教授頂きたく存じます。 質問に関しましては、以上です。 以下、参考までに、本件について私が自力で調べたものの、 結論に至らず挫折した、或いは保留している経緯を記します。 まず、PGPを利用して、下記のような暗号/複合をすることにより、 メールの盗聴リスクを回避できないかどうか調べました。 (a)webサーバからsendmailを用いて送信されるデータを暗号化する。 (b)前項のデータをサイト運用担当者が受信して複合化する。 結果、(b)はOutlook Express等のメーラにプラグインを導入することで、 実現することが可能であることは理解できましたが、 (a)の具体的な実現方法を理解するには至らず、挫折しました。 次に、前述(a)を提供するサービスがないか検索しました。 その結果、下記のレンタルサーバが、同様のサービスを提供中であることがわかりました。 https://www.ssl-on.net/index.html ただ、もし現在利用中のレンタルサーバの利用を止めて、 他のレンタルサーバを利用するのであれば、 前述のようなレンタルサーバを複数比較検討したく考えているのですが、 同様のサービスを提供できるレンタルサーバが他に見つからなかった為、 この手立ては一旦保留としてあります。 挫折した、或いは保留している経緯に関しましては、以上です。 皆様、宜しくご教授の程をお願い申し上げます。
- ベストアンサー
- ネットワーク
補足
ご指摘ありがとうございます。 私が参考にした意見は、 http://www.gabacho-net.jp/whims/whim0039.html にあるような、平文に見える暗号が良いと言う主張だったのでしょうか？ そうならば、誤解でした。 正直、平文に見える暗号を使うほうが良い。と書いて欲しかったです。 また、自動的に俳句を作るソフトもあるようなので、 AESで暗号化したものを１６進数の列と見て、 適当な規則で俳句の列に変換したら、不自然だけれど 一応、平文に見える暗号になるかな？？