JP4991283B2 - コンテンツベースのアドレシングにおける追加ハッシュ関数 - Google Patents

Description

本発明は、コンピュータを用いた情報の記憶および取り出しに一般に関する。より具体的には本発明は、コンピュータファイルの内容を特定およびハッシュ関数および乱数の使用に関する。

従来技術は、国際公報第ＷＯ９９／３８０９３に記載されるように、コンテンツアドレス可能なディジタル情報の記憶、その取り出し、およびハッシュ関数、メッセージダイジェスト、および記述子ファイルの使用を含む。国際公報第ＷＯ９９／３８０９２は、コンテンツアドレス可能な情報の記憶およびアクセスのための具体的な技術を記載し、国際公報第ＷＯ０１／１８６３３は、コンテンツアドレス可能な情報を暗号化する技術を記載する。これら公報は全て、参照によって援用される。

従来技術において議論されるように、コンテンツアドレス可能な技術は、記憶された内容の完全性を保証するようなかたちで文書を記憶およびアクセスするのに非常に有用でありえることは明らかである。従来技術で議論されるように、ある技術は、特定の文書をユニークに示すために、原文を元に固定長の「ハッシュ値」を発生するメッセージダイジェスト（例えば「ＭＤ５」のようなもの）を用いることである。さらに単一のＭＤ５は、多くの文書をユニークに表しえ（例えば記述子ファイルを用いて）、個々の文書は、それぞれが単一の文書または文書群のセットを参照する多くの異なるＭＤ５を含みえる。

注意されるハッシュ関数に関連する２つのリスクが存在する。すなわち、統計的ハッシュ関数の衝突およびハッシュ攻撃である。ハッシュ衝突は、純粋に偶然に悪意なく、コンテンツアドレス可能な記憶を実現するシステムが、異なるコンテンツを持つが同じハッシュ値、つまり同じ「コンテンツアドレス」を有する２つのファイルを含むときに起こる。ほとんど任意の考えられるシナリオの下では、このリスクは非常に長い時間のあいだ無視できる程度に留まるだろうーーマーケティング目的ではこのリスクをなくすか大幅に減らすことに大きな価値があるかもしれないが。

ハッシュ攻撃は、全く異なる前提であり、「第２プリイメージを見つけること」としても知られる。ハッシュ攻撃は、不謹慎な者が悪意を持って、オリジナルファイルのハッシュ値と同一のハッシュ値（または「コンテンツアドレス」）を作るために構成された大幅に変えられたコンピュータファイル（例えば）のバージョンを生成するときである。ハッシュ攻撃は、ランダムなビットパターンをファイル中に単に挿入しえ、またはコントラクト文書の意味が変わりえる。いずれの場合にも、ハッシュ攻撃は、ハッシュ関数を破ることになり、適切に保存されていると考えられたディジタル情報の破壊になる。

いずれのシナリオにおいても、システムそのものの信憑性に関わる問題である。すなわち、いくつかの成功した、広く公にされたハッシュ攻撃の後は（直接に現実の世界での適用性がなく、学問的な条件の下であっても）、システムは一般人の心には疑わしいものとなる。さらに、使用中のハッシュ関数が破られるかもしれないことがいったん単に証明されても、システムは疑わしくなる。コンピューティングリソースが進化し続けるうちに、そのようなハッシュ攻撃は、長い期間にわたっては成功するかもしれない。より大きなハッシュ関数のサイズが選ばれ、続いて破られると、互換性の問題および破られた信頼の鎖が生じる。この結果は、このようなシステムの自然な応用となるべき長期的記憶サービスの魅力的な展望ではない。

非常に大きいサイズを有するハッシュ関数を単に用いることはいつも実用的とは限らない。一方で、ハッシュ関数は、ハッシュ関数衝突（２つの異なる入力についての同一のハッシュ値）が統計的に除外されることを保証するために充分に大きくなければならない。もう一方で、そのターゲットとされたアプリケーションにおけるレファレンスとして実用的であり続けるために充分に小さくなければならず、またハッシュ値を計算するのに必要とされるプロセッサ時間の点でも実用的でなければならない。

残念ながら、特定のサイズのハッシュ関数についてシステムが一般に動作可能であっても、異なるハッシュサイズに変更することは、効率の低下、およびアプリケーション変換コストと共に、下位互換オーバヘッドのような多くの影響を持つ大きな作業である。例えば、コンテンツアドレス可能な記憶システム中のＭＤ５アルゴリズムを異なるハッシュ関数と置き換え、コンピュータファイル毎に新しいメッセージダイジェストを生成することは、問題を生じる。１２８ビットメッセージダイジェスト（それぞれがあるファイルについてユニークなアドレスを表す）は、他の文書および世界中のコンピュータシステムにわたっておそらくは散りばめられているので、これら１２８ビットメッセージダイジェストを新しく計算されたメッセージダイジェストと置き換えることはほとんど不可能だと判るかもしれない。さらにもし前のハッシュ関数が「破られる」と一般に受け入れられた後にこの変換が起こると、重要かつ本質的に取り返しのつかない「信頼ギャップ」を生むことになりえるが、これは既存のコンテンツアドレスが変換の時点では疑いを晴らし得ないからである。

よって上記問題を解決するメカニズムおよび技術が必要とされる。

前述を達成するために、本発明の目的にしたがって、悪意のあるハッシュ攻撃を排除し、ハッシュ関数衝突が検出されることの保証を提供する技術が記載される。

一般的な概念は、コンテンツアドレシングをコンテンツ検証から分離することである。換言すれば、コンテンツアドレシングに用いられるハッシュ関数は、コンテンツ検証に用いられるハッシュ関数とは異なる。バリエーションとして、コンテンツアドレシングのためのハッシュ関数の代わりに乱数発生器が用いられる。この技術は、時間と共にコンテンツ検証ハッシュ関数が変化されえ、トランスペアレントに強化され、コンテンツアドレシングハッシュ関数を用いて計算されたコンテンツアドレスを用いた任意のアプリケーションについて完全に下位互換性を維持することを可能にする。よってコンテンツアドレシングハッシュ関数のそれではなく、検証ハッシュ関数の完全な強度により、ハッシュ攻撃が検出されえ、防がれえる。その結果、言及すべきより少ない悪意のある攻撃が予想されるが、これは成功する可能性が少ししかないとそれらには知られるからである。

このアプローチは、ほとんどのアプリケーションにおいて大きな変換を要求し、既存のコンテンツアドレシングされたデータの集積の完全性を危うくし、よって長期的なアーカイブ機能についての技術のアピール度を大きく低減させる、全体のシステムにわたって単に単一のコンテンツアドレシングハッシュ関数をアップグレードするデフォールトのシナリオに対して大きな利点を提供する。

検証のための第２ハッシュ関数の使用は、アドレシングハッシュ関数を伴う衝突、またはそれに対するハッシュ攻撃の検出を可能にする。１２８ビットを用いれば衝突が２つのファイル間で起こるのは統計的に尤もらしくはないが、それでも大衆はそのような衝突が検出されえるという安心を求めるかもしれないのである。衝突が起こったとしても、２つのファイルについての検証ハッシュ値は異なるので、よってアドレシングハッシュ関数が２つの異なるファイルについて同じ値を生んだという問題にフラグを付けられる。同様に、もし悪意の者が１２８ビットハッシュ関数を攻撃し、２つのファイルが同じハッシュ値を与えるような方法を考え出すなら、この攻撃は検証ハッシュ値の差のためによっても検出されえる。よってあらゆるそのような攻撃が検出されえることがほぼ確かであるので、そのような攻撃を実行するために時間とリソースを消費する者がでることはずっと起こりにくい。

本発明は、そのさらなる利点と共に、以下の記載を添付の図面と併せて参照することによって最も良く理解されよう。

古く、潜在的に安全ではないハッシュ関数（例えば１２８ビットのハッシュ関数）を使い続けることについての従来技術の性質、および潜在的な問題（実際の、または大衆の心に受け止められる）が与えられたとき、改善が望まれる。従来技術のハッシュ関数は、２つの目的を果たすと考えられる。ハッシュ関数によって作られるハッシュ値は、任意の与えられたコンピュータファイルについてのほとんどユニークなコンテンツベースのアドレスを提供するだけでなく、ファイルのコンテンツを検証するために用いられえるユニークな値を提供する。ハッシュ関数は、参照のため、およびコンテンツの検証のための両方に用いられる単一のハッシュ値を作る。１２８ビットハッシュ関数によって利用可能なアドレス空間のサイズは、現実的には問題がないことが判る。１２８ビットのハッシュ関数（例えば）は２１２８アドレスのアドレス空間を提供し、これは全ての意図および目的のために予見可能な未来において不足することはなく、衝突に至ることもないユニークなアドレスの量である。

しかし同じハッシュ関数がファイルのコンテンツの検証を提供するためにも用いられる。すなわち、ファイルがそのハッシュ値をアドレスとして用いて取り出されるとき、ハッシュ値は再計算され、オリジナルのものと比較される。用いられるハッシュ関数を強化することが望ましいので、ユニークなアドレスを提供するためにオリジナルの参照ハッシュ関数を保持しつつ、ファイルのコンテンツの検証を提供するために第２検証ハッシュ関数が用いられえる。オリジナルの参照ハッシュ関数を保持することは多くの利点を有し、それにはファイルを参照するのに用いられるユニークな値が続けて用いられえるという利益が含まれる。問題のファイルを参照するために、このユニークな値が多くの場所に分配され、他の文書中に挿入されているかもしれないので、このユニークなアドレスが変わらないことは重要なことである。同様に強力な第２検証ハッシュ関数がファイルのコンテンツを検証するために用いられることを可能にすることによって、このようなシステムがハッシュ攻撃に曝されないというより大きな保証が与えられる。このようなシステムは、与えられたファイルについての安定なユニークなコンテンツアドレスの利益を損なうことなく、この検証ハッシュ関数が時間と共にダイナミックにアップグレードされることを可能にする。

