「ハッシュ関数」を含む日記 RSS

はてなキーワード: ハッシュ関数とは

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

Web ブラウザとは (Chrome, デベロッパーコンソール, alert)

はじめてのHTML (VSCode, HTML, Emmet)

さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)

HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)

はじめてのJavaScript (JS, ES6, エラー)

JavaScriptでの計算 (値, 算術演算子, 変数, 代入)

JavaScript論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)

JavaScriptループ (ループ, for)

JavaScriptコレクション (コレクション, 配列, 添字, undefined)

JavaScript関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)

JavaScriptオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)

はじめてのCSS (CSS, セレクタ, background-color, border)

CSSを使ったプログラミング (transform, id, class)

Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)

診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)

診断機能組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)

ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)

Linux開発環境構築コース

LinuxというOS (VirtualBox, Vagrant, Ubuntuインストール, OS, CUIの大切さ)

コンピューター構成要素 (ノイマンコンピューター, プロセス, lshw, man, ps, dfの使い方)

ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)

標準出力 (標準入力標準出力標準エラー出力パイプgrep)

vi (vimtutor)

シェルプログラミング (シバン, echo, read, 変数, if)

通信ネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)

サーバークライアント (tmux, nc, telnet)

HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

GitHubウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)

イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)

GitとGitHub連携 (git, ssh, clone, pull)

GitHubへのpush (init, add, status, インデックス, commit, push, tag)

Gitのブランチ (branch, checkout, merge, gh-pages)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)

集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)

アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)

ライブラリ (ライブラリ, パッケージマネージャー, npm)

Slackボット開発 (slack, mention, bot)

HubotとSlackアダプタ (hubot, yo)

モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)

ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)

同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)

例外処理 (try, catch, finally, throw)

HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsイベントループ, リスナー)

ログ (ログ, ログレベル)

HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)

HTMLフォーム (フォームの仕組み, form, input)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)

認証利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)

Cookie を使った秘密匿名掲示板 (Cookie, Set-Cookie, expire)

UI、URI、モジュール設計 (モジュール設計, フォームメソッド制限, リダイレクト, 302)

フォームによる投稿機能の実装 (モジュール性, textarea, 303)

認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)

データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)

トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)

削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)

管理者機能の実装 (Web サービス管理責任, 管理者機能の重要性)

デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)

脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)

XSS脆弱性対策 (XSS, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)

ExpressのAPI (app, Properties, Request, Response, Router)

GitHubを使った外部認証 (Passport, OAuth)

スティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)

継続的インテグレーション (CircleCI)

クライアントフレームワーク (Webpack, Chrome 以外のブラウザでもES6)

DOM操作フレームワーク (jQuery, jQueryアニメーション, this)

AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)

WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)

RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)

データモデリング (リレーショナルモデル, 正規化)

テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)

インデックス (インデックス, 複合インデックス, Bツリー)

集計とソート (SUM, COUNT, ORDER BY, GROUP BY)

「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計モジュール設計、MVC)

認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)

予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)

予定とユーザーの一覧の表示 (非同期処理, Promise, then)

出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)

