Quantcast
Channel: Node.jsタグが付けられた新着記事 - Qiita
Viewing all articles
Browse latest Browse all 9138

「先生!暗号化文字列の復号化が上手くいきません!」「なに!?」

$
0
0

タイトルだけ見ても「なんのこっちゃ」という感じですが、「文字列を暗号化して、DBに格納→DBから取得して、復号化したいのに上手くいかないけどなんで?」という過去の自分を忘れないようにする戒めの記事になります。

結論

上記の原因としては、 暗号化文字列の桁数 > DBの桁数 となっており、DB格納時に切り落とされていたからです。
つまり、適切な暗号化文字列がDBに格納されていないので、復号化に失敗するわけです。
愚かすぎて笑っちゃいますね。ハハハ

関連する箇所のシステム構成

  • API (Flask - python)
    • 暗号化モジュール:cryptography
  • AWS Lambda(Node.js)
    • 暗号化モジュール:crypto
  • Amazon Aurora(DB)

簡単なシステム間の連携の説明

  1. Flask API
    1. 文字列の暗号化
    2. DBへの格納
  2. Lambda
    1. DBからデータの取得
    2. 文字列の復号化を行う

※暗号化のアルゴリズムなどの詳細は省きます。

事象発生までの経緯と結果

  1. Flask API
    1. 成功:文字列の暗号化
    2. 成功:DBへの格納
  2. Lambda
    1. 成功:DBからデータの取得
    2. 失敗:文字列の復号化を行う

失敗した処理の箇所のログを見てみると、以下のようなエラーが。
TypeError: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt

併せてDBから取得した暗号化文字列の方も見てみても、パッと見問題なさそう。(こんな感じになっていた→8e189494ffae.....)

念のため、Flask APIの方の暗号化処理のログと、DBの値も見てみることに。

すると、暗号化処理のログで出力されている暗号化文字列の桁数と、DBの実際に格納されている暗号化文字列の桁数が一致していないことが発覚・・・

詳細な事象としては、以下でした。

  • DBの桁数(50)に対して、暗号化文字列が64文字
  • DBは50桁なので、後ろ14文字が切り落とされる
  • Lambdaで復号化する際に、50文字だから復号化に失敗

なので、DBの桁数を100桁まで拡張して、やり直したところ、無事成功・・・

まとめ

暗号文字列をそのまんまDBに格納するときは、
DBの桁数と暗号化文字列の桁数をしっかりチェックする!

失礼しました。


Viewing all articles
Browse latest Browse all 9138

Trending Articles