コンテンツアドレス可能な記憶：
以下の議論の理解を助けるために、コンテンツアドレス可能な記憶を簡単に復習することが役に立つだろう。図１は、文書１０２についてのハッシュベースのユニークな識別子１２２を作る技術を示す。以下の記載は、表現され管理される簡単な文書の例を用いるが、文書１０２はディジタル形式で表現される任意のタイプの情報でありえる。例えば本発明は、コンピュータファイル、ファイル群のグループ、ファイル識別子群のグループ、または他のデータの集積またはデータベース情報のような情報の任意の電子的表現に適用可能である。そのような他のデータの集積には、ディジタルオーディオまたはビデオストリームからのフレームまたはクリップ、ディジタル写真、スキャンされた紙の文書、ボイスメッセージ、ＣＡＤ／ＣＡＭデザイン、ＭＲＩまたはＸ線データ、メッセージレコードまたはファイルからのストリーム、システムの監査またはステータスログからのログエントリ、電子メールアーカイブ、小切手イメージなどが含まれる。データベース情報には、リレーショナル、階層、ネットワークまたは他のデータベースが含まれる。一般に、ディジタル情報は、２進（またはｎ進）ディジットの任意のストリングを含みえる。ある実施形態において、ディジタル情報は、バイナリラージオブジェクト、つまりＢＬＯＢ群として操作される。以下の記載は、コンピュータファイルを例として用いるが、本発明はそのようには限定されない。「コンピュータファイル」という語は、前述の情報のタイプの任意の電子的表現を包含するようにここでは用いられる。

アルゴリズム１０４は、その文書についてのユニークな識別子１０６を作るために文書１０２を処理するために用いられる。好ましくはアルゴリズム１０４は、ハッシュ値１０６を作るハッシュ関数である。この例では、ハッシュ関数は、ハッシュ値またはメッセージダイジェスト（「ＭＤ」）１０６を作るように用いられる。よく知られるハッシュ関数には、ＭＤ２、ＭＤ５、ＳＨＡ−１、ＳＨＡ−２５６、ＲＩＰＥＭＤ−１６０などが含まれる。

この技術で知られるように、文書にわたってのハッシュ関数の使用は、その文書の「ディジタル指紋」であり、それをユニークに特定するユニークなハッシュ値つまりメッセージダイジェストを作る。メッセージダイジェストまたは「ＭＤ」という語は、ハッシュ関数によって作られたハッシュ値を指すためにしばしば用いられ、ある文書についてのユニークなコンテンツベースの識別子を作るのに用いられえる任意のタイプのハッシュ関数を包含するよう意図される。この例では、ＭＤ５アルゴリズムがＭＤ１０６を作るために用いられることを想定する。

メッセージダイジェスト１０６は、本発明の目的のために用いられえ、またはそれは記述子ファイル１０８内に埋め込まれえる。記述子ファイル１０８は、メッセージダイジェスト１０６および文書１０２の情報または任意の他の情報をさらに記述し、識別し、または説明する任意のさまざまなメタデータ１１０を含む。記述子ファイルの記述およびメタデータのタイプは、上で参照された国際出願群において記載されている。ある実施形態においてはメタデータ１１０は、記述的ファイル名、ファイルサイズ、アクセス権限、所有者、保持期間などを含む。主題、タイトル、作者、日付のようなより上位の情報も含まれえる。

記述子ファイルは、もし特定のアプリケーションのために必要であるならこのタイプの情報のためのプレースホルダとして機能するのに、またもしシチュエーションがそのように要求するならファイル群のグループについてのメッセージダイジェストを保持するのに有用である。メッセージダイジェストは、記述子ファイルを参照しえ、または個別の文書を直接に特定しえる。

いったん記述子ファイルが生成されると、ハッシュ関数１１４は、記述子ファイルに適用されて、他のメッセージダイジェスト１１６を作る。メッセージダイジェスト１１６は、従来技術に示される技術を用いて文書１０２の位置をユニークに特定し、識別するために今度は用いられえる。例えば記述子ファイル１０８および文書１０２はコンピュータの通常のファイルシステムに記憶されえ、ここではそれらのファイル名はそれぞれＭＤ１１６およびＭＤ１０６によって表現されるビットストリングである。またはそれぞれのファイルはデータベース内に記憶されえ、ここではファイルへのキーはそれぞれのファイルについてのそれぞれのメッセージダイジェストである。一般にファイル１０８および文書１０２は任意のコンテンツアドレス可能な記憶システム内に記憶されえ、ここではそれらは、それらのメッセージダイジェストだけを用いて位置特定および取り出しがなされえる。

ＭＤ５メッセージダイジェスト（または他のハッシュ値）は、人間によって容易に読まれ、覚えられえる形に変換されえる。ＭＤ５ハッシュ関数からの結果として生じるメッセージダイジェストは１２８ビットの数であるので、この数を人間が用いるのにより扱いやすいかたちにエンコードするのが望ましい。結果として生じる数は、１０進、１６進、または２進を含む任意のさまざまな形態にエンコードされえる。好ましくはこの数は、ベースＡＳＣＩＩキャラクタセット中の２６のアルファベットおよび数字のキャラクタのセットへマッピングされるベース３２の数に変換される。このマッピングは、「ＡＳＣＩＩアーマリング（ASCII Armoring）」と呼ばれ、コンテンツがアルファニューメリックコーディングに制限されることを要求するプロトコル上で送信するために２進情報を限られたキャラクタセットに収めるためにふつう用いられる。好ましい実施形態において、フラグキャラクタは、結果として生じるストリング内の所定の位置に含まれ、ストリングの全体長を２７キャラクタにする。このフラグキャラクタは、使用するアルゴリズム、ファイルのタイプなどのような情報も提供しえる。

結果は、数字および大文字の２７キャラクタのＡＳＣＩＩストリングである。このようなフォーマットは、より簡単に人間に書かれて、および／またはコンピュータによって操作されえ、また容易に多くのソフトウェアプログラムによって受け入れられるコンパクトな形態を提供する。加えて、メッセージダイジェストのこの特定の表現は、より簡単にデータクエリーによって取り出され、ソフトウェアアプリケーションファイルリクエストにコーディングされ、コンテンツまたはアセット管理システムによって参照され、オブジェクトブラウザでリクエストされ、ある文書から他の文書へ電子的にコピーおよびペーストされ、電子メールを介して送られるなどの利点を有する。

この例では、ＭＤ１１６は、２７キャラクタストリング１２０に変換されている。具体的な実施形態において、ストリング１２０は、インターネット名１１８と連結され、ＵＲＬ１２２を作る。名前１１８は、ＤＮＳによって解決され、「trustclip.com」というドメインネームを含む。この具体的な実施形態において、「trustclip.com」は、コンテンツアドレス可能な記憶デバイスに接続されるウェブサーバの位置特定を行うのに用いられる。ドメイン「trustclip.com」を運用するサービスプロバイダは、メッセージダイジェストをユニークな識別子として用いてこのような文書群を記憶し、ＵＲＬ（ＵＲＬ１２２のような）が与えられるときに、このような文書をユーザに利用可能にする。このようにして、ユーザがＵＲＬ１２２を与えられるとき、またはそうでなければそれをリンクとして用いるとき、ウェブサイト「trustclip.com」は、ＭＤ１２０をとり、文書を位置特定し、それをユーザに返す。もしＭＤ１２０が複数の文書についてのメッセージダイジェストを含む記述子ファイルを特定するなら、これら文書の全てが返される。本発明は、メッセージダイジェスト（形態１１６、１２０または他のもの）が多くのやり方で用いられてオリジナルの文書を位置特定することを想定する。前述のように、メッセージダイジェストは、文書のファイル名、データベースのキー、ＵＲＬまたはＵＲＩ（またはＩＰアドレスまたはパス名のような他のファイルロケータ）内に埋め込まれて、または単にそのままで用いられえる。

他の実施形態において、メッセージダイジェストは、そのときメッセージダイジェストを用いてメッセージダイジェストによってユニークに特定される文書を検索し位置特定をするためにサービスプロバイダに与えられる。例えば、サービスプロバイダは、それら自身のコンテンツアドレス可能な記憶をサーチしてもよく、または他のエンティティの記憶内で文書を検索してもよい。またメッセージダイジェストは、企業ネットワークを通して、イントラネット上で、インターネット上で、またはそのメッセージダイジェストによってユニークに特定される文書を探す目的で他のやり方で、ブロードキャストされえる。記述子ファイルの実施形態は、上述の国際出願において記載されている。

検証ハッシュ関数の使用法：
図２は、異なるハッシュ関数を用いて計算された任意の個数のファイルについてのハッシュ値を含むテーブル２００を示す。テーブル２００は、ある実施形態では「ハッシュオーソリティ（hash authority）」と呼ばれる。データベースに含まれる特定のファイルについて、テーブル２００は、異なるハッシュ関数を用いて計算されたそのファイルについての任意の個数の異なるハッシュ値を保持しえる。例えばテーブル２００は、第１ハッシュ関数（例えばＭＤ５アルゴリズム）を用いて計算されたアドレスハッシュ値（ＡＨ）を保持するカラム２０４、および異なるハッシュ関数を用いて計算された検証ハッシュ値（ＶＨ）を保持するカラム２０８を含む。それぞれのロウは与えられたファイルに対応する。例えばロウ２１２はファイルＡに対応し、ＭＤ５アルゴリズム（例えば）を用いて計算されたファイルＡについてのＡＨを含む。ファイルＡについてのＶＨは２５６ビットハッシュ関数またはそれより強いものを用いて計算される。特定のファイルＡについて、そのＡＨがそのＶＨと関連付けられて記憶され、よって特定のファイルについてのＡＨを参照することによってそのＶＨが得られ、かつその逆も成り立つことをロウ２１２は示す。特定のファイルについてのＶＨは、そのファイルについてＡＨを計算するのに用いられるハッシュ関数と同じ長さ（またはそれより短い長さ）を有するハッシュ関数の結果でありえる。しかしＶＨを計算するのに用いられるこのハッシュ関数がより強いことが好ましい。また、カラム２０８のような多くのカラムが存在しえ、その結果、ある与えられたファイルについて、異なる検証ハッシュ関数を用いて計算された多くのＶＨ値を有してもよい。

テーブル２００は、記憶されているファイルの個数に依存して任意の個数のエントリ（またはレコード）を有しえる。テーブル２００は、単一のコンピュータ上において、コンピュータ群のネットワーク上において、コンピュータ群の分散化ネットワーク上において、またはファイルまたは他のディジタル情報を記憶するのに適切な任意のデータベース内において記憶されるファイルと関連付けられえる。さらにテーブル２００は、当業者には理解されるように、ハッシュ関数、タイムスタンプおよび／またはディジタル署名を用いて保護されたそのエントリを有しえる。さらに特定のファイルについてのＡＨおよびＶＨは、必ずしもテーブルではなく、任意の他の適切なデータ構造を用いてそれぞれ互いに関連付けられえる。

図３は、ファイルをデータベースに追加するある実施形態を記載するフローチャートである。この簡単な例において、コンピュータファイルまたは他のタイプのディジタル情報が本発明の技術を用いて、ファイル群のデータベースに追加することが望まれている。