出欠とコメント更新 (Promiseチェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2016-01-05

[][][][]

原理から学ぶネットワーク・セキュリティ - 第4回 ハッシュ関数:ITpro

同じ人がいったんパスワードを変更して,再び元に戻してもshadowファイルソルトのおかげで元には戻らず,パスワードが元と同じものとは,設定者以外には分からないのです。


Googleで以前使用したパスワードを設定したいなら! - pochi-pの絵日記

皆さんももしGmail等を使っていてGoogleパスワードを以前のものに戻したくなったら、是非「100回無関係パスワードに変更して、それから以前のパスワードに変更」してみてくださいね

2015-12-19

[][][]

bitcoin・blockchain

ビットコイン - Wikipedia


はてなブックマーク - 新井俊一のソフトウェアビジネスブログ: 今話題のブロックチェーンとは何なんだ? 部外者の技術者として考察してみる。

はてなブックマーク - イーサリアム共同創業者Vitalik Buterinが語る、ブロックチェインの真の価値 | ビットコインニュースのBTCN

「ビットコインはインターネットの再来だ」

ビットコインがブロックチェーンより重要な理由 | TechCrunch Japan

ブロックチェーン技術は、蒸気機関や燃焼機関と同様に扱われるべき世紀の発明であり、金融界どころか、その外までをも変貌させてしまう可能性を秘めている。」

http://jp.cointelegraph.com/news/115873/what-is-the-reason-that-a-world-financial-institution-invests-in-a-block-chain-technology-as-a-favorite-of-the-fin-technical-center-all-togetherjp3

ロシアの政治家でIT起業家でもあるニコライ・ニキフォロフはブロックチェーンテクノロジーに注目


ハッシュ関数改ざんを検出する

http://itpro.nikkeibp.co.jp/article/COLUMN/20071031/286012/?ST=selfup&P=2



Amazon.co.jp: 仮想通貨革命 電子書籍: 野口 悠紀雄: Kindleストア

2015-10-15

LINE Engineers' Blog掲載された記事を読み解こうとして力尽きた

http://developers.linecorp.com/blog/ja/?p=3591

Letter Sealing って何でしょうか。私気になります

必要範囲で、原文を引用しています。原文は先に引用元アドレスと閲覧日時を記し、引用記法によって地の文識別できるようにしています

長すぎ;読まない

ECDHAES256-CBC 使ってみた。通信相手の認証については読み取れない。

暗号通信の流れ

図2 において、 Server のところで Re-Encryption (一度復号されて、再度暗号化されている) ことが明示されています

この図を素直に読むと、送信者からサーバーまでの通信路は暗号化されているものLINEサーバーが受信したところで復号されて平文で保存され、サーバーから信者までの通信路は暗号化されていると理解できます文脈から、この流れを変えたいのであると推測できます

SSL公開鍵暗号

http://developers.linecorp.com/blog/ja/?p=3591 より引用2015年10月14日 22時40分に閲覧:

加えて、LINEでは、仮に通信ネットワークの傍受が行われたとしてもメッセージを覗くことができないように、公開鍵暗号(public key encryption)方式を使っていますユーザーに対してLINEアプリ提供する際、暗号化ができる公開鍵のみをアプリに入れて提供し、ユーザー端末とサーバ接続されたときだけLINEサーバでのみ解析できる暗号化された安全チャネルを作ります。こうすることで、SSL(Secure Socket Layer)より軽く、LINEの全バージョンで使用できる安全暗号化を実現できます

SSL はすでに時代遅れの代物で、 2015年現在は皆さん TLS を利用されていることでしょう。 Web ブラウザSSL 2.0SSL 3.0 を有効にしているそこのあなた、今すぐ無効しましょう。

TLS では、公開鍵暗号方式共通鍵暗号方式電子証明書暗号学的ハッシュ関数といった複数暗号技術要素を組み合わせて安全通信路を確保しています

RSA代表される公開鍵暗号方式一般的AES代表される共通鍵暗号方式と比べて計算量が大きい、つまり重たい処理となります

このため TLS では、通信路を流れるデータ暗号化に共通鍵暗号を用いて、共通鍵の共有や相手の認証のために公開鍵暗号方式を用いるのが一般的です。

仮にメッセージ暗号化に RSA を用いているとしたら、 SSL より軽いという点をどのように実装しているのか気になります

http://developers.linecorp.com/blog/ja/?p=3591 より引用2015年10月14日 22時40分に閲覧:

ユーザー側のLINEアプリ(クライアント)には、サーバが発行したRSA鍵を使用してデータ暗号化に使う暗号化鍵値を共有します。この鍵を利用してデータ暗号化すると、第三者メッセージを見ることができなくなります

これは上で説明したとおり SSLTLS でも行っていることです。

RSA を用いているので安全であるという主張をしていますが、メッセージ暗号化に用いられている暗号スイートアルゴリズムの種類、鍵の長さ、ブロック暗号場合暗号利用モード、そしてハッシュアルゴリズムの種類)は、その通信路が安全である判断できるか否かを決める大切な情報です。

http://developers.linecorp.com/blog/ja/?p=3591 より引用2015年10月14日 22時40分に閲覧:

既存RSA方式秘密データの共有に使う安全方式ではありますが、鍵管理の面から見ると、ユーザー側の端末でそれぞれのRSA鍵をすべて管理しなければならないという問題があり、その代替手段としてDHを使用するようになりました。

