ネット上に大学や情報処理学会が発表している資料で公開鍵暗号の説明に公開鍵(public key)/秘密鍵(secret key)としているものがありますが、公開鍵暗号のprivate keyのことをsecret keyとも呼ぶのは日本以外でも一般的なのでしょうか？秘密鍵配送問題の説明で秘密鍵(secret key)で署名などとしてある資料もあり、初学者の混乱の原因になっているような気がします。 - ockeghem page
私の手に余る質問でしたのでfacebookで呼びかけたところ、神戸大学の森井先生が回答くださいました。暗号学の専門家ならpublic key/private keyと書くところだが、応用系の論文であればsecret keyと書く場合もあるだろうとのことです。以下は、森井先生のコメントの引用です。読者限定の会話でしたので引用の許可はいただいています。 （追記） Twitterにて、暗号の専門家にもsecret keyを用いる用例はある（多い）というご指摘をいたただきました。その判断は私にはできませんが、いずれにせよ、公開鍵暗号のprivate keyをsecret keyと書くケースはそれなりにあるということのようです。 -- アカデミック（今、流行り？の学術的）には、public key/private keyです。何の注釈もなくsecret keyと書くと共通鍵暗号の共通鍵をイメージしま
QUICむけにAES-GCM実装を最適化した話 (1/2)
4月末に、会社のほうで「Can QUIC match TCP’s computational efficiency?」というブログエントリを書きました。我々が開発中のQUIC実装であるquiclyのチューニングを通して、QUICのCPU負荷はTLS over TCP並に低減可能であろうと推論した記事です。この記事を書く際には、Stay Homeという状況の中で、手元にあった安いハードウェアを使ったのですが、その後、10gbe NICを入手し、ハードウェアによるUDP GSOオフロード環境でのパフォーマンスを確認していくと、OpenSSLのAES-GCM実装がボトルネックになることがわかってきました。 TCP上で通信するTLSでは、一般に、データを16KB単位でAEADブロックに分割して、AES-GCMを用いてAEAD暗号化します注。一方、UDPを用いるQUICでは、パケット毎にAES-GC
)
ソルト (暗号) - Wikipedia
上のテーブルで示したように、ソルトの値が異なると、平文のパスワードが同じであっても、作られるハッシュ値はまったく別になる。 加えて、攻撃者がハッシュ値を事前に計算しておくことも難しくなるため、辞書攻撃の効果も低減できる。ただし、よく使われるパスワードや、簡単に推測できるパスワードに対しては、ソルトは効果がない。 よくある誤用[編集] ソルトの再利用[編集] プログラマがパスワードをハッシュ化する際に毎回同じソルトを使用するケース。 この場合でも、既存のレインボーテーブルを無効化することはできる（ソルトの値が適切であれば）。ただし、広く使われている製品にソルトがハードコーディングされると、そこから抽出したソルトを使って新しいレインボーテーブルを生成できてしまう。 また、ソルトが固定だと、パスワードが同じユーザーはハッシュ値も同じになってしまう（ハッシュ値を作る際にユーザ名を混ぜ込んでいる場合
楕円曲線暗号アルゴリズムを理解する｜TechRacho by BPS株式会社
お久しぶりです。yoshiです。みなさん、夏を満喫していますか？ 私は溶けそうです。日本の夏はとってもあつい。 覚えている方がいるかどうかは分かりませんが、以前私はRSA公開鍵暗号アルゴリズムを理解するという記事を書きました。今回はその続編（？）です。 楕円曲線について 楕円曲線、という言葉を事前知識無しで見ると、 多分こんな画像が脳裏に浮かぶと思います。違います。 楕円曲線の楕円は楕円積分から現れた言葉で、楕円積分は文字通り楕円の弧長などを求める方法なので全くの無関係とは言えませんが、少なくとも楕円曲線と楕円は別の図形です。楕円のことは忘れましょう。 実際の楕円曲線は、例を示すと以下のような曲線です。 一般化すると (ただし または ) という式で表されるこのような曲線をワイエルシュトラス型楕円曲線と呼びます。ワイエルシュトラス型、と付いているのは他のパターンもあるからで、 こんな形の楕
itamae-plugin-resource-encrypted_remote_file を作った - くりにっき
itamae-plugin-resource-encrypted_remote_file (0.0.1): encrypt secret data, and forward decrypted file to remote. http://t.co/te4q9nPRtV— RubyGems (@rubygems) 2015, 5月 9 github.com 概要 暗号化されているファイル復号化してサーバに転送するための itamae で Resourceプラグインです 作った経緯 アプリのデプロイサーバの構築をitamaeでやっていたのですが、デプロイユーザのsshの秘密鍵をどうサーバに転送するかという問題がありました。 普通にやるのであれば remote_file でよかったのですが、そのためには秘密鍵をそのままリポジトリにコミットする必要があり悩ましいところでした 社内リポジトリでかつ
クラウドを支えるこれからの暗号技術 - Cybozu Inside Out | サイボウズエンジニアのブログ
サイボウズ・ラボの光成です。 私は先月のDevelopers Summit 2015で、「クラウドを支えるこれからの暗号技術」という講演をいたしました。そのとき、近いうちに詳細なテキストを公開する予定と申し上げました。その準備ができましたので報告いたします。 講演と同じタイトル『クラウドを支えるこれからの暗号技術』のpdfはgithubから取得できます。 2015/6/21追記。このテキストが秀和システムから出版されました。 表題の講演は、主に2000年に入ってから登場した新しい暗号技術の紹介がメインです。そのときのプレゼン資料は3月の時点で4万5千ビューを超えていて、デブサミ資料の中でもかなり上位に入る閲覧数のようです。技術者の暗号に関する関心が高いことを伺わせます。 しかし一般向けの暗号のテキストは、公開鍵暗号の一つであるRSA暗号やElGamal暗号ぐらいしか詳しい原理が記されていな
/dev/random - Wikipedia
/dev/random はUnix系オペレーティングシステム (OS) における擬似デバイスの一種であり、乱数生成器として機能する。デバイスドライバその他の情報源から集めた環境ノイズを利用して、真の乱数性を得るのが目的である。全てのUnix系OSが /dev/random およびそれに類する機能を実装しているわけではない。また、それぞれの実装が、同じように振舞うわけでもない。このような擬似デバイスを実装した最初のOSはLinuxであった。 Linux[編集] このようなOSレベルの乱数用デバイスを実装した最初のOSカーネルが Linux であった。設計にあたっては、いかなる生成法（暗号学的ハッシュ関数など）にも脆弱性が発見され得る可能性があるという仮定を置いており、そのような脆弱性に耐性を持つよう設計されている。 この実装では、エントロピープールにおけるノイズのビット数の予測を常に保持する
cloudpack night #7 に参加しました / EC2 における AES-NI の話 - 水深1024m
先日行われた cloudpack night #7 に参加しました。 http://www.zusaar.com/event/978005 主催された cloudpack の id:yoshidashingo さんのまとめはこちら。 http://d.hatena.ne.jp/yoshidashingo/20130826/1377527798 新卒入社5ヶ月目、社会人なりたてのぺーぺーではあるのですが、 僭越ながら若手 LT 枠で発表させていただきました。 EC2 環境における AES-NI の性能について紹介しました。 AES 暗号化するならインスタンスをよく見たほうが良いですよ、という話です。 LT の資料だとうまくまとまらない気がしたので記事という形でまとめておきます。 AES-NI とは 詳細はここで説明するよりググったほうが良いです。 一言で言うと AES 暗号の CPU サポー
結城浩「新版暗号技術入門 秘密の国のアリス」を読んでる - There's an echo in my head
新版暗号技術入門 秘密の国のアリス 作者: 結城浩出版社/メーカー: ソフトバンククリエイティブ発売日: 2008/11/22メディア: 単行本購入: 46人 クリック: 720回この商品を含むブログ (81件) を見る すごくわかりやすいし面白い。 共通鍵暗号 事前に共有しておいた秘密鍵を使って暗号化・復号化する方式 今のところAES-256-CBCが安全 AES（やDES）は固定長のブロックを暗号化するための技術 ブロック暗号という ストリーム暗号 CBCやCTRは自由長のバイト列をブロックに分割してブロック暗号に渡す方法。モード CBCは前ブロックの結果（最初は初期化ベクトル）を対象のブロックにXORしてから暗号化する 並列処理はできない 最後のブロックはそれ以前の全てのブロックの影響を受けるので、最後のブロックだけ切り取ってMACに使うことができる CTRはnonceをもとに作った
高木浩光＠自宅の日記 - 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと
■ 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと 「コンピュータセキュリティを基礎から」というと、暗号の解説、特に共通鍵暗号と公開鍵暗号の違いからなどといった解説をよく目にする。昔は専門の方によって注意深く書かれていたのに対し、ここ何年かはひどい状況になっている。先月、宮崎で開かれたSCIS 2008の席でも暗号研究者の方々との雑談でそういう話になった。私は暗号は専門でないのでその話題は迂闊に書けないできたが、このところの巷の誤り解説の氾濫ぶりは目に余るものがある。 最もひどく蔓延っていてしばらく消えそうにない間違い解説の典型例は次だ。 「公開鍵で暗号化したものを秘密鍵で復号するのと同様に、秘密鍵で暗号化したものを公開鍵で復号できるようになっている。」 事例1: 日本ベリサイン株式会社による公開鍵暗号方式の解説 このような共通鍵暗号方式の問題点を解決する暗号方式が、公開鍵暗号方式
クラウドを支えるこれからの暗号技術
SSII2021 [TS3] 機械学習のアノテーションにおける データ収集 〜 精度向上のための仕組み・倫理や社会性バイアス 〜SSII
LINE DEVELOPER DAY 2016 開催のお知らせ « LINE Engineers' Blog
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog saegusa2017-04-16Yoshihiro was a network engineer at LINE, responsible for all levels of LINE's infrastructure. Since being named Infra Platform Department manager, he is finding ways to apply LINE's technology and business goals to the platform. こんにちは。LINEでネットワークやデータセンターを担当している三枝です。2017年1月にJANOG39で登壇する機会を頂きましたので、今回
LINE「独自暗号化」のメリットと安全性について
LINEが使用している「独自の」暗号化手法について、情報が一部開示（参照：LINEの暗号化について « LINE Engineers' Blog）され、Twitterでもやりとりをしたので、まとめてみる。 ■なぜTLSを使わないか TLSではなく、１パスのメッセージ暗号化を使っている理由については、Adopting SPDY in LINE – Part 2: The Details « LINE Engineers' Blogに以下のような記載があり、TLSを使うことによるレイテンシの増加を懸念しているためと考えられる。 3G mobiles networks normally operate at slow speeds. （中略）If the connection changes modes when the user sends a message, we are forced t
GitHub の公開鍵で暗号化する ghcrypt の処理内容 - こせきの技術日記
GitHub のユーザ名を指定してファイルを暗号化するツール ghcrypt を作った - こせきの技術日記 の続き。甘い物のことは忘れて、もうちょっとちゃんと書きます。 いくつかバージョンアップを行いました。暗号化はAESで行い、AES のパスフレーズを公開鍵で暗号化するようにしました。現在のバージョンは 0.5 です。 https://github.com/koseki/ghcrypt ghcrypt ファイル名 githubユーザ名(受信者) ghcrypt ファイル名.enc.tar githubユーザ名(送信者)で、暗号化・復号化を行います。 動作環境 OpenSSH の 5.6 以降が必須です。OpenSSL は 0.9.8 あたりで動作確認をしてます。 OpenSSH 形式の公開鍵を OpenSSL で使える PKCS#8 にエクスポートするために、 OpenSSH 5.6
module OpenSSL::PKCS5
クラスの継承リスト: OpenSSL::PKCS5 要約 OpenSSL PKCS#5 関連の機能を集めたモジュール モジュール関数 pbkdf2_hmac(pass, salt, iter, keylen, digest) -> String pass と salt から共通鍵暗号の鍵および IV(Initialization Vector) を生成します。 OpenSSL::PKCS5.#pbkdf2_hmac_sha1 と異なり任意の ハッシュ関数を利用できます。 返り値の文字列から鍵と IV に必要なバイト数を切り出して利用します。 この関数は OpenSSL 1.0.0 以降でなければ利用できません。 [PARAM] pass: パスワード文字列 [PARAM] salt: salt 文字列 [PARAM] iter: 鍵および IV 生成時のハッシュ関数の繰り返し回数 [PAR
パスワードのハッシュに使うべきPBKDF2、Bcrypt、HMACの各言語実装一覧 - このブログはURLが変更になりました
いつも忘れるのでメモ。 元ネタ:Are you sure SHA-1+salt is enough for passwords? 日本語訳:「SHA-1+salt」はパスワードに十分だと思いますか？ こうしたスキームをいくつか選ぶことができる： PBKDF2 http://en.wikipedia.org/wiki/PBKDF2 Bcrypt http://www.openwall.com/crypt/ HMAC http://en.wikipedia.org/wiki/HMAC 各選択肢はそれぞれの強みと弱みがあるが、これらは全てSHA1+saltのような汎用ハッシュのインプリメンテーションより、はるかに強力だ。 ということで、各言語での実装を調べてみた。実装が正しいかは調べてない。別実装もあるかもしれない。 言語 PBKDF2 Bcrypt HMAC Java Bouncy Castl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Curipha Networks
Googleのニューラルネットワークが自ら暗号化通信を考案
How to use RSA in Linux kernel
GitHub - herumi/ango