このデータベースは、そのファイルのハッシュ値がそのユニークなアドレスとして用いられるコンテンツベースのアドレシングスキームを好ましくは用いてファイルを記憶する。２つの異なるハッシュ関数は、このデータベースと関連付けられている。アドレシングハッシュ関数は、それぞれのファイルをアドレスするのに用いられるアドレスハッシュ値（ＡＨ）を生成し、検証ハッシュ関数は、特定のファイルのコンテンツを検証するのに用いられる検証ハッシュ値（ＶＨ）を生成するのに用いられる。好ましくは検証ハッシュ関数は、アドレシングハッシュ関数よりも強く、より強いハッシュ関数の例はＳＨＡ−２５６およびＲＩＰＥＭＤ−２５６である。

ある実施形態において、検証ハッシュ関数は、アドレシングハッシュ関数と同じハッシュ関数であるが、それはフラグ、パラメータ、追加入力、バリエーションまたは他の改変を用いることによって、アドレシングハッシュ関数によって作られるものとは異なるハッシュ値を作る。例えば、このファイルは、ファイル名、サイズ、所有者、作成日、またはそのファイルの最後４ｋブロックのような反復（repeat）のようなメタデータを含むことによってわずかに改変されえる。

テーブル２００のようなデータ構造が存在し、データベース内に存在する全てのファイルについてのエントリおよびそれらの対応するハッシュ値を含むが、そのようなテーブルはもしファイルがまだ追加されていないのなら空であってもよい。

２２０において、追加されるべきファイルが任意の適切なソースから得られる。２２４において、アドレシングハッシュ関数がこのファイルに適用されて、ファイルのＡＨを生成し、そのユニークなアドレスを決定する。２２８において、検証ハッシュ関数が用いられてファイルのＶＨを生成する。ステップ２３２は、追加されるべきファイルが既にデータベース内に存在するかをチェックする。このようなファイルについてチェックすることは、さまざまなやり方で実行されえる。ある実施形態においては、そのファイルについてそのＡＨを識別子またはインデックスとして用いて、データベース全体が検索される。例えば、ファイルは、そのファイルのＡＨであるファイル名の下で記憶されえる。このとき、ファイルシステム全体は、このＡＨが存在するかを調べるようにそれからスキャンされえる。他の実施形態において、このＡＨは、このファイルが既に存在するかを決定するために、テーブル２００へのルックアップとして用いられえる。

もしこのファイルがデータベース内に存在しないと決定されるなら（ファイルのＡＨに一致するものが何も見つからないことによって）、２３６において、ファイルはデータベース内にそのアドレスとしてそのＡＨを用いて記憶される。例えば、このファイルは、そのＡＨであるファイル名を与えられえる。次に２４０において、この特定のファイルについてのＡＨ−ＶＨのペアがテーブル２００に追加されることによって、新しく追加されたファイルについてのエントリがテーブル２００内にここで存在することになる。このＡＨは、データベース内でのこのファイルについてのユニークなアドレスとしてリクエスタに戻される。プロセスはそれから終了する。

ステップ２３２に戻り、もしファイルが既にデータベース内に存在すると決定されるなら（ファイルのＡＨと一致するものが見つけられることによって）、既にデータベース内に存在するファイルが、追加されることが望まれるファイルと実際に同じであるかがそれから決定される。２４４において、データベース内のアドレスＡＨにある、このファイルについてＶＨが計算される。２４８において、データベース内に存在するこのファイルについてのＶＨが、追加されるべきファイルについてのＶＨ（ステップ２２８から）と比較される。たいていの場合、２つのＶＨは同じであり、これは追加されるべきファイルが既にデータベース内に存在することを表す。もしこうであれば、ＡＨはリクエスタにデータベース内のそのファイルについてのユニークなアドレスとして戻され、プロセスは終了する。一方、もし２つのファイルについてのＶＨが異なるなら、これは問題があることを表す。

２５２において、システムは、問題の存在を報告する。この問題は、ハッシュ攻撃の結果でありえ、この場合、２つのファイルのうちの１つが悪意を持って変更され、その結果、アドレシングハッシュ関数がファイルが同じであると示しても、検証ハッシュ関数（より強くより信頼できる）が２つのファイルは実際には異なると示す。他の可能性としては、システムハードウェアまたはソフトウェア内に技術的誤動作があり、ＶＨ値が異なるように見えても、ファイルは実際には同じであることがある。３番目の可能性としては、ハッシュ衝突が起こって、２つのファイルが実際には異なっていても、それぞれのファイルについてのアドレスハッシュ値の計算は同じ値を生むことである。いずれの場合も、ステップ２５２は、この問題をシステムまたはユーザに対して示し、これらが適切な処置を取りえる。いずれの場合も、このようなシナリオは特定の実施形態によっては起こりえるが、好ましくはこのファイルはデータベースにこの時点では追加されるべきではない。

図４は、ファイルがデータベースから取り出されるある実施形態を記載するフローチャートである。このシチュエーションにおいて、ユーザは、本発明の技術を用いて実現されたデータベースからファイルを取り出したい。２６０において、ユーザまたはソフトウェアは特定のファイルを希望し、そのファイルについての以前に計算されたハッシュ値に基づいてそのファイルを要求する。好ましくはユーザまたはアプリケーションは、そのファイルについてのハッシュ値が、ＡＨ値を計算するためにシステムによっても用いられる特定のアドレシングハッシュ関数を用いて計算されていることを知っている。所望のファイルについてのＡＨは、ユーザまたはアプリケーションによって、そのＡＨが記憶されている任意の適切なソースから得られる。２６４において、ユーザまたはアプリケーションは、所望のファイルのこのアドレスハッシュ値（ＡＨ）をシステムに提示する。２６８において、システムはＡＨを用いて、この所望のファイルがデータベース内に存在するかを、ステップ２３２において前述された技術を例えば用いて決定する。もし存在するなら、このファイルについてのＡＨおよびＶＨを取り出すためにこのステップにおいてハッシュオーソリティテーブルが調べられてもよい。もしファイルがデータベース内に存在しないと決定されるなら、２７２においてシステムはユーザまたはアプリケーションに所望のファイルが見つからなかったことを報告する。

しかしもしファイルが見つかったとシステムが信じるとシステムが示すなら、２７６においてシステムはデータベース内で見つかったファイルのＡＨを計算する。２８０において、２６４においてユーザから受け取られたＡＨは、２７６において生成されたＡＨと比較される。この比較は、アドレスＡＨにおいて記憶されたファイルが実際にＡＨに等しいアドレスハッシュ値を有することを保証するチェックとして実行される。状況によっては、この比較ステップを実行しないことも可能である。

もしＡＨ値群が異なるなら、２８４において異常がユーザまたはアプリケーションに報告される。２８０において計算された異なるＡＨ値群は、ローカルファイルが壊れていることを典型的には示し、ユーザに戻されるべきではない。もしＡＨ値が同じであるなら、これはアドレスＡＨにおいて見つかったファイルがおそらくユーザによって希望されるファイルであることを示す。したがって２８８において、データベースにおいて見つかったファイルの検証ハッシュ値（ＶＨ）が計算される。２９２においてこの計算されたＶＨが、ハッシュオーソリティテーブル中のエントリからのこのファイルについてのＶＨと比較される。このファイルに対応するハッシュオーソリティテーブル中のこのエントリは、ステップ２６８のあいだにＡＨをインデックスとして用いて参照され、またはＶＨはテーブルにおいてこの時点でやはりファイルのＡＨをインデックスとして用いて参照されえる。もしＶＨ値が異なるなら、ステップ２５２において記載されたのと同じ可能性のある問題を示す問題が２９６においてユーザに報告される。もしＶＨ値が同じなら、これはアドレスＡＨにおいて見つかったファイルが、そのファイルが最初にデータベースに追加されたときにもともとこの場所において記憶されたのと同じファイルであることを示す。このステップで等しいＶＨ値群は、見つかったファイルがユーザによって希望されるファイルであることを信頼性を持って示す。２９８においてこのファイルは、それをリクエストするユーザまたはソフトウェアアプリケーションへ届けられる。

図５は、本発明の実施形態を用いて実現されたデータベース中のファイルの完全性をチェックする技術を記載するフローチャートである。このシチュエーションにおいて、もし異常が見つけられたなら警告を発して、もし必要なら修正するためのアクションをとるために、データベース中に記憶されたファイルの完全性を連続的にチェックすることが望ましい。このような連続的な完全性チェックなしでは、悪意を持つ者がデータベースのオリジナルのファイルを置換、変更または消去し、オリジナルのデータがなくなることもあり得る。例えば、もし誰かがファイルのアドレスハッシュ値（ＡＨ）を計算するのに用いられるより低い強度のハッシュ関数を破る方法を見つけるなら、その人間にとっては偽のファイルをデータベースに挿入することも可能になる。換言すれば、この偽のファイルは、オリジナルのファイルの変更されたバージョンであるが、しかしそのアドレスハッシュ値はオリジナルのファイルのものと同じである。よってファイルは、不正な目的のために変更されえ、真のファイルになりすましてデータベース中に挿入されえる。両方のファイルについてのアドレスハッシュ値が同じなので、不正に変更されたファイルが正しいファイルではないことを証明することは非常に困難になりえる。検証ハッシュ関数がそのようなファイルのコンテンツを検証して、変更されたファイルが不正なバージョンであることを証明するとしても、真のファイルのオリジナルのコンテンツは失われてしまう。

本発明のこの実施形態において、コンピュータファイルを保持するデータベースは、それぞれのファイルの複製（またはより多くのコピー）を保管し、よってあるコピーにおいてエラーが検出されるときには疑わしいファイルはその複製と置換されえる。先行技術による技法もそのような複製およびファイル置換の使用を含みえるが、以下の記載は、第２検証ハッシュ関数を用いて連続的な完全性チェックを実行する方法を提供する。このシナリオでは、本発明の実施形態によって多くのコンピュータファイルが適切なデータベース中に記憶されている。データベース中に記憶されたそれぞれのファイルについて、アドレスハッシュ値（ＡＨ）および検証ハッシュ値（ＶＨ）のペアがテーブルまたは他の適切なデータ構造のかたちで記憶されている。図５のフローチャートは、第２検証ハッシュ関数の追加された強度および優位性を用いてこれらファイルの完全性を連続的にチェックする方法を提供する。

３０４で始まり、システムはデータベース中の全てのファイル（またはもし望まれるなら全てのファイルのうちのサブセット）について反復する。この反復は、データベース中に存在する全てのファイルを通して、それらのファイル名または他の識別子を用いて順次ステップを踏むことによって実行されえ、またはハッシュオーソリティテーブル２００のようなテーブルが用いられて、それぞれのファイルをテーブルからのそのＡＨを用いて参照することによってデータベース中の全てのファイルにわたって反復しえる。さまざまなファイルにわたる反復のための他の技術には、ファイルまたはテーブル中のファイルエントリをランダムにステップすることが含まれる。