DH および ECDH による共通鍵暗号に用いる鍵の交換は SSLTLS でも実装されており近年では広く使われていますSSL より軽いと主張し、 SSLTLS公開鍵暗号方式以外の要素によって担保している安全性をどのように確保しているか不明実装に比べると、大きな改善です。

なお SSLTLS においては通信相手の公開鍵を全て管理する必要がないように、上で説明した電子証明書による公開鍵基盤 (PKI) の仕組みを利用しています

まり共通鍵暗号に用いる鍵の交換にどのような手段を用いるかは、鍵管理とは(ほぼ)独立です。

共通鍵暗号暗号利用モード

http://developers.linecorp.com/blog/ja/?p=3591 より引用2015年10月14日 22時40分に閲覧:

ここでメッセージ暗号化に使用している暗号アルゴリズムAES-CBC-256という方式で、現在一般に使われている暗号アルゴリズムの中で最も強度が高いと評価されています

メッセージ認証と組み合わせない CBCビット反転攻撃に弱いことが知られていますGCM ではデータ暗号化と認証を同時に行うためビット反転攻撃に耐性がありますAESGCM で利用するのは、 最近TLS実装では広く用いられており、 Googletwitter も利用しています

CBCCBC-MAC のようにメッセージ認証と組み合わせることでビット反転攻撃に強くなります

解決されない鍵管理問題

図6 のとおり、 ECDH共通鍵暗号に用いる鍵の交換を行うにしても通信相手の公開鍵必要です。 上で説明したとおり鍵管理という問題への解決策になりません。また公開鍵が本当に通信相手のものであることをどのように検証するのかについても不明です。通信相手の検証は、送信側では秘密の話を他の人に知られないように、受信側では他の人になりすまされないように、双方にて必要です。

ここから安易パターン想像ですが、通信相手の公開鍵情報LINE ユーザー情報の一部として LINE サーバー管理されており、必要に応じて安全通信路を用いて LINE サーバーから取得するようなものではないかと思います公開鍵情報のやりとりに用いられる通信路に正しく実装された TLS が用いられていて、サーバークライアントの両方が認証されていて、現在の水準から見て妥当レベル暗号スイートが用いられていることを願うばかりです。

公開鍵秘密鍵がどこでどのように保管されているのか気になります。各端末で保管するのが安全ですが、サービス要求として端末を乗り換えてもメッセージが読めるという条件を安易に満たすために秘密鍵LINE サーバーに預託していないことを祈るばかりです。

ECDH 鍵の生成は計算量が大きい処理であり質の良い乱数必要します。 PC に比べると非力なスマートフォンで生成した鍵の質をどのように担保しているのか気になります

2015年10月17日 10時16分追記

先ほど閲覧したところ、上記引用箇所の多くは削除されていました。公開鍵が本当に通信相手のものであることをどのように検証するのかについては明らかではないようです。 LINE サーバーが介在する形であれば、鍵をすり替えることで別のユーザーになりすますことが可能でしょう。または、 LINE アプリに何か細工をする方がより簡単でしょう。

ECDH 鍵はその場限り (ephemeral) という説明がないので Perfect Forward Secrecy ではないと考えられ、望ましくないという意見もあるようです。 LINE サーバーとの間に安全通信路を確立する目的で ECDH 鍵を用いる場合LINE サーバーが用いる秘密鍵漏洩は全てのユーザーに影響を与えうるため PFS は非常に重要です (TLS を用いた Web サーバーでも同様です) 。一方ユーザー間でメッセージ暗号化する場合ユーザー所有の ECDH 鍵についてはそのユーザーに影響が限定されます通信相手ごとに必要なその場限りの鍵生成とユーザー所有の ECDH 鍵を利用した鍵交換にかかる計算量と ECDH漏洩リスクを天秤にかけて PFS を採用しないという判断かもしれません。

通信の秘密という観点ではメッセージの内容だけではなく誰と通信たか (または、していないか) という情報も守りたくなります。宛先を LINE サーバー確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます

2014-07-15

http://anond.hatelabo.jp/20140715162504

めんどくさいからハッシュ関数で生成してる。

管理パスワードマネージャ任せだけど、無くしてもたいてい何とかなるのが便利。

マスターパスワード適当に決めて、サービス名(YahooとかHatenaとか)と組み合わせて変換した上で

