WinFormで適当にそれっぽいものを作って実際に実行してみます。encryptedText;}実行結果:出てきたハッシュをSHA256データベースで検索してみます。今回は、アルゴリズムに集点をおいて、可読性を優先してコードを書いたのもあり速度については一切考慮しておりませんが、一応ランタイムのものと比較してみます。比較にあたって、下記記事を参考にソースコードを拝借いたしました。ありがとうございました。{elapsed.TotalMilliseconds}");}今回は5回ほど計測してみました。それぞれ1000回の試行にかかった平均時間(ミリ秒)です。ランタイムのものと比較すると、約800倍近く時間がかかっていますね。手も足も出ませんでした。1.0187最後に一番苦戦したのは理論代数の分野の理解です。理解できないせいで計算があわず、2時間格闘しました。結局ふわっとしか理解できていません。詳しい方がいらっしゃれば、些細な情報でもコメント欄にて解説頂けるとありがたいです。フルソースコードは僕のGithubリポジトリにあります。当記事内で間違いや誤字脱字等ありましたら、お手数ですがコメント欄にてご指摘いただけますと幸いです。最後まで読んでいただき、ありがとうございました。(不具合修正)一定の文字数を超えると、生成されるハッシュの値が異なる現象その他一部で意図しない動作を確認しました。このプログラムで一定以上の文字数を超えると算出されるハッシュ値が異なるか?結論から申し上げますと、ブロック長の記録の例外処理を完全に忘れていました。「何らかの理由で記録するスペースがなかった場合、次のブロックで記録する」という処理です。ただのヒューマンエラーでした。最初、この謎現象の原因を掴むべくデバッグしていましたら右が正しいものです。ブロック末端&チャンクが異なっています。デバッグを続けていくと、この現象は一定の文字数以上(ブロック数2以上)で発生することがわかりました。したがって、ブロック分割部分で何かしらの問題が発生していると予想できます。そこで、実際に中身を見てました。1ブロック目と2ブロック目のブロックがそれぞれ同一の値となっていることが確認できます。問題の分割関数を覗いてみます。問題箇所を特定できました。人為的ミスは、一歩引いてソースを見てみないと中々発見できませんね。2進数のプレーンテキスト配列の0から512までを毎回コピーしていたことが原因でした。ブロックが複数ある場合にのみ発生する不具合だったので、発見に時間がかかりました。修正後のソースコードは以下の通りです。//ブロックが複数ある場合も想定されるので、//n*512から512先までをコピーしなければいけない。BLOCK_SIZE);以上、折角の機会なので不具合に対する適切な対処法と僕なりのデバッグ手法を紹介してみました。不具合について既知の不具合として、コメント欄にてご指摘いただきました。プレーンテキストの文字数が5文字であり、特定の文字が含まれていると発生する模様。▼2文字分、0が抜け落ちてます。