３０８において、チェックされるべきファイルがそのファイルの既存のＡＨを参照することによって得られ（テーブルから、ファイル名から、または他の手段を介して得られ）、データベース中のそのファイルのアドレスを決定する。３１２において、システムによって用いられているアドレシングハッシュ関数がファイルに適用され、そのファイルのＡＨを計算する。３１６において、この計算されたＡＨは、ハッシュオーソリティテーブル中で見いだされたファイルについてのファイルについての既存のＡＨと比較される。

もしＡＨ値群が異なるなら、３２０においてシステムは問題をユーザまたは完全性チェックを実行するアプリケーションに報告する。もしＡＨ値群が異なるなら、システムは、分析されている現在のファイルがなんらかのかたちで（技術的な誤動作、攻撃、その他によって）壊れていると推定し、システムは３２４においてエラーリカバリを実行する。システムは現在のファイルのコピーを他の位置に以前に記憶しているので、ハッシュオーソリティテーブル（ファイルの位置特定をまず行うのに用いられる）からのＡＨがそのファイルの既存の良いコピーを位置特定するために用いられる。いったん位置特定されると、疑わしいファイルは既知の良いコピーと置換される。ファイルの両方のコピーが同時に壊れることは統計的に起こりえないので、ファイルの複製は良いコピーであると推定される。もちろん、複製の完全性をダブルチェックするために、ハッシュオーソリティテーブル中で見つけられたＡＨと比較されるように、その複製のＡＨも計算されえる。他のエラーリカバリプロシージャも実行されえる。例えば、実現のアプローチに依存して、システムは疑わしいファイルを置換しないと決定しえ、疑わしいファイルは消去されえ、または疑わしいファイルは改竄の企図の証拠を文書化し保存するためにオリジナルのあるバージョンとして記憶装置に追加されえる。問題の現在のファイルについていったんエラーリカバリが実行されると、ループは３４４において継続され、その完全性がチェックされるように次のファイルが得られる。

ステップ３１６に戻り、もしＡＨ値が同じなら、これは、コンテンツアドレスＡＨにおいて見つかった現在のファイルが、おそらくそのアドレスにもともと記憶されたファイルであることを示す。３２８において、そのファイルの検証ハッシュ値（ＶＨ）が計算され、さらにファイルの完全性をチェックする。好ましくはシステムによって用いられる検証ハッシュ関数は、アドレシングハッシュ関数とは異なり、それよりも強力である。３３２において、そのファイルについて計算されたＶＨは、ハッシュオーソリティテーブル中に存在する既存のＶＨ（そのファイルがもともと記憶されるときに計算された）と比較される。もしＶＨ値群が異なるなら、３３６において、ステップ２５２において一般に記載されたように問題が報告される。

３４０においてシステムは、問題に対応するために適切な修正のためのアクションを取りえる。例えば、そのファイルは疑わしいとしてフラグが付けられえ、なぜＶＨ値群が異なったかを決定するために監査が実行されえ、現在のファイルの複製が用いられて疑わしいファイルのコピーを置換しえ、そのファイルの他の既存のコピーが消去されえるなどである。これら取られえる修正アクションは、システムの設計および実現方法およびシステムの操作者が達成したいと思う目標に依存する。いったん適切なアクションが取られると、３４４において分析されるべき次のファイルが得られる。

ステップ３３２に今度は戻り、もしＶＨ値群が同じなら、これは、コンテンツアドレスＡＨに現在存在するファイルが、実際にそのＡＨ−ＶＨペアがハッシュオーソリティテーブルに追加されたときにもともとそこに配置されたファイルであることをほぼ確実に示す。このシチュエーションにおいて、報告または修正アクションは必要とされず、３４４において分析されるべき次のファイルが得られる。いったん全てのファイルがループ３０４〜３４４を介してチェックされると、プロセスは終了するかまたは元に戻る。

マルチレベルでの実施形態：
本発明の実施形態は、デスクトップコンピュータ、サーバ、専用のメインフレームなどの上に常駐するデータベースにおいて実現されえると同時に、分散されたかたちでも実現されえる。図６は、コンピュータファイル（または他のディジタル情報）を保持するデータベースが多くのサーバコンピュータの中で分散されているマルチレベルデータベース４００を示す。このデータベースは、任意の個数のコンピュータにわたって分散化されたやり方で実現されえ、これには図６に示される単純マルチレベルデータベースが含まれる。もちろんより少ない、またはより多い個数のレベルが存在しえ、また、異なるタイプの階層中に配置されたより少ない、またはより多い個数のデータベースサーバが存在しえる。この例では、データベースサーバ４１０、４１２、および４１４は、大きな会社の部門に関連付けられたサーバを表す。データベースサーバ４２０（および示されない他のもの）は、示される３つの部（および示されない他のもの）を有する会社内の事業部レベルを表す。データベースサーバ４３０は、本社オフィスと関連付けられ、他の会社または子会社に対応する他のサーバともリンクされえ、グローバルハッシュオーソリティが存在しえる次のより高いレベルへのリンクをも有しえる。

それぞれのデータベースサーバと関連付けられているのは、図２に示されるようにおそらくは実現された、または同様に機能するデータ構造を用いるハッシュオーソリティテーブル（例えばテーブル４１１）である。特定のレベルにおけるそれぞれのテーブルは、そのレベルにおけるサーバに記憶されるファイル（およびそれらに関連付けられたハッシュ値）だけでなく、次のより低いレベルにおける全てのファイルも表す。このようにして、与えられたレベルにおけるハッシュオーソリティテーブルは、より低いレベルにおける全てのコンテンツを知っており、同時にそのサーバにおいて記憶されるコンテンツも知っている。このマルチレベルデータベース実施形態は、効率、スケーラビリティおよびローカル処理のために分散化されたコンピュータを用いる必要に対応すると同時に、与えられたレベルのハッシュオーソリティテーブルが、それより下のコンテンツを追跡するだけでなく、そのコンテンツの完全性も検証することを可能にする。例えば、もし同じファイルがデータベース内の異なるデータベースサーバに追加されるなら、このファイルの複数のコピーが異なるサーバ上に存在し、異なるハッシュオーソリティテーブル中に同一のエントリが存在することになる。もし悪意を持つ者がデータベース内のファイルのうちの一つのコピーを変更することに成功すると、この不正なコピーは、真のコピーの完全性に疑いを抱かせることになるかもしれない。以下の記載はこれらの問題に対処する。

図７は、マルチレベルデータベースにファイルを追加するある技術を記載するフローチャートである。４５０において、コンピュータファイル（または他のディジタル情報）が得られ、このファイルがデータベースに追加されなければならないという指示がユーザ（または他のソフトウェアアプリケーション）から受け取られる。４５４において、ファイルのアドレスハッシュ値（ＡＨ）および検証ハッシュ値（ＶＨ）が計算される。４５８においてファイルは、ローカルサーバ４１０（例えば）上のアドレスＡＨに記憶され、計算されたＡＨ−ＶＨペアはローカルテーブル４１１（例えば）に追加される。４６６において計算されたＡＨ−ＶＨペアは、もしまだ存在しないならこのペアをテーブル４２１に追加する意図で、次のレベル、すなわちデータベースサーバ４２０へと送られる。説明の簡単のためにこのファイルはまだサーバ４１０上に存在していないと仮定するが、このファイルが以前に記憶されたかをチェックするためには図３の実施形態が用いられえる。

ファイルがデータベースに追加されるとき（例えば図３および図７におけるように）、システムは、まずそのファイルがすでにデータベース中に存在するかどうかをチェックしえ、またはそれはチェックしないことを選択しえる。システムがチェックするかどうかは、さまざまなファクタの中でもとりわけ、コンピュータファイル中に含まれる情報の種類に依存する、実現する上での詳細事項である。例えばもしそのコンピュータファイルがＭＲＩデータまたはＸ線データを含むなら、あるファイルのコンテンツが他のファイルのコンテンツと似ていないことはほぼ確実である。よって効率のために、そのファイルが既にデータベース中に存在するかを調べるためにチェックする必要はなく、それは全く同じファイルが既に存在する確からしさが無いからである。一方、もしそのファイルが、多くの従業員が会社のデータベースに記憶しようとする、よくある電子メールの添付を表すなら、そのようなファイルが既にデータベースに追加されているかをまず調べるためにチェックすることが有用だろう。システムがまずチェックするかどうかは、他のファクタにも依存しえる。

４７０において、サーバ４１０から受け取られたＡＨ−ＶＨペアは、次のより高いレベルにあるテーブル４２１中に既存のエントリと比較される。同様のエントリが存在するかどうかに依存して、３つの可能な結果がこの比較にはある。もしテーブル４１１から渡されたＡＨ値に対応するＡＨ値がテーブル４２１にないなら、テーブル４２１にはサーバ４１０に追加されたファイルに対応するエントリが存在せず、このファイルはサーバ４２０に追加されていないと同時に、その他のより低いレベルのサーバの任意のもの（この例では４１２および４１４）にも追加されていないと決定される。もしこのようなシチュエーションなら、４７４においてテーブル４１１から渡されたＡＨ−ＶＨペアはテーブル４２１にエントリとして追加される。サーバ４１０上に記憶されたファイルは、サーバ４２０にもコピーされえるが、これは厳密には必要ではない。もうテーブル４２１もＡＨ−ＶＨペアを含み、これはより低いレベルのサーバのうちの少なくとも１つが対応するコンピュータファイルを含むことを示す。このペアがテーブルに追加された後で、フローはステップ４６６へとループバックし、ここで同じＡＨ−ＶＨペアが次のより高いレベル（サーバ４３０およびテーブル４３１）へ渡され、次のより高いレベルにおいて一致するものが存在するかをチェックして調べる。この受け渡しおよびチェックは、全てのレベルが尽くされるまで続く。

こんどはステップ４７０に戻り、もしテーブル４１１から渡されたＡＨ−ＶＨペアが正確に一致する（すなわちＡＨ値およびＶＨ値が一致する）なら、これは、サーバ４１０に今追加されたそのコンピュータファイルが、サーバ４２０の中に、またはおそらくはそのより低いレベルのサーバのうちの１つの中にも存在することを示す。４７８においては、システムの実現方法がファイルのコピーのうちの１つが消去されることを要求しない限り、アクションは必要とされない。（これは、記憶容量を節約するために、任意の与えられたファイルは分散化された環境では一度しか記憶されないと断定するメカニズムの基礎となりえる。）４７４および４７８の両方において、ＡＨが、ファイルについてのユニークなアドレスとしてリクエスタに戻される。４７８の後、プロセスは終了する。