ハッシュ関数にかけた下位何桁かを登録用に使ってる。

2013-03-23

プロテクト強化後のもふったーも予想以上に酷かった件(追記あり)

ことのあらまし
  1. Twitterクライアントもふったーの作者「TweetDeckのconsumer secret簡単に抜ける、終わってる」(http://blog.livedoor.jp/blackwingcat/archives/1760823.html)
  2. 別の誰か「もふったーのconsumer secretも簡単に抜ける」(http://d.hatena.ne.jp/kusano_k/20130318/1363640368)
  3. もふったーの作者「プロテクト強化した」(http://blog.livedoor.jp/blackwingcat/archives/1762970.html)

プロテクトかけたアルゴリズムを実装したバージョン差し替え」たなんて言われると本当に「プロテクト」がかかっているのか確かめてみたくなるのが人情というもの。というわけで、プロテクト強化後のもふったー(v0.9.6b)からconsumer secretが抜けるか試してみた。結論から言うと、あっけなく取り出せた。以下に手順を記す。

手順

動作がよくわかっていないアプリケーションを解析して仕様を明らかにすることをリバースエンジニアリングと呼ぶ。ソフトウェアリバースエンジニアリングは基本的に対象を逆アセンブルしてひたすら読むことによって行う(その補助に1命令ずつ実行してレジスターやメモリーの様子を観察することもある)。しかし、よっぽど小規模なものでなければオブジェクトコード全体を逆アセンブルして最初から最後まで読むなんてのは不可能だ。人間の読速度には限界があるし、時間も有限だからだ。そして、詳しい動作を知りたい部分というのは全体のごく一部であることが多いので全逆アセンブリを読むのには非常に無駄が多い。

からリバースエンジニアリングはいかに詳らかにすべき動作を行っているコードを絞り込むか(=読むべき逆アセンブリを少なくするか)が重要になる。

この場合も同様だ。TwitterGUIクライアントを頭から読むのは到底無理なので、どうやって解析すべきコードの範囲を狭めるかを考えた。それにはOAuth認証においてconsumer secretがどのような役割を果たすのかを知る必要がある。

OAuth認証で、consumer secretはそのままサーバーに送信されたりはしない。signatureの生成にHMAC-SHA1が使われ、その鍵にconsumer secretが使われる。HMACは次のように算出される。

HMAC (K,m) = H ((K ⊕ opad) ∥ H ((K ⊕ ipad) ∥ m))

ここで

である

まずはこのあたりから攻めようと思った。SHA-1計算はいくつか特徴的な定数が使われるので、そこからSHA-1計算に使われているであろう関数444190を特定する。この関数エントリーポイントに中断点(ブレークポイント)を設定してOAuth認証をさせるべくもふったーの「ブラウザ認証ボタンを押す。狙い通り中断するので関数を抜けるまで実行する。関数401100の4012DAに出た。少し下を見るとこのようになっている。

CPU Disasm
Address   Hex dump          Command                                      Comments
00401311  |.  33F6          xor     esi, esi
00401313  |   8D8C24 A40000 /lea     ecx, [local.54]
0040131A  |.  394C24 14     |cmp     dword ptr ss:[local.90], ecx
0040131E  |.  75 0E         |jne     short 0040132E
00401320  |.  3BF5          |cmp     esi, ebp
00401322  |.  73 29         |jae     short 0040134D
00401324  |.  0FB68434 A400 |movzx   eax, byte ptr ss:[esi+esp+0A4]
0040132C  |.  EB 21         |jmp     short 0040134F
0040132E  |   3BF5          |cmp     esi, ebp
00401330  |.  73 1B         |jae     short 0040134D
00401332  |.  8B5424 18     |mov     edx, dword ptr ss:[local.89]
00401336  |.  52            |push    edx                                 ; /Arg1 =  [LOCAL.89]
00401337  |.  8D8C24 FC0000 |lea     ecx, [local.33]                     ; |
0040133E  |.  8BD6          |mov     edx, esi                            ; |
00401340  |.  E8 CB4D0000   |call    00406110                            ; \mofooter.00406110
00401345  |.  83C4 04       |add     esp, 4
00401348  |.  0FB6C0        |movzx   eax, al
0040134B  |.  EB 02         |jmp     short 0040134F
0040134D  |   33C0          |xor     eax, eax
0040134F  |   34 5C         |xor     al, 5C
00401351  |.  888434 B80000 |mov     byte ptr ss:[esi+esp+0B8], al
00401358  |.  83C6 01       |add     esi, 1
0040135B  |.  83FE 40       |cmp     esi, 40
0040135E  |.^ 72 B3         \jb      short 00401313
00401360  |.  895C24 3C     mov     dword ptr ss:[local.80], ebx
0040134F  |   34 5C         |xor     al, 5C

が注意を引く。もしかしてこれはopadとのxorではないか?

00401351  |.  888434 B80000 |mov     byte ptr ss:[esi+esp+0B8], al

xorした結果を格納している。

先ほどの中断点は無効化しこのループを抜けた地点である401360まで飛ばす。この時点でesp+0B8を見ると次のようになっている。

Hex dump
64 2E 16 64|37 04 32 6D|0F 0D 26 29|3A 37 1F 2F|
18 69 6E 6E|0D 25 29 33|11 34 29 69|12 36 24 1E|
05 16 33 6A|04 3B 0E 68|7A 5C 5C 5C|5C 5C 5C 5C|
5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|

あとはこれと5Cとをxorすればconsumer secretが手に入る。終わり。

追伸

はてな増田スーパーpre記法で半角の<>が含まれていると投稿が出来ないのを早く直してください。

3/23 18:45追記

もふったーの作者から反応があった。「本気だったつもりのもふったーのデバッグ処理が残ってた」らしい(http://blog.livedoor.jp/blackwingcat/archives/1763951.html)。修正したとのことなので最新版(v0.9.6e)を見てみた。確かに若干変更されているが何の問題もない。SHA-1の呼び出しに中断点を設置して渡されているバイト列を見るだけ。

CPU Disasm
Address   Hex dump          Command                                  Comments
00401324  |.  8D4424 20     |lea     eax, [local.102]
00401328  |.  50            |push    eax                             ; /Arg1 = 
00401329  |.  E8 623A0400   |call    00444D90                        ; \mofooter.00444D90

ここでeaxが指すメモリーを見ると以下のようになっている。

01 23 45 67|89 AB CD EF|FE DC BA 98|76 54 32 10|
F0 E1 D2 C3|00 02 00 00|00 00 00 00|40 00 00 00|
40 4F 73 53|62 54 5C 7E|59 57 53 42|55 45 7A 57|
61 47 7A 5B|42 4F 7B 61|5D 66 5E 7A|42 7F 40 63|
79 66 05 55|79 4C 60 42|02 10 36 36|36 36 36 36|
36 36 36 36|36 36 36 36|36 36 36 36|36 36 36 36|

先頭32バイトゴミ無視して0x36とxorすればconsumer secretが得られる。

2012-05-05

http://anond.hatelabo.jp/20120505001212

なんか sha1md5 などによるハッシュ化に似たような話だね。

それらのハッシュ関数はその原理上、衝突することが避けられない。

その解釈と数値というものも、衝突という概念があり得るものなら別物の可能性があるし、無いなら両者は同じものでしょ。

2009-05-16

http://anond.hatelabo.jp/20090516121216

一言でバイナリツリーと言っても

実はレッドブラックだったり、

積み込みをどこで均一化するか?とかハッシュ関数はどうするか?

削除するときに木の均衡をどうするか?

メモリは事前に取るのか?キャッシュはするか?

など、B木といっても山ほどアルのでB木と書いても、山ほどやることはあるので

どんなB木かってのは、もっと書き込まないとわからないとおもう。

少なくともB木というだけでは何も説明できていないとおもう。

逆に、その程度なら、関数名を なんちゃらBtreeと書いておけば済むことだと思う。

最悪のツリー構造バイナリーツリーじゃぁ、ベクターの方がマシだし。

その部分をどうしたか?という部分が重要で、それって、日本語で書いた方が長くならない?

C言語コメントの方がわかりやすくない?

やっぱり、横暴かなぁ。バランスが難しいです。

2009-03-27

ハッシュ関数を調べた

http://anond.hatelabo.jp/20090326142330 の続き

pythonでベンチとった。試した方法は以下

  1. md5hex: md5を使う
  2. crc32x4: 4分割してそれぞれcrc32にかけてつなぐ
  3. headtail: 初めの16文字と終りの16文字をつなぐ
  4. skipover: 等間隔に32文字とる

長くなるので、使用したスクリプトと生の結果は http://anond.hatelabo.jp/20090326123924 に貼った。

結果としては、早さは3, 4, 1, 2の順で、3を基準にとると、

文字列md5hexcrc32x4headtailskipoverループ回数
2566.6361.01.465536
10248.3361.02.016384
409626851.02.54096

という比率になった。

文字列長が長くなるとやはり後2つが有利だ。また、今回は32文字に切り詰めたがそれでもコリジョンは発生しなかった。アルゴリズム上、数文字だけの変化には対応出来ない可能性があるが、切り詰める量が少なく入力にいくらかのランダム性があれば実用になると思う。

(追記:URLで使ったら、ランダム性が悪くてコリジョン出た。素直にmd5ベターかもしれない)

しかし、この程度の速度差であれば、コリジョン耐性を重視して素直にmd5を使用するのも良いかもしれない。特に、今時はネイティブコードライブラリをほぼ標準で持つ処理系が多いため、まずはmd5で、としても間違いはなさそう。

2009-03-26

ハッシュ関数を調べる

セキュリティ目的ではない。ハッシュテーブルで使うような奴でキャッシュで使いたい。

手軽なほうが良い。軽いほうが良い。推測可能でよい。数十バイトくらいの文字列にしたい。

md5が一番汎用っぽいけど、無駄に重い気がする。crc32は軽そうだしそれなりに汎用っぽいけど、ハッシュ長が短いのがめんどい

ベターはなんだろう。セオリーはなんだろう。

調べた→ http://anond.hatelabo.jp/20090327015620

ベンチ用スクリプト

#!/usr/local/bin/python
from sys import argv, stderr
from time import time
from string import ascii_letters, join
from random import choice
from hashlib import md5
from binascii import crc32
from itertools import izip

time_fmt = '%10s: %5d ms'
shift = int(argv[1]) if len(argv)>1 and argv[1].isdigit() else 2
length = 0x100 << shift
cycle = 0x10000 &gt;&gt; shift
print &gt;&gt; stderr, 'string length: 0x%x, cycle: 0x%x' % (length, cycle)
data = tuple(''.join(choice(ascii_letters) for i in xrange(length)) for j in xrange(cycle))

start = time()
md5hex = tuple(md5(s).hexdigest() for s in data)
print &gt;&gt; stderr, time_fmt % ('md5hex', (time() - start) * 1000)

start = time()
crc32x4 = tuple(''.join('%08x' % abs(crc32(s[i::4])) for i in (0, 1, 2, 3)) for s in data)
print &gt;&gt; stderr, time_fmt % ('crc32x4', (time() - start) * 1000)

start = time()
startend = tuple(s[:16]+s[-16:] for s in data)
print &gt;&gt; stderr, time_fmt % ('headtail', (time() - start) * 1000)

start = time()
skip = tuple(s[::(len(s)/32+1)] for s in data)
print &gt;&gt; stderr, time_fmt % ('skipover', (time() - start) * 1000)

for s in izip(data, md5hex, crc32x4, startend, skip):
    print join(s)

実行結果

% python hashbench.py 0 &gt; hash0.txt
string length: 0x100, cycle: 0x10000
    md5hex:   199 ms
   crc32x4:  1081 ms
  headtail:    30 ms
  skipover:    41 ms
% python hashbench.py 2 &gt; hash1.txt
string length: 0x400, cycle: 0x4000
    md5hex:    83 ms
   crc32x4:   363 ms
  headtail:    10 ms
  skipover:    20 ms
% python hashbench.py 4 &gt; hash2.txt
string length: 0x1000, cycle: 0x1000
    md5hex:    52 ms
   crc32x4:   170 ms
  headtail:     2 ms
  skipover:     5 ms

2007-05-26

ころころアカウント変える奴がウザイ

その分だけ他の人が選べる文字列が減っていく事に少しは申し訳ないと思わないのかね。他人と被らないような、全然脈絡のない文字列にして欲しい。ハッシュ関数みたいなやつ。

つーかチラシの裏にでも書いてろよ。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん