暗号の歴史と現代暗号の基礎理論（RSA, 楕円曲線）-前半- - ABEJA Tech Blog
はじめに このブログに書かれていること 自己紹介 注意 Part1 古典暗号 2つの暗号方式 スキュタレー暗号 アルゴリズムと鍵 シーザー暗号 原理 頻度分析 アルベルティ暗号 ヴィジュネル暗号 如何にしてヴィジュネル暗号は破られたか Part2 近代暗号 エニグマ エニグマの登場 エニグマの基本構造 如何にしてエニグマは突破されたか 前提条件 必ず異なる文字に変換される性質を利用 ループを利用 まとめ 参考文献 採用情報 はじめに このブログに書かれていること 前半 古代暗号から始まる暗号の歴史 エニグマの構造と解読法について 後半（後半ブログは こちら） RSA暗号の基本 楕円曲線暗号の基本 自己紹介 こんにちは！株式会社ABEJAの @Takayoshi_ma です。今回のテックブログですが、ネタに5時間程度悩んだ挙句、暗号を取り上げることにしました！暗号化手法の解説にとどまらず、そ
TLS暗号設定ガイドライン 安全なウェブサイトのために（暗号設定対策編） | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。 本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
クラウドを支えるこれからの暗号技術
『クラウドを支えるこれからの暗号技術』 本書は公開鍵暗号に続く、新しい暗号技術を紹介します。 対象読者 『暗号技術入門』（結城浩）を読んで最先端暗号理論はどうなってるのだろうと興味を持った方 「入門書に載っているRSA暗号は安全ではないので使ってはいけない」ということを知らない方 Hash(secret key||message)で認証してはいけない理由（SHA-2とSHA-3の違い）を知りたい方 楕円曲線暗号の楕円曲線を直感的に把握したい方 最近ちょいちょい聞く「準同型暗号」って何だろうと思っている方 楕円曲線といえばy2 = x3 + ax + bという式が唐突に出てくるけど何故なのと疑問に思った方 EdDSAって何? ECDSAの書き間違い?と思ったらEdwards曲線が出てきて、それ何だろうと思った方 暗号で使われる数学の話をきちんと理解したい方 などなど。 購入 秀和システム 正
「第6期サイボウズ・ラボユース成果発表会」開催 - Cybozu Inside Out | サイボウズエンジニアのブログ
サイボウズ・ラボの光成です。3月30日に第6期サイボウズ・ラボユース成果発表会を開催したのでその報告をします。 サイボウズ・ラボユース サイボウズ・ラボユースとは日本の若手エンジニアを発掘し、育成する場として2011年に設立されました。 ラボユース生が作りたいものをサイボウズ・ラボの社員がメンターとしてサポートします。 開発物の著作権は開発者本人に帰属します。基本的にオープンソースとして公開するのが条件です。 去年からは最大1年の通年募集となっています。 今年は3月で修了される3人の方と、現在開発継続中の4人、ラボユースOBから一人の発表がありました。 修了生の発表 緑川志穂さん 緑川さんは楕円曲線計算ライブラリecpyのC++による高速化というテーマで発表しました。 メンターは私です。 去年の中間発表ではペアリング暗号ライブラリのPython実装を紹介しましたが、今年はC++で開発したラ
RSA鍵の生成時に確率的素数判定法を使って問題ないのか - hnwの日記
前回記事「RSA公開鍵から素数の積を取り出す方法」でも紹介しましたが、RSA鍵の生成には巨大な2つの素数p,qが必要です。近年一般的に使われている2048bit RSA鍵の場合、p,qの大きさは1024bit、10進で約308桁の数になります。 このRSAのアルゴリズム中ではpとqを法としたフェルマーの小定理（正確にはその拡張であるオイラーの定理）を利用しています。つまり、pとqが合成数だとRSA暗号の大前提が狂ってしまいますので、pとqには確実に素数を選ぶ必要があります。 ところで、OpenSSLのRSA鍵生成の実装では、pとqの素数判定にMiller-Rabin素数判定法が用いられています。Miller-Rabin素数判定法は片側誤りの確率的アルゴリズムで、「たぶん素数」「確実に合成数」の判定ができるようなものです。pとqの素数性が重要なのに、その判定に確率的アルゴリズムを使っても問題
妻に公開鍵暗号を教えてみた - 西尾泰和のはてなダイアリー
何気なく放送大学をつけていたら公開鍵暗号の話をしていた。 妻「この話、何度聞いてもわかんないのよね」 僕「え、どこがわからない？どこまではわかってる？」 妻「平文はわかるけど、鍵を共有するとか秘密にするとか、署名するとかがよくわからない」 僕「あー、鍵に例えているのが逆効果なのか」 「鍵」をNGワードに指定 僕「じゃあ『鍵』という言葉を使わずに説明してみよう。暗号って『平文を暗号文に変換する方法』で伝えたい文章を暗号文に変えて送り、受け取った人はそれに『暗号文を平文に戻す方法』を使って元の文章を得るわけだ。その目的は、途中の通信文が敵に取られたりしても通信の内容がバレないようにするため。」 妻「うん」 僕「昔の暗号化の方法は、片方の方法がわかるともう片方の方法も分かった。例えば『アルファベットを後ろに1個ずつずらすと平文に戻せます』って教えてもらったら、『なるほど、前に1個ずつずらせば暗号
Go言語と暗号技術（AESからTLS）
最近マスタリングTCP/IP SSL/TLS編や暗号技術入門を読んでいた．理解を深めるためにGo言語で標準のcryptoパッケージを触り/実装を読みながら読んだ． cryptoパッケージは他の標準パッケージと同様に素晴らしい．Go言語にはどのような暗号化手法が実装されているのか実例を含めてざっとまとめる．なお本文に書ききれなかったものを含め全ての実装例はtcnksm/go-cryptoにある． 共通鍵暗号 まずは共通鍵暗号をみる．共通鍵暗号は暗号化と復号化に同じ鍵を用いる暗号化方式である．共通鍵暗号はブロック暗号とストリーム暗号の2種類に分けることができる．ブロック暗号は特定の長さ単位で暗号化を行う方式であり，ストリーム暗号はデータの流れを順次処理していく方式である． Go言語にはブロック暗号としてDES（Data Encryption Standard），DESを繰り返すtriple-D
Zabbix3.0注目機能「通信暗号化」、「管理画面の改善」、「監視結果予測機能」紹介 ～Zabbix Conference 2015参加レポート～ | Tech-Sketch
Zabbix3.0注目機能「通信暗号化」、「管理画面の改善」、「監視結果予測機能」紹介 ～Zabbix Conference 2015参加レポート～ OSSの統合監視ソフトウェア「Zabbix」の国際カンファレンス「Zabbix Conference 2015」が北欧の国ラトビアの首都リガで9/11,12の2日間開催されました。このカンファレンスに参加し、Zabbix3.0の最新情報など聞いてきたのでその模様をお届けします。TISからは、TIS独自のZabbixに対する取り組みである"HyClops"に関して発表してきたので、その内容についても紹介します。 Zabbix Conferenceとは？ こちらの記事でも紹介されているように、Zabbixの開発元企業であるラトビアの首都リガにあるZabbix社主催で年次開催されている国際カンファレンスです。世界各国のZabbixユーザ、コミュニテ
DockerのMySQLデータコンテナを暗号化する。 - Qiita
すごくマニアックな要件過ぎて、需要があるかどうかは不明なのですが、 ネットを探してもほとんど情報が見つからなかったので、備忘録代わりに書いておきます。 現在の状況 まず、既存の構築済みDockerコンテナはこんな感じ。 MySQLコンテナはCentOSです。 MySQLのデータを別のDockerコンテナに分けています。 しかし、データのみの持ち出しが容易な反面、 tar等のコマンドでデータを別の人に持ちだされてしまうと、 セキュリティが心配！という声が有りました。 というわけでなんとかデータ部分だけを暗号化してくれ、というオーダーを受け、 色々試行錯誤してみたわけです。 そもそもMySQLの暗号化は どうも色々調べると、MySQLの場合、レコードに挿入するデータ自体を暗号化することが多いらしく、そういった記述は多々見つかりました。 7.11.2. 暗号化関数と圧縮関数 http://mys
etcd/consulに認証情報を安全に保存する
etcd/consulに認証情報を安全に保存する 分散Key-Valueストアとしてetcdやconsulの利用が増えている．ここにアプリケーションの設定値などを保存し，各ホストからそれらを購読して利用する． また，X-as-a-Serviceといった外部サービスの利用も多くなってきた．その場合API Tokenやパスワードといった認証情報が必要になる．PaaSやTwelve-factor的なアーキテクチャを採用する場合は，それらの値を環境変数に保存して利用することが多い（危険であるという意見はある．cf. http://techlife.cookpad.com/entry/envchain）．etcdやconsulといった分散Key-Valueストアの利用を前提としたアーキテクチャでは，そこに外部に漏らしたくない設定値も一緒に保存してしまうのがシンプルになる． しかし，そういった設定値を
パスワードのハッシュに使うべき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
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で登壇する機会を頂きましたので、今回
knife-solo_data_bagを使ってEncrypted Data Bagで暗号化したファイルを配布する - ＼＼\\٩( 'ω' )و //／／
knife-solo環境でリモート側のサーバーに暗号化したファイルを配布する方法についてメモ。 対象となるケース knife-soloを使ってchef-soloを実行している リモート側にローカルで暗号化したファイルを転送したい 実行環境 ローカル側(knife-solo実行環境) OS: MacOS X 10.7.5 chef: 11.4.0 knife-solo: 0.3.0.pre2 リモート側(chef-solo実行環境) OS: Amazon Linux chef: 11.4.0 Data Bag chefにはdata bagというものがあってリポジトリ全体にわたって定義する必要のある情報を格納しておく仕組みがあります。大抵はユーザのアカウント情報を管理したりしているのではないでしょうか。 Encrypt a Data Bag ユーザ名や公開鍵などはリポジトリにcommitしてお
CloudFlare: Goで書いた安全にデータをやりとりする仕組み - ワザノバ | wazanova
http://blog.cloudflare.com/red-october-cloudflares-open-source-implementation-of-the-two-man-rule 核ミサイルは、誤って、もしくは担当者が勝手に発射してしまわないように、二人一組で操作する仕組みになっていますが、それと同様に、かなりセンシティブなデータのやり取りも複数人の関与/確認が有効とされてます。CloudFlareがオープンソースで提供したRed Octoberは、それを実現するために、Goで書かれた暗号化 & 解読サーバです。サーバは、一定期間内に、あらかじめ設定された認証ユーザの数だけの証明書を預かると、従前に暗号化されたものを解読するという仕組みです。 1) How to use it Red Octoberサーバのセットアップは簡単。ローカルで読めるパスとSSLキーのペアがあればよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - bichenkk/coinmon: 💰 The cryptocurrency price tool on CLI. 🖥
プライヴァシー重視型の「Uber的」サーヴィスは生まれるか──スイスの研究チームが開発したシステムの実力
GitHub - google/wycheproof: Project Wycheproof tests crypto libraries against known attacks.
暗号文のままで計算しよう - 準同型暗号入門 -
Encrypting Logs on Their Way to Elasticsearch Part 2: TLS Syslog - Sematext
Encrypting Logs on Their Way to Elasticsearch - Sematext