しかしもしＡＨ値が一致するが、ＶＨ値が一致しないなら、これは４８２で報告される問題を表す。前述のようにこの問題は、衝突、技術的誤動作またはハッシュ攻撃でありえる。ステップ３４０において記載されたアクションのような修正アクションが４８６において取られえる。任意の適切なアクションが取られた後で、プロセスは終了する。他の実施形態において、システムは、ステップ４８６の後にステップ４６６に制御を移すよう決定しえ、ここでは前述のようにＡＨ−ＶＨペアは次のより高いレベルへと渡される。

他の前述のような実施形態は、図６のマルチレベルデータベースを用いて、または同様の分散化されたデータベースを用いて実現されえる。例えば、図４で記載された取り出し実施形態が、分散化されたデータベース上で実現されえ、この場合は、ステップ２６８は、単一のサーバではなく、さまざまなデータベースサーバ群にわたって検索する。同様に、図５で記載された完全性チェックの実施形態は、分散化されたデータベース上で実現されえ、そのときはステップ３０４のループは、さまざまなデータベースサーバ群上にある全てのファイルを考慮することになる。

既存のコンテンツアドレス可能な記憶システムへのハッシュオーソリティ機能の追加：
図８は、既存のコンテンツアドレス可能な記憶システムにハッシュオーソリティ機能を追加するある技術を記載するフローチャートである。先行技術はコンテンツアドレス可能な記憶技術を記載し、これによれば与えられたファイルについてハッシュ関数が用いられてユニークなメッセージダイジェストを生成する。ファイルがコンテンツアドレス可能な記憶（ＣＡＳ）システムに記憶されるとき、そのメッセージダイジェストは、ユニークにそのファイルをアドレスするためだけではなく、ファイルのコンテンツを検証するためにも用いられえる。以下の実施形態を用いれば、ここで記載されるようなハッシュオーソリティ機能を、そのようなＣＡＳシステムに追加する（すなわち、第２検証ハッシュ関数の使用を追加する）ことが可能である。７０４において、図２のそれと類似のハッシュオーソリティテーブルまたは類似のデータ構造が作られてアドレスハッシュ値（ＡＨ）および検証ハッシュ値（ＶＨ）を保持する。既存のＣＡＳシステムは、コンテンツアドレスまたはアドレスハッシュ値（ＡＨ）をそれぞれのファイルについて生成するために、特定のハッシュ関数（以下ではアドレシングハッシュ関数と呼ぶ）を既に利用している。これらＡＨ値は、新しく作られたハッシュオーソリティテーブルの第１カラムに置かれ、一方、第２カラムはそれぞれのファイルについて検証ハッシュ関数によって生成された検証ハッシュ値を保持する。好ましくは検証ハッシュ関数は、アドレシングハッシュ関数よりも強い、異なるハッシュ関数である。

７０８において、データベース内のそれぞれのファイルまたはコンテンツアドレスにわたって反復するループが始まる。７１２において、そのアドレスハッシュ値（ＡＨ）つまりコンテンツアドレスと共に、次のファイルが得られる。７１６において、検証ハッシュ関数が用いられてそのファイルについてのＶＨを計算する。それから７２０においてこのＡＨ−ＶＨペアがハッシュオーソリティテーブルにエントリとして追加される。７２４において、ループはデータベース内の次のファイルへと続く。いったんデータベース内の全てのファイルが処理され、それらのＡＨ−ＶＨペアがテーブルにエンターされると、７２８において、新しいハッシュオーソリティメカニズムがアクティベートされる。このアクティベーションは、任意の将来の追加、取り出しまたは完全性チェックプロセスがハッシュオーソリティテーブルを前述のように利用することを意味する。

検証ハッシュ関数のアップグレード：
図９は、検証ハッシュ関数をアップグレードする技術を記載するフローチャートである。前述のように、検証ハッシュ関数は、ファイルのコンテンツを検証するためにアドレシングハッシュ関数に加えて用いられる。より完全な完全性を提供するために、既存の検証ハッシュ関数を置き換えること、または第２検証ハッシュ関数をシステムに追加することも可能である。例えば、もし２５６ビット検証ハッシュ関数が現在用いられているなら、５１２ビット検証ハッシュ関数が追加され、用いられてもよい。以下は、第２検証ハッシュ関数が第１検証ハッシュ関数と共に用いられる技術を記載するが、第１検証ハッシュ関数を第２検証ハッシュ関数で置換することも可能である。

ステップ７４０は、データベース内の全てのファイルにわたって反復するループを始める。このループはそれぞれのファイルを、それらのファイル名または計算されたハッシュ値を介して順番に参照し、またはハッシュオーソリティテーブルを用いてそれぞれのファイルについて反復する。７４４において、処理されるべき次のファイルがデータベースから得られる。

７４８において、新しい検証ハッシュ関数が用いられてＶＨ’、つまりそのファイルについての新しい検証ハッシュ値を計算する。７５２において、新しい検証ハッシュ関数を用いて計算された検証ハッシュ値の全てを保持するテーブルに第３カラムを例えば追加することによって、ＶＨ’がハッシュオーソリティテーブルに追加される。例えば図１１に示されるようである。よってテーブル内のファイルについての与えられたエントリは、３つのハッシュ値を有する。すなわち、アドレスハッシュのための第１値、第１検証ハッシュのための第２値、および第２検証ハッシュのための第３値である。もちろん代替の実施形態においては、第２検証ハッシュ値は単に第１検証ハッシュ値を置き換え、テーブルが２つのカラムのままであってもよい。７５６において次のファイルが処理される。

いったん全てのファイルが処理されると、７６０において、システムは、新しいアップグレードされた検証ハッシュ関数の使用を、システム内でその存在をフラグを付けることによってアクティベートする。アップグレードされたハッシュ関数の存在は、追加、取り出しおよび完全性チェックプロセスについて影響を有する。例えば、ファイルが追加されるとき、両方の検証ハッシュ関数が用いられて、テーブルに追加される２つの異なる検証ハッシュ値を計算する。同様に、ファイルが取り出されるとき、両方の検証ハッシュ関数が用いられて、そのファイルのコンテンツを検証する。完全性チェックのプロセスも両方の検証ハッシュ関数を用いることになる。

図１０は、ハッシュオーソリティテーブルのためにセキュリティを提供するのに用いられえるさらなる技術を記載するフローチャートである。図１１は、さらなるセキュリティ手段を有するハッシュオーソリティテーブル８００のある実施形態を示す。テーブル８００は、アドレスハッシュ値のためのカラム８０２、第１検証ハッシュ関数値のためのカラム８０４、第２検証ハッシュ関数値のためのカラム８０６、タイムスタンプのためのカラム８０８、およびディジタル署名のためのカラム８１０を含む。このテーブルは、第２検証ハッシュ関数が用いられる実施形態を実現するが、このさらなるセキュリティ技術がハッシュオーソリティテーブルの実施形態と共に用いられえる。

さらなるセキュリティ技術は好ましくはステップ７７０において用いられ、ここで任意の処理のあいだに、ハッシュオーソリティテーブル内のレコードが追加または変更される。例えば、新しいファイルがデータベースに追加されるときにはレコードが追加され、新しい検証ハッシュ関数値が追加され、またはマッピングが図１５に記載され後述のように追加されるときにはレコードが変更される。テーブル内のエントリへの任意の追加、またはその変更は、これらセキュリティ技術の使用を要求する。これらのシチュエーションにおいては、以下の追加ステップを行うことが適切でありえる。

７７４において、レコード内の既存のエントリ（例えばカラム８０２〜８０６）は、任意の適切なタイムスタンプ方法を用いてタイムスタンプが押される。７７８において、タイムスタンプがカラム８０８内のレコードへ追加される。７８２において、ハッシュオーソリティを認証するために、任意の適切なディジタル署名を用いてそのレコードについてディジタル署名が作られる。このディジタル署名は、ＡＨおよびＶＨ値、タイムスタンプおよび前のレコードのディジタル署名を含む、そのレコード内の任意の適切な情報を含みえる。７８６において、ディジタル署名がカラム８１０内のレコードに追加される。

ユニークな識別子としての乱数の使用：
いったんアドレシングおよび検証の異なる機能が２つの別個のハッシュ関数によって扱われえる（前述のように）ことが判れば、ファイルをユニークに識別し、データベース内のそのユニークなアドレスとして機能するために、アドレシングハッシュ関数によって生成されたものとは異なるユニークな数が用いられえることがさらに判る。換言すれば、アドレシングハッシュ関数は検証目的に用いられるのではないので（別個の検証ハッシュ関数の使用のために）、ユニークなアドレスをファイルのために生成するためのユニークな数を生成するアドレシングハッシュ関数を使うことは厳しく必要というわけでもないだろう。これらの目的のために、もしファイルをアドレスするための、充分に大きな乱数がユニークな識別子として生成されるなら、ファイルのコンテンツを検証するために検証ハッシュ関数がやはり用いられえ、同じ効果を得ることになろう。簡単に言えば、アドレシングハッシュ関数は、ファイルについてのユニークなアドレスとして用いられるべき、適切なだけ充分に大きい乱数を発生する乱数発生器によって置き換えられえる。

非常にさまざまな種類の乱数発生器が用いられえる。乱数発生器の知見および使用はこの技術でよく知られている。例として、用いられえる乱数発生技術には、時間、温度またはノイズ測定値などのようなシード値を用いて疑似乱数を発生することが含まれる。発生される乱数のサイズは、それぞれの実現例および発生される乱数の全てのもの中におけるユニークさを確実にするシステムの操作者の要求によって変化する。少なくとも１２８ビット（その２進形態で）を有する乱数が、公開または半公開の応用例（典型的にはインターネット上の）で衝突のリスクが非常に低いことを適切に保証するために必要とされよう。ある実施形態において、乱数発生器は、衝突を避けるのに適切に充分に長い１２８ビットの乱数を発生し、これは１２８ビットのアドレシングハッシュ関数を実現した（または実現する）システムとの互換性を可能にする。もちろんより長い乱数も用いられえる。

図１２は、ファイルについての対応する乱数と共に任意の個数のファイルについての検証ハッシュ値を含むテーブル５００を示す。ある実施形態においてテーブル５００は、「識別子オーソリティ」テーブルと名付けられている。データベースに含まれる特定のファイルについて、テーブル５００は、そのファイルについての乱数および検証ハッシュ関数を用いて計算されたそのファイルについてのハッシュ値を保持する。（もちろん１つより多い検証ハッシュ関数が存在する代替の実施形態も用いられえる。）テーブル５００は、乱数発生器を用いて計算された乱数（Ｒ）を保持するカラム５０４およびハッシュ関数を用いて計算された検証ハッシュ値（ＶＨ）を保持するカラム５０８を含む。それぞれのロウは、与えられたファイルに対応する。例えば、ロウ５１４はファイルＷに対応し、ファイルＡについてのＲを含む。ファイルＡについてのＶＨは、２５６ビットのハッシュ関数を例えば用いて計算される。ロウ５１４は、特定のファイルＷについて、そのＲがそのＶＨと関連付けられて記憶され、よって特定のファイルについてのＲを参照してそのＶＨが得られ、またその逆も得られるようになっている。

