①ハッシュ値と同じ値が元のデータの中に含まれる
全てのデータ列に対して、データ列のハッシュ値が、そのデータ列の一部になっている、つまり、data.includes(hash(data))
があらゆるデータにとって成り立つと言うことと解釈しました。長さ0のデータの場合のハッシュ値が定義できない、長さ1の場合はそのデータそのものであるなど、既にハッシュ関数とは言えません。
②同じハッシュ値を与える入力値の組み合わせが1つ偶然見つかった
誕生日のパラドックスと同じです。
③入力値の上位数ビットを変更してもハッシュ値が変化しない
無視されるビット列がある時点で、それはすでにハッシュ関数とは言えません。
④ハッシュ関数の設計から10年以上経過した
いつから設計されていたのかは開発者本人しかわからず、構想だけなら公表の10年以上前から設計していた可能性があります。公表の時期では無く設計の時期を問うことは検証不可であり、無意味です。
⑤同じハッシュ値を与える入力値の組み合わせを求める最適なアルゴリズムが見つかった
「最適」の定義が曖昧です。多項式時間のことを意味するのであれば、P≠NP予想の結論次第では、全てのハッシュ関数に多項式時間でとけるアルゴリズムが存在することになります。しかし、AKS素数判定法のように多項式時間のアルゴリズムであっても、実用的であるとは限りません。
⑥ハッシュ値がとりえない値が1つ見つかった
ハッシュ値が2^256のパターンがあるハッシュ関数において、とりえない値が1つあると言うことは、とりえるハッシュ値が2^256-1であると言うことになります。もし、2^256であると発表しているのに、実際は2^256-1であったとするなら、世間では詐欺扱いになります。第一、後からとりえない値が見つかったというのであれば、そもそもから検証不足であり、開発者の能力が不足しています。
⑦ハッシュ値の高速な計算方法がある
「高速」の定義が曖昧です。どんなハッシュ関数であれ、とりえるパターンの数と同じ数だけのPCを用意し、一度にバラバラのデータをハッシュ値を求めることで特定のハッシュ値のデータを探したときの期待値は1です。
まとめ
①ハッシュ関数では無い
②誕生日のパラドックス
③ハッシュ関数では無い
④検証不可
⑤定義が曖昧
⑥検証不足
⑦定義が曖昧
安全を問う以前の問題だと思われます。