テーブル５００は、記憶されているファイルの個数に依存して任意の個数のエントリ（またはレコード）を有しえる。テーブル５００は、単一のコンピュータ上に、コンピュータ群のネットワーク上に、コンピュータ群の分散化されたネットワーク上に、またはファイルまたは他のディジタル情報を記憶するのに適切な任意のデータベース内に記憶されるファイルと関連付けられえる。さらにテーブル５００は、当業者によって理解されるようにハッシュ関数、タイムスタンプおよび／またはディジタル署名を用いてそのエントリが保護されえる。さらに特定のファイルについてのＲおよびＶＨは、必ずしもテーブルでなくても任意の他の適切なデータ構造を用いて互いに関連付けられえる。

テーブル５００にまた含まれるのは、ファイルの複製がデータベースに追加されるときに有用な実際のアドレスカラム５１２である。例えば、ファイルＺがデータベースに追加され、そのＲ−ＶＨペアがロウ５２０に追加された後で、ファイルＺがファイルＸの正確な複製であることが発見されえる。この認識は、ファイルＺがデータベースに追加されつつあるときか、または最適化プロセスのあいだに後で起こりえる。ファイルＺについての乱数が既に発生され、カラム５０４に追加され、ユーザまたはアプリケーションに分配されているので、ロウ５２０を消去する（またはそれをエンターしない）のは不自然であるが、これはさまざまな当事者が、それを参照する唯一の手段としてファイルＺについて発生された乱数を用いているかもしれないからである。このシチュエーションにおいては、物理的にファイルＺをデータベースに追加する必要がない（またはおそらくはファイルＺが消去されている）ので、ファイルＸについての乱数は、ロウ５２０のカラム５１２にエンターされ、それによってファイルＺを探す者に、ファイルをアドレスするためにはファイルＸの乱数が用いられなければならないことを示す。ファイルＸおよびファイルＺは、複製であるので、ファイルＸのための乱数をアドレスとして用いることは適切である。実現例に依存して、カラム５１２内のブランクエントリ（または他の適切なフラグ）は、調べるべき他のアドレスが存在しないことをシステムに対して示す。もちろん、同じファイルを全て参照する多くのエントリがテーブル５００には存在しえる。この場合、そのファイルの１つのコピーだけが維持される必要があり、消去された（または追加されなかった）そのファイルのコピーについてのテーブル５００内のエントリはカラム５１２を利用して、そのファイルの実際のアドレスを示す。

図１３は、それぞれのファイルについてユニークなアドレスを発生する機能としてシステムが乱数発生器を用いるデータベースにファイルを追加する技術を記載するフローチャートである。５５０において追加されるべきファイルがユニークなまたはソフトウェアアプリケーションから得られる。５５４において適切な乱数発生器が用いられて乱数Ｒをそのファイルについて作る。この乱数は好ましくは、データベースに追加されるそれぞれのファイルについてユニークなアドレスを提供するのに適切に充分に長いビットのストリングである。先行技術で説明され図１に示されるように、このビットストリングは、容易にユーザが読める識別子を提供するために、またはファイルについてのファイル名として働かせるために、エンコードされえる。図１にまた示されるように、乱数は、ＵＲＬまたは他の適切な識別子の一部を形成しえる。代替の実施形態においては、ステップ５５４は、ファイルを得てすぐに実行される必要はないが、ステップ５６０と共に、またはステップ５７２と共に実行されえる。５５８においてシステムによって用いられる検証ハッシュ関数が用いられてファイルの検証ハッシュ値（ＶＨ）を計算する。

ファイルが既にデータベース内に存在するかをチェックすることが望ましくない（すなわち単にファイルを直接に追加することが有利である）実施形態においては、ステップ５６２は実行されず、５６０においてファイルはそれからデータベース内のアドレスＲに記憶される。５６８においてＲ−ＶＨペアがそれからハッシュオーソリティテーブルに追加され、Ｒがファイルについてのユニークなアドレスとしてリクエスタに戻され、プロセスは終了する。

ファイルが既にデータベース内に存在するかをチェックすることが望ましい実施形態においては、ステップ５６２は、ファイルについて計算されたＶＨを、テーブルのカラム５０８中の全てのＶＨ値と比較する。もし一致するものが見つからなければ、これはそのファイルが存在せず、制御はステップ５６０に進み、このステップがそのファイルおよびそのＲ−ＶＨペアを前述のように追加する。しかしもし一致するものが見つかれば、これはファイルのコピーが既にデータベース内に存在することを示し、ハッシュオーソリティテーブル内のエントリが既に存在することを示す。ある実施形態においてはそのファイルについての新しい乱数を発生し、新しいエントリをテーブルに追加する必要はない。したがって５８４において、ＶＨの一致に対応するテーブル中のエントリからの乱数がユーザ（または他のアプリケーション）にデータベース内のそのファイルについてのユニークなアドレスとして返される。この実施形態において、新しい乱数は発生される必要はなく、新しいエントリがテーブルに追加される必要はなく、このファイルはデータベースに追加される必要はないが、それはそのファイルが既にデータベース内に存在するからである。ステップ５５８で計算されたＶＨに一致するＶＨを有するエントリをテーブル内で単に見つけることによって、見つかったエントリからの乱数を用いることによって、そのファイルを特定するために用いられる乱数が得られる。５８０の後にプロセスは終了する。

ステップ５６２の他のバリエーションにおいては、乱数が既にそのファイルについて発生され、既にユーザまたは他のソフトウェアアプリケーションに返されているシチュエーションが存在しえる。このシチュエーションにおいては、もし５６２においてＶＨの一致が存在し、ファイルのコピーが既にデータベース内に存在すると決定されるなら、やはり５７２においてＲ−ＶＨペアをテーブルに追加することが望ましい。このＲ−ＶＨペアはテーブルに追加されるが、それは将来そのファイルを参照するのを助けるために乱数Ｒが既にユーザに返されており、よってテーブル内には乱数Ｒに対応するエントリが存在しなければならないからである。しかしこのシナリオにおいては、ファイルの他のコピーを追加することは厳しく必要とされないので、５７６において、新しく追加されるＲ−ＶＨペアから既存の乱数へのマッピングが追加される。ファイルのコピーを追加する必要はないが、それはファイルが既にデータベース内に存在するからである。

例としてテーブル５００のロウ５２０を考え、ここではファイルＺがデータベースに追加されることが望まれるが、５６２においてはファイルＺがファイルＸの正確なコピーであることが決定される。（ファイルＺのＶＨがファイルＸのＶＨに一致するので、これらファイル群が同じであることが決定されえる。）ファイルＺはデータベースに追加される必要はないが、それはファイルＸが既に存在しているからであるが、５７２においてロウ５２０がテーブルに追加され、ファイルＺについての新しく発生された乱数Ｒ（５５４において作られた）およびファイルＺについてのＶＨを提供する。５７６において、ファイルＺについての乱数Ｚからファイルの実際のアドレスへのマッピングを提供するために、カラム５０４からのファイルＸについての乱数が、ロウ５２０においてカラム５１２に追加される。もちろんもし実際にファイルＺ（ファイルＸの複製）を追加することが望ましいなら、ステップ５７６を実行し、カラム５１２を利用する必要はないだろうが、それはカラム５０４におけるファイルＺについての乱数がそのときファイルＺをデータベース内で正確に特定するはずだからである。５８０の後にプロセスは終了する。

最適化実施形態は、乱数発生器を用いられて実現されるデータベース内でファイルの複数のコピーを扱う。この最適化において、データベース内の与えられたファイルの複数のコピーは、データベース内のファイルの単一のコピーだけを残して消去される。この最適化は、一致するＶＨ値を探して識別子オーソリティテーブル５００内の全てのエントリを通してルーピングすることによって実行されえる。一致するカラム５０８におけるＶＨ値は、同じファイルのコピーを示す。一致を探してテーブル内のエントリ群のリストを通してルーピングするアルゴリズムは、当業者には知られている。特定のファイルについての２個より多い一致がいったん見つかると、カラム５０４の乱数は、ファイルのコピーのそれぞれをアドレスし、適宜、複数のコピーを消去するのに用いられる。好ましくはファイルの単一のコピーが保持され、テーブル中のそれぞれのＲ−ＶＨペアエントリも保持される。それぞれのエントリは保持されるが、それはそれぞれのファイルについてのアドレスＲが、将来、このファイルを参照するためにこのアドレスに頼るユーザおよびアプリケーションに既に分配されているからである。最後に、ファイルが消去されたエントリを、ファイルの単一の残っているコピーへとマッピングするために、識別子オーソリティテーブルがアップデートされる。例えば前述のように、もしファイルＸおよびファイルＺがコピーであり、もしファイルＺがデータベースから消去されなければならないなら、ロウ５２０におけるエントリは保持されるが、カラム５１２におけるマッピングは追加され、それによりファイルＺについての乱数をファイルＸについての乱数へマッピングし、よってファイルＺのためのアドレスＲを持った任意のユーザが、ファイルＸのためのアドレスＲにおいてこのファイルのコピーを見つけられるようにする。もちろんこの技術は、与えられたファイルの複数のコピーについてもうまく働く。

図１４は、ファイルを特定するのに乱数が用いられるデータベースからファイルを取り出す技術を記載するフローチャートである。このシチュエーションにおいて、ユーザはファイルをデータベースから取り出したい。６１０においてユーザまたはソフトウェアアプリケーションは、特定のファイルを希望し、そのファイルについての以前に記憶された乱数（Ｒ）に基づいてそのファイルを探す。所望のファイルについてのＲは、Ｒを記憶する任意の適切なソースからユーザまたはアプリケーションによって得られる。このユーザまたはアプリケーションは、所望のファイルのこのＲをシステムに示す。６１４においてシステムはＲを用いて、所望のファイルがデータベース内に存在するかをＲをファイルのアドレスとして、またはおそらくはそのファイル名として用いることによって決定する。このファイルについてのＶＨを見つけるために６１８において識別子オーソリティテーブルが調べられる。

６２２において、データベースで見つかったファイルの検証ハッシュ値（ＶＨ）が計算される。６２６においてこの計算されたＶＨが、識別子オーソリティテーブル内のエントリからのこのファイルについてのＶＨと比較される。もしＶＨ値が異なるなら、６３４において、ステップ２５２において前述の同じ可能性がある問題を示すことで問題がユーザに報告され、この場合、ハッシュ衝突はありえないことを除くが、それはファイルについてのアドレスを計算するためにハッシュ関数が用いられていない（乱数が用いられている）からである。もしＶＨ値が同じであるなら、これはアドレスＲにおいて見つかったファイルが、ファイルが最初にデータベースに追加されたときにこの位置にもともと記憶されたのと同じファイルであることを示す。このステップにおける同じＶＨ値は、見つかったファイルがユーザによって望まれるファイルであることを信頼性を持って示す。６３０においてファイルは、それをリクエストしたユーザまたはソフトウェアアプリケーションに届けられる。

図１５は、乱数が用いられてファイルをユニークに特定する実施形態に、前述の追加セキュリティ技術も適用可能である識別子オーソリティテーブル８４０のある実施形態を示す。追加の技術は、レコードが追加されるとき（すなわちファイルまたは新しいＲ−ＶＨペアが追加されるとき）、またはレコードが変更されるとき（例えば実際のアドレスが追加されるとき）に用いられえる。例えばタイムスタンプ８４８は、カラム８４２〜８４６に適用され、ディジタル署名８５０は、以前のレコードのディジタル署名に加えて、以前のカラムの全てを含む。もちろん、タイムスタンプおよびディジタル署名にフィールドが含まれるバリエーションも可能である。

コンピュータシステムとしての実施形態：
本発明は、さまざまなコンピュータ上で実現されえる。ある想定された実施形態において、文書を記憶および読み出しするのに用いられるコンピュータハードウェアは、マサチューセッツ州、Hopkinton のEMC Corporationから入手可能なCenteraブランドのコンピュータである。このCentera製品説明ガイドは、このコンピュータおよびそのソフトウェアを記述し、http://www.emc.com/pdf/products/centera/centera_guide.pdfにおいて入手可能であり、ここで参照によって援用される。このシステムソフトウェアはLinuxおよびJAVA（登録商標）を用いて記述されえる。この実施形態において、Centeraコンピュータは、図１
に示されるように、ユーザがメッセージダイジェストをＵＲＬを介して供給できるようにするウェブサイトのバックエンドであることが想定される。ウェブサイトサーバ上で動作するシステムソフトウェアは、Centeraおよびユーザ間をインタフェースし、ここで記載したようにファイル挿入および取り出しを可能にする。乱数発生器の使用を伴う実施形態においては、任意の汎用コンピュータ上で実現されえ、マイクロソフト社から入手可能な．ＮＥＴおよびＣ＃（「Ｃシャープ」）言語と併せてＬｉｎｕｘも用いられえる。

他の実施形態において、文書記憶、システムソフトウェアおよびユーザインタフェースは、全て単一のコンピュータ上に常駐している。他の実施形態において、サービスプロバイダは、ユーザとインタフェースするフロントエンドユーザインタフェースをインターネットを介して提供するが、それからメッセージダイジェストによって特定された文書をそれ自身に記憶するのではなく、インターネットまたは他のワールドワイドネットワーク上で検索する。または全く分散されたピアツーピアシステムは、そのコンテンツを読み出しおよび保証するためのコンテンツアドレス可能な記憶だけに基づく。

図１６Ａおよび１６Ｂは、本発明の実施形態を実現するのに適するコンピュータシステム９００を示す。図１６Ａは、コンピュータの一つの可能な物理的形態を示す。もちろんコンピュータシステムは、集積回路、プリント基板、および小型携帯機器から、大型のスーパーコンピュータに至るまで多くの物理的形態をとりえる。コンピュータシステム９００は、モニタ９０２、ディスプレイ９０４、筐体９０６、ディスクドライブ９０８、キーボード９１０、およびマウス９１２を含む。ディスク９１４は、データをコンピュータシステム９００に転送し、かつデータをコンピュータシステム９００から転送するために用いられるコンピュータで読み取り可能な媒体である。

図１６Ｂは、コンピュータ９００のブロック図の例である。システムバス９２０に接続されているのは、さまざまなサブシステムである。プロセッサ（群）９２２（中央処理装置群、すなわちＣＰＵ群とも呼ばれる）は、メモリ９２４を含む記憶装置に結合されている。メモリ９２４は、ランダムアクセスメモリ（ＲＡＭ）および読み出し専用メモリ（ＲＯＭ）を含む。この技術ではよく知られるようにＲＯＭは、データおよび命令を単一方向にＣＰＵおよびＲＡＭに転送するようにはたらき、ＲＡＭは、典型的にはデータおよび命令を双方向に転送するのに用いられる。メモリのこれら両方のタイプは、以下に述べるコンピュータ読み出し可能な適当な媒体を含みえる。固定ディスク９２６はまた、双方向でＣＰＵ９２２に結合され、追加のデータ記憶容量を提供し、また以下に述べるコンピュータ読み出し可能な適当な媒体を含みえる。固定ディスク９２６は、プログラム、データなどを記憶するのに用いられえて、典型的には一次記憶よりも低速な二次記憶媒体（ハードディスクのような）である。固定ディスク９２６内に保持された情報は、適切な場合においては、メモリ９２４の仮想メモリとして標準的なかたちで統合されえることが理解されよう。取り外し可能なディスク９１４は、以下に説明するコンピュータ読み出し可能な媒体のいかなる形態をも取りえる。

ＣＰＵ９２２はまた、ディスプレイ９０４、キーボード９１０、マウス９１２およびスピーカ９３０のようなさまざまな入力／出力装置に結合される。一般に入力／出力装置は、ビデオディスプレイ、トラックボール、マウス、キーボード、マイク、タッチパネルディスプレイ、トランスデューサカードリーダ、磁気または紙テープリーダ、タブレット、スタイラス、音声または手書き認識機、生体情報読み取り機、または他のコンピュータのいずれでもよい。ＣＰＵ９２２は追加で、ネットワークインタフェース９４０を用いて他のコンピュータまたは通信ネットワークに結合されてもよい。そのようなネットワークインタフェースによりＣＰＵは、上述の方法ステップを実行する過程で、ネットワークから情報を受け取り、または情報をネットワークに出力してもよい。さらに本発明の方法の実施形態は、ＣＰＵ９２２上だけで実行されてもよく、またはインターネットのようなネットワーク上で、処理の一部を担当する遠隔地にあるＣＰＵと協働して実行されてもよい。

さらに本発明の実施形態は、コンピュータによって実現できるさまざまな操作を実行するコンピュータコードを格納した、コンピュータによって読み出し可能な媒体を持つコンピュータ記憶製品に関する。媒体およびコンピュータコードは、本発明の目的のために特別に設計され構築されたものでもよく、またはコンピュータソフトウェア技術の当業者に既知の利用可能なものであってもよい。コンピュータ読み出し可能な媒体の例としては、これらに限定はされないが、ハードディスク、フレキシブルディスク、および磁気テープのような磁気媒体、ＣＤ−ＲＯＭおよびホログラフィックデバイスのような光媒体、フロプティカルディスクのような光磁気媒体、特定アプリケーション向け集積回路（ＡＳＩＣ）、プログラム可能な論理デバイス（ＰＬＤ）、およびＲＯＭおよびＲＡＭデバイスのように、プログラムコードを記憶し実行するために特別に構成されたハードウェアデバイスが挙げられる。コンピュータコードの例としては、コンパイラによって生成される機械語、およびインタープリタを用いてコンピュータによって実行可能なより高いレベルのコードを含むファイルが挙げられる。

上述の本発明は、明瞭な理解の目的にためにある程度詳細に説明されてきたが、ある種の変更および改変が添付の特許請求の範囲内で実施されえることは明らかだろう。本発明の装置および方法を実現する多くの手法が存在することに注意されたい。よって説明された実施形態は、例示的であって限定的ではないと解釈されなければならず、本発明はここに挙げられた詳細に限定されるべきではなく、特許請求の範囲およびその等価物の全ての範囲によって定義されなければならない。

文書についてのハッシュベースのユニークな識別子を作る技術を示す説明図である。 異なるハッシュ関数を用いた計算された任意の個数のファイルについてのハッシュ値を含むテーブルを示す説明図である。 データベースにファイルを追加するある実施形態を記載するフローチャートである。 データベースからファイルが取り出されるある実施形態を記載するフローチャートである。 本発明の実施形態を用いて実現されたデータベース内のファイルの完全性をチェックする技術を記載するフローチャートである。 コンピュータファイルを保持するデータベースが多くのサーバコンピュータ中に分散化されているマルチレベルデータベースを示す説明図である。 マルチレベルデータベースへファイルを追加するある技術を記載するフローチャートである。 既存のコンテンツアドレス可能な記憶システムにハッシュオーソリティ機能を追加するある技術を記載するフローチャートである。 検証ハッシュ関数をアップグレードする技術を記載するフローチャートである。 ハッシュオーソリティテーブルにセキュリティを提供するのに用いられえるさらなる技術を記載するフローチャートである。 さらなるセキュリティ手段を有するハッシュオーソリティテーブルのある実施形態を示す説明図である。 任意の個数のファイルについての検証ハッシュ値と共に、ファイルについての対応する乱数を含むテーブルを示す説明図である。 それぞれのファイルについてユニークなアドレスを発生するための関数としてシステムが乱数発生器を用いるデータベースにファイルを追加する技術を記載するフローチャートである。 ファイルを特定するのに乱数が用いられるデータベースからファイルを取り出す技術を記載するフローチャートである。 さらなるセキュリティ技術も適用可能な識別子オーソリティテーブルのある実施形態を示す説明図である。 本発明の実施形態を実現するのに適切なコンピュータシステムを示す説明図である。 本発明の実施形態を実現するのに適切なコンピュータシステムの構成を示す説明図である。

Claims (18)

1. コンピュータを用いてコンピュータファイルをデータベースに追加する方法であって、
   前記データベースに追加すべき前記コンピュータファイルを受け取ること、
   前記コンピュータファイルについてのユニークな識別子であって、前記データベースにおけるユニークな位置を識別するのに用いるユニークな識別子を、前記コンピュータが計算すること、
   前記コンピュータファイルについての、前記ユニークな識別子とは異なる検証ハッシュ値であって、前記コンピュータファイルの内容を検証するのに用いられる検証ハッシュ値を、検証ハッシュ関数を用いて、前記コンピュータが計算すること、
   前記コンピュータファイルを前記データベースにおいて前記ユニークな識別子によって特定される位置に記憶すること、
   前記ユニークな識別子および前記検証ハッシュ値を対応付けたユニークな識別子−検証ハッシュ値のペアを、前記データベースに関連付けられたデータ構造に、前記コンピュータが追加すること、および
   前記コンピュータのメモリに前記データ構造を保存すること
   を含み、
   前記ユニークな識別子−検証ハッシュ値のペアは前記データ構造に関連付けられ、それにより前記ユニークな識別子−検証ハッシュ値のペアの前記データ構造への前記追加は、前記データベース内の前記コンピュータファイルの存在を示しており、
   更に、前記コンピュータが、前記コンピュータファイルを、前記メモリに記憶された前記データ構造へ追加するに際して、
   前記コンピュータファイルのコピーが前記データベースに存在するであるかを、前記ユニークな識別子と一致する値を求めて前記メモリに記憶された前記データ構造を検索することによって前記コンピュータが決定すること、
   前記コンピュータファイルのコピーが前記データベースに存在すると決定されるとき、前記コンピュータファイルの前記コピーについてのコピーハッシュ値を、前記コンピュータが前記検証ハッシュ関数を用いて計算すること、および前記検証ハッシュ値を前記コンピュータが前記コピーハッシュ値と比較すること、
   前記検証ハッシュ値が前記コピーハッシュ値と一致すると決定されるときは、前記コンピュータが所定のアクションを取ること、
   前記検証ハッシュ値が前記コピーハッシュ値と一致しないと決定されたときは、問題を、前記コンピュータが入出力装置を用いてユーザに報知すること、
   を含み、
   前記データ構造はテーブル、リストまたはツリーデータ構造である方法。
2. 請求項１に記載の方法であって、前記ユニークな識別子は第１のハッシュ関数から演算され、前記検証ハッシュ関数は前記第１のハッシュ関数よりもより強いセキュリティを提供する方法。
3. コンピュータを用いて所望のコンピュータファイルをデータベースから取り出す方法であって、
   前記所望のコンピュータファイルについてのユニークな識別子であって、前記データベースにおけるユニークな位置を識別するのに用いるユニークな識別子を前記コンピュータが得ること、
   前記ユニークな識別子を参照として用いて、前記コンピュータが、前記データベースから記憶されたコンピュータファイルを取り出すこと、
   前記ユニークな識別子を用いることによって前記データベースに関連付けられたデータ構造からユニークな識別子−検証ハッシュ値のペアを取り出すことであって、前記データ構造はコンピュータのメモリに保存されており、前記取り出された検証ハッシュ値は検証ハッシュ関数を用いて前記記憶されたコンピュータファイルから前もって導かれており、前記導かれた検証ハッシュ値は前記ユニークな識別子とは異なっており、
   前記検証ハッシュ関数を用いて前記記憶されたコンピュータファイルの内容を検証する検証ハッシュ値を、前記コンピュータが計算すること、
   前記計算された検証ハッシュ値を前記導かれた検証ハッシュ値と、前記コンピュータが比較すること、および
   前記計算された検証ハッシュ値が前記導かれた検証ハッシュ値と一致するときに前記記憶されたコンピュータファイルが前記所望のコンピュータファイルであると前記コンピュータが決定し、前記記憶されたコンピュータファイルの内容の検証に前記計算された検証ハッシュ値を用いることによって、前記所望のコンピュータファイルを、前記コンピュータが前記データベースから取り出すこと
   前記計算された検証ハッシュ値が前記導かれた検証ハッシュ値と一致しないときは、問題を、前記コンピュータが入出力装置を用いてユーザに報知すること、
   を含み、
   前記データ構造はテーブル、リストまたはツリーデータ構造である方法。
4. 請求項３に記載の方法であって、
   前記所望のコンピュータファイルの取り出し要求であって、前記ユニークな識別子を含む取り出し要求をユーザーから受け取ること、
   前記記憶されたコンピュータファイルが前記所望のコンピュータファイルであるとき、前記記憶されたコンピュータファイルを前記ユーザに届けること
   をさらに含む方法。
5. 請求項３に記載の方法であって、
   前記ユニークな識別子を探して前記データ構造を検索することによって記憶されたコンピュータファイルを取り出す前記ステップを実行すること
   をさらに含む方法。
6. 請求項３に記載の方法であって、前記ユニークな識別子は、第１のハッシュ関数を用いて計算され、前記検証ハッシュ関数は前記第１ハッシュ関数よりもより強いセキュリティを提供する方法。
7. コンピュータを用いて、ファイル群のデータベースにハッシュオーソリティ機能を追加する方法であって、
   （Ａ）複数のエントリを含むハッシュオーソリティデータ構造を、テーブル、リストまたはツリーデータ構造として作ること、
   （Ｂ）前記データベースのファイルについてのユニークな識別子であって、前記データベースにおけるユニークな位置を識別するのに用いられるユニークな識別子を、前記コンピュータが取り出すこと、
   （Ｃ）前記データベースから、前記コンピュータが前記ファイルを取り出すこと、
   （Ｄ）前記ファイルについての、前記ユニークな識別子とは異なる検証ハッシュ値であって、前記ファイルの内容を検証するのに用いられる検証ハッシュ値を、検証ハッシュ関数を用いて、前記コンピュータが計算すること、
   （Ｅ）前記ユニークな識別子および前記検証ハッシュ値を対応付けたユニークな識別子−検証ハッシュ値のペアを前記ハッシュオーソリティデータ構造の前記エントリのうちの１つに、前記コンピュータが追加すること、および
   （Ｆ）前記コンピュータのメモリに前記ハッシュオーソリティデータ構造を保存すること
   を含み、
   前記ユニークな識別子−前記検証ハッシュ値のペアは前記データベース内で関連付けられており、
   前記ファイルを、前記コンピュータが前記ユニークな識別子を用いて前記データベースから取り出す際には、前記ハッシュオーソリティ機能を用いて、
   前記検証ハッシュ関数を用いて前記ファイルの内容を検証する検証ハッシュ値を、前記コンピュータが計算し、
   前記計算された検証ハッシュ値を前記ユニークな識別子−前記検証ハッシュ値のペアとして記憶された検証ハッシュ値と、前記コンピュータが比較し、
   前記計算された検証ハッシュ値が前記記憶された検証ハッシュ値と一致するときには前記ファイルが前記所望のファイルであると、前記コンピュータが決定し、
   前記計算された検証ハッシュ値が前記記憶された検証ハッシュ値と一致しないときは、問題を、前記コンピュータが入出力装置を用いてユーザに報知するようにされた
   方法。
8. 請求項７に記載の方法であって、前記ユニークな識別子はアドレシングハッシュ関数から演算され、前記検証ハッシュ関数は前記アドレシングハッシュ関数よりもより強いセキュリティを提供する方法。
9. 請求項７に記載の方法であって、
   前記データベース中の前記複数のファイルのうち、前記取り出されたファイル以外のファイルのそれぞれについて、請求項７のステップ（Ｂ）ないし（Ｅ）を実行すること
   をさらに含む方法。
10. コンピュータを用いて、ファイルのデータベース内の検証ハッシュ関数をアップグレードする方法であって、
    前記ファイルのデータベースを表すデータ構造へアクセスすることであって、前記データ構造は、前記データベース内の前記ファイルのそれぞれについてのユニークな識別子−検証ハッシュ値のペアを含み、前記各ファイルについての前記検証ハッシュ値は前記各ファイルのコンテンツにおいて実行される検証ハッシュ関数を用いて前もって計算され、前記検証ハッシュ値は、前記各ファイルについてのユニークな識別子とは異なっており、前記ユニークな識別子は前記データベースにおけるユニークな位置を識別するのに用いられ、
    前記データベース内の前記ファイルのそれぞれについて、
    前記、前記コンピュータがファイルを取り出すこと、
    より強い検証ハッシュ関数を用いて前記ファイルについての新しい検証ハッシュ値であって、前記ファイルの内容を検証するのに用いる検証ハッシュ値を、前記コンピュータが計算すること、
    前記新しい検証ハッシュ値を前記ファイルの前記ユニークな識別子と関連付けて、前記コンピュータが、前記データ構造に追加し、アップグレードされたユニークな識別子−新しい検証ハッシュ値のペアを前記ファイルについて形成すること、および
    前記コンピュータのメモリに前記データ構造を、テーブル、リストまたはツリーデータ構造として、前記コンピュータが保存すること
    を含み、
    当該検証ハッシュ関数は、前記ファイルを前記ユニークな識別子を用いて前記データベースから取り出す際には、
    前記検証ハッシュ関数を用いて前記ファイルの内容を検証する検証ハッシュ値を、前記コンピュータが計算し、
    前記計算された検証ハッシュ値を前記ユニークな識別子−前記検証ハッシュ値のペアとして記憶された検証ハッシュ値と、前記コンピュータが比較し、
    前記計算された検証ハッシュ値が前記記憶された検証ハッシュ値と一致するときには前記ファイルが前記所望のファイルであると、前記コンピュータが決定し、
    前記計算された検証ハッシュ値が前記記憶された検証ハッシュ値と一致しないときは、問題を、前記コンピュータが入出力装置を用いてユーザに報知するのに用いられる
    方法。
11. 請求項１記載の方法であって、
    前記ユニークな識別子は、識別可能なハッシュ関数を用いて前記コンピュータファイルから計算された識別可能なハッシュ値、乱数発生器を用いて発生された乱数、あるいは擬似乱数発生器を用いて発生された擬似乱数のいずれかである
    方法。
12. 請求項３記載の方法であって、
    前記ユニークな識別子は、識別可能なハッシュ関数を用いて前記コンピュータファイルから計算された識別可能なハッシュ値、乱数発生器を用いて発生された乱数、あるいは擬似乱数発生器を用いて発生された擬似乱数のいずれかである
    方法。
13. 請求項７記載の方法であって、
    前記ユニークな識別子は、識別可能なハッシュ関数を用いて前記コンピュータファイルから計算された識別可能なハッシュ値、乱数発生器を用いて発生された乱数、あるいは擬似乱数発生器を用いて発生された擬似乱数のいずれかである
    方法。
14. 請求項１０記載の方法であって、
    前記ユニークな識別子は、識別可能なハッシュ関数を用いて前記コンピュータファイルから計算された識別可能なハッシュ値、乱数発生器を用いて発生された乱数、あるいは擬似乱数発生器を用いて発生された擬似乱数のいずれかである
    方法。
15. 前記検証ハッシュ値は、ユニークであり、コンテンツベースの識別子である請求項１記載の方法。
16. 前記検証ハッシュ値は、ユニークであり、コンテンツベースの識別子である請求項３記載の方法。
17. 前記検証ハッシュ値は、ユニークであり、コンテンツベースの識別子である請求項７記載の方法。
18. 前記検証ハッシュ値は、ユニークであり、コンテンツベースの識別子である請求項１０記載の方法。

Images