ROT13とBase64の違い｜暗号とエンコードの境界

ROT13とは、アルファベットを13文字ずらす単換字式暗号で、1980年代初頭のUsenetのnet.jokesでネタバレ隠しに使われた、固定鍵13の自己逆操作です。
Base64とは、3バイトのバイナリを64種類の印字可能文字で表すエンコード規格で、SMTPやHTTPヘッダのようなASCII制約のある経路でデータを運ぶために生まれました。
セキュリティ企業で暗号実装を検証していた頃、ログに残ったBase64文字列を暗号化済みだと信じていた現場で、デコードした瞬間に認証情報が平文で現れたことが何度もあります。
そこで見えるのは、エンコードは運搬、暗号化は機密性、ハッシュは完全性検証という役割の違いであり、ROT13とBase64はどちらも秘密の鍵なしに元へ戻るため、防御には使えないという事実です。

結論：ROT13は『中身が見える暗号』、Base64は『暗号ですらない』

ROT13は単換字式暗号、Base64はエンコードです。
この違いを見落とすと、「暗号化したのだから安全だ」という誤解に一直線でつながります。
両者に共通するのは、秘密の鍵がなくても変換手順さえ知っていれば誰でも元に戻せることにあります。

30秒で分かる早見表：可逆性・鍵・目的の3軸

この表で押さえるべきなのは、ROT13もBase64も「元に戻せる」点では似ていても、守っているものがまったく違うことです。
ROT13は26文字のアルファベットを13文字ずらす単換字式暗号で、13は誰でも知っている固定値ですから、秘匿力はありません。
Base64はそもそも暗号ではなく、バイナリを64種類の印字可能文字で表す表現変換です。
目的が違う以上、同じ机に並べて比べるには、可逆性・鍵の有無・目的の3軸がいちばん分かりやすいのです。

なぜ両方とも『パスワード代わり』にしてはいけないのか

筆者はコードレビューで「Base64=暗号化」という誤解に出会うたび、その場でブラウザの開発者ツールを開き、atob() と打ち込んで原文を一瞬で復元してみせます。
目の前で秘密が消える体験ほど、エンコードと暗号化の差を腹落ちさせるものはありません。
CTFの問題作成でも同じで、末尾の = を見て「あ、Base64だ」と気づく参加者の表情は印象的です。
ROT13も Base64 も、第三者から見て残るのは文字の見た目だけで、秘密そのものはどこにも残っていません。

だから、これらをパスワード代わりに使うのは危険です。
ROT13は13ずらすだけで読め、Base64は反射的にデコードされます。
『隠したつもり』ほど見つかりやすいものはなく、機密性を期待した瞬間に設計が破綻します。
暗号化が必要な場面では、鍵を持つ人だけが戻せる仕組みを使うべきで、ROT13やBase64はその役目を担えません。

そもそも『暗号化』と『エンコード』は何が違うのか

三分法で見ると整理しやすくなります。
エンコードは運搬と互換性のための変換で、可逆であり、鍵はいりません。
暗号化は機密性のための変換で、可逆ですが鍵が必要です。
ハッシュは完全性確認のための処理で、元には戻せません。
分類を決めるのは処理の見た目ではなく目的です。

ROT13は暗号化の系譜にあるものの、鍵が公知の固定値13なので実質的には難読化にとどまります。
Base64は暗号化の仲間ですらなく、メールやHTTPヘッダのように 7bit ASCII しか通せない経路でバイナリを運ぶための規格です。
Basic認証の Base64 や JWT の base64url を暗号化だと思い込む事故が起きるのは、まさにこの目的の取り違えからです。
まずはエンコード/暗号化/ハッシュの違いを頭に入れ、そのうえで ROT13 と Base64 を見分けていきましょう。

エンコード・暗号化・ハッシュという3つの座標

エンコード、暗号化、ハッシュは、見た目だけならどれも「データを別の形に変える」処理に見えます。
けれど分類を決めるのは処理そのものではなく、何のためにやるかという意図です。
運搬と互換性ならエンコード、機密性なら暗号化、完全性の検証ならハッシュ。
新人に説明するときは、この三分法を先に置くと混乱がすっと減ります。

意図(intent)が分類を決める：運搬か・機密か・検証か

現場で役に立つのは、まず「元に戻せるか」「鍵が要るか」「何のためか」を順に確かめるやり方です。
実際、研修でこの3問を投げると、文字列の扱いはほぼ迷いませんでした。
三つの問いに答えるだけで、エンコードか暗号化かハッシュかが決まるからです。
処理の名前を覚えるより、目的(intent)で見分けるほうが実務では強い。

エンコードは可逆で、鍵も不要です。
情報を落とさずに往復でき、誰でも同じ規則でエンコードもデコードもできます。
目的は安全な運搬と互換性であって、秘匿ではありません。
Base64、URLエンコード、文字コード変換がここに入り、メールやHTTPヘッダのような通り道を通すために使われます。

暗号化は可逆ですが、復号できるのは鍵を持つ者だけです。
安全性の核は鍵にあり、鍵なしで読めないことが機密性を支えます。
AESやRSAはこの座標にありますし、ROT13も系譜としては暗号化側です。
ただし ROT13 は鍵が固定値13で公知なので、秘匿力は失われています。
だから同じ「変換」でも、運搬用のエンコードとは役割がまるで違うのです。

ハッシュは不可逆で、出力は固定長です。
元データに戻す鍵は存在せず、一方向に流すことで完全性を検証します。
MD5やSHAはここに置かれ、パスワード照合や改ざん検知に向いています。
エンコードや暗号化と決定的に違うのは、「元に戻れるか」が前提にないことです。

ROT13とBase64を座標に置く

ROT13は、アルファベットを13文字ずらす単換字式暗号です。
A-Z と a-z だけが対象で、日本語や数字、記号は変わりません。
26文字の半分である13文字をずらすため、2回かけると必ず元に戻る自己逆操作になります。
1980年代初頭の Usenet の net.jokes で、ジョークのオチやネタバレをうっかり読まれないようにする軽い難読化として広まりました。
つまり、暗号化の形を借りていても、実態は「見せ方の工夫」に近いのです。

Base64は暗号ではなく、バイナリを印字可能文字へ写すエンコード規格です。
6bit×4=24bit、つまり3バイトを4文字に置き換える設計なので、データ量は約33%増えます。
末尾の = は端数の埋め合わせで、URLセーフ変種では + を - に、/ を _ に置き換え、= を省くこともあります。
SMTP や HTTP ヘッダのように 7bit ASCII しか通しにくい経路で、安全に運ぶための道具であり、機密性とは無関係です。

この二つを座標に乗せると、違いがはっきりします。
ROT13 は暗号化の軸にありますが、鍵が公知の固定値なので防御としては弱い。
Base64 はエンコードの軸にあり、そもそも「隠す」発想を持ちません。
実務では Basic 認証の Base64 や JWT の base64url を「暗号化」と誤解しがちですが、そこで安全を担うのは別の層です。
ROT13 と Base64 を同列に扱うと、役割を取り違える危険が出ます。

ハッシュとの混同も多い：MD5やSHAは元に戻らない

ハッシュの混同は、Base64 の事故より深刻です。
あるプロジェクトでは、パスワードをハッシュではなく Base64 で保存していたことがありました。
可逆な Base64 を不可逆なハッシュと取り違えた典型例で、DB が漏れれば全パスワードが即復元されます。
ここでは「見た目が変わった」だけでは何の防御にもならない、と痛いほどわかります。

MD5 や SHA は、まさに元に戻らないことを前提に設計されています。
入力が同じなら同じ固定長の値になり、少しでも変われば出力は大きく変わります。
その性質が、パスワード照合や改ざん検知で効くわけです。
暗号化なら鍵を使って戻せますが、ハッシュには戻すという発想自体がありません。
往復できるかどうか、この一点が三分法の最後の決め手です。

ROT13の仕組み：13ずらすだけの自己逆操作

ROT13は、アルファベットを13文字だけ後ろへずらす単換字式暗号です。
AはNに、NはAに、HELLOはURYYBになります。
古代のシーザー暗号を、26文字の英字圏でちょうど半周する13に固定したものだと考えると、動きが一気に見えやすくなるでしょう。

なぜ13なのか：一周して元に戻る対称性

13が選ばれる理由は、英字が26文字でできているからです。
13+13=26で一周し、もう13ずらすと出発点へ戻る。
このためROT13を2回かけると必ず元に戻り、ROT13(ROT13(x))=x が常に成り立ちます。
数学では対合、暗号では自己逆操作と呼ばれる性質です。
紙の上でAからZまでを2段に並べ、上段の文字の真下に13個先を置いて見ると、往復の対称性が直感的につかめます。
筆者がCTFのCrypto問題を解説するとき、真っ先にこの見せ方を使うのは、初学者が「暗号は一度かけたら別物になる」という思い込みをほどきやすいからです。

暗号化＝復号という珍しい性質(自己逆操作)

ROT13の面白さは、暗号化と復号が同じ処理になる点にあります。
専用の復号器を用意する必要はなく、もう一度「13ずらす」だけで読めるようになる。
実装が極端に単純で、手でやっても機械でやっても迷いにくい反面、鍵は固定で公知なので秘匿力はほぼありません。
つまりROT13は「隠す」より「そのまま見せない」ための道具であり、強固な暗号とは別物です。

変換対象もはっきりしています。
ASCIIのA-Zとa-zだけがずれ、ひらがな、カタカナ、漢字、数字、記号はそのまま残ります。
日本語の文章にROT13をかけると、英単語だけが変わって日本語は無傷のままなので、知らないと「効いていない」と誤解しやすい。
メールアドレスをHTMLソースでROT13難読化した実例を確かめたときも、素通りするスパムボットはありましたが、ROT13デコードを試す少し賢いボットもいました。
気休め程度には効く、しかし本気の相手には無力、という現実です。

ネタバレ隠しという正しい使い道：ROT13が生まれた理由

ROT13は1980年代初頭のUsenet、特にnet.jokesで育った合意の道具です。
不快なジョークやネタバレを、読みたい人だけが自発的に解読するための薄いベールとして使われました。
雑誌がクイズの答えを上下逆さまに印刷して、見たければ自分でひっくり返すのと同じ発想です。
目的は秘匿ではなく、うっかり目に入るのを防ぐことにありました。
だからこそROT13は、暗号学の本格派というより、ネット文化が生んだ気軽な礼儀作法として記憶されているのです。

Base64の仕組み：3バイトを4文字に変換する規格

Base64は、64種類の印字可能文字でバイナリを表すエンコード規格です。
標準の文字集合はA-Z・a-z・0-9の62種に+と/を足した64種類で、各文字が0〜63の数値に対応します。
3バイトを24bitとして6bitずつ4分割し、4文字へ写し替える設計なので、データは約33%増えますが、ASCIIしか安全に通せない経路でも壊れにくく運べます。

なぜ3バイト→4文字なのか：6bitと8bitの最小公倍数

ここでの核は、1文字=6bit、1バイト=8bitという不揃いな単位を、24bitでそろえている点です。
6と8の最小公倍数は24なので、3バイト=24bitがちょうど4つの6bit群に分かれます。
この一致があるから、端数を無理に削らず、過不足なく64文字テーブルへ置き換えられるのです。

実装の流れも単純です。
3バイトをビット列として並べ、6bitずつ4つに切り分け、その各値を0〜63の索引として文字表から引きます。
画像データでも実行ファイルでも同じで、内容は変えず表現だけをASCII寄りに変えるのがBase64の役割です。
筆者が暗号実装の検証で、データURIに埋め込まれた巨大なBase64文字列を初めて見たとき、画像がただの文字列としてHTMLに溶け込んでいるのに驚きました。
デコードしてPNGヘッダが現れた瞬間、これは保存でも圧縮でもなく、あくまで運搬手段なのだと腑に落ちました。

この仕組みの代償が、約33%の膨張です。
3バイトが4文字になる以上、4÷3≒1.33倍になるのは避けられません。
ある障害調査では、この3割増えたBase64ペイロードがヘッダのサイズ上限を超え、リクエストが弾かれていました。
数字を頭で知るだけでは足りず、実際の上限値に触れたときに初めて「増えるエンコード」の意味が見えてきます。

末尾の『=』の正体：パディングの読み方

末尾の『=』は、元データが3バイト単位にきれいに割り切れなかったときの端数を埋める印です。
残りが1バイトなら『=』が2つ、2バイトなら1つ付きます。
これをパディングと呼び、最後の塊が24bitに満たないことを示しています。

つまり『=』は、Base64の見分けやすい手がかりです。
もっとも、これは絶対条件ではなく、base64urlでは省略されることがあります。
符号そのものより、末尾に端数処理があるという発想を押さえておくと、デコード時に余計な混乱を避けやすいでしょう。

そもそも何のために？：7bitチャネルでバイナリを運ぶ

Base64は、メール(SMTP)やHTTPヘッダのように、もともと7bit ASCIIテキストしか安全に通せない経路で、バイナリを壊さず運ぶために生まれました。
画像や実行ファイルをそのまま流すと、途中のゲートウェイや古い処理系で文字化けや欠落が起きます。
そこで、どんなバイナリも一度ASCII文字列へ変換し、通路を確保するわけです。

この目的を知ると、Base64が秘匿のための仕組みではないこともはっきりします。
見た目は暗号文に近くても、中身は隠していません。
むしろ「安全に届ける」ことに全振りした規格であり、運搬に特化した設計だと理解すると、HTMLへの埋め込みやヘッダ送信の意味も読みやすくなります。

Base64の変種：URLセーフ(base64url)とパディング省略

base64urlは、標準Base64の文字体系をURLやファイル名向けに少しだけ変えた変種です。
実務で目にする「+と/が-_に変わっている」「=が無い」文字列の正体はたいていこれで、見た目が違っても仕組みはBase64の延長にあります。
違いは小さいのに、デコーダの選び方を誤ると復号が壊れるため、ここを見分けるだけで運用上の事故はかなり減ります。

+/が-_に変わる理由：URLとファイル名の予約文字回避

base64url（RFC 4648 §5）は、標準Base64の62番目の+を-に、63番目の/を_に置き換えます。
たった2文字の差ですが、これがURLやファイル名への埋め込みを安全にします。
+と/は環境によって予約文字として扱われ、+が空白に化けるような誤動作も起きるため、そのままではトークンやパラメータに載せにくいのです。

実務で見ると、この置換は「読みやすくする工夫」ではなく「壊れないようにする工夫」です。
JWTのように文字列をそのまま経路に流す場面では、記号ひとつの意味が変わるだけで認証や受け渡しが崩れます。
だからこそ、base64urlは危険な2文字だけを無害な-と_に差し替えた設計になっています。

=が消える理由：長さから復元できるパディング

=パディングも、base64urlでは省略されることがよくあります。
URLセーフ用途では=自体が余計な予約文字になりやすく、見た目を短くできる利点もあるため、末尾を削る運用が広く使われます。
ただし、消えたからといって情報が失われるわけではありません。

復号側は文字列長のmod4を見れば、欠けた=の数を機械的に復元できます。
つまり、=が無いBase64を見ても、仕様どおりのbase64urlであれば戸惑う必要はありません。
ここを知らないと「欠損データ」に見えてしまいますが、実際には省略されたパディングを元に戻しているだけです。

JWTで実際に見るbase64url：署名が無ければ中身は丸見え

JWT（JSON Web Token）は、ヘッダ・ペイロード・署名の3部すべてがbase64urlで符号化され、ドットで区切られています。
初めて検証したとき、ペイロードをコピーしてデコードサイトに貼り、ユーザーIDや権限がそのまま読めて肝を冷やしたことがあります。
署名で改ざんは防げても、中身は隠れていない。
あの手触りは、JWTの性質を身体で覚えるには十分でした。

だからJWTに機密情報を平文で入れてはいけません。
安全性の源泉はBase64ではなく第3部の署名にあり、ペイロードは誰でもbase64urlデコードして読めます。
さらに、サーバが標準Base64、クライアントがbase64urlを期待していて、+を含むトークンだけ間欠的に認証エラーになるバグを追ったこともあります。
原因が-/_の文字置換の不一致だと分かるまで半日かかりました。
標準Base64とbase64urlは互換ではない、この一点を外すと現場ではすぐに詰まります。

実務での誤用と正しい使い分け

Base64とROT13は、どちらも「見た目を変える」道具であって、秘匿の仕組みではありません。
現場で事故が起きるのは、この差を取り違えてしまうからです。
認証情報やAPIキーをBase64やROT13で隠したつもりでも、コードやログを見られた時点で復元はすぐに終わります。
用途を正しく切り分けるだけで、無意味な防御をかなり減らせます。

やりがちな事故：Base64で『暗号化したつもり』

最頻出の事故は、Base64で暗号化したつもりになってしまうことです。
Base64は誰でも逆変換できるため、設定ファイルやログに置いたDBパスワードやAPIキーは、紙に書いて机の上に置くのと変わりません。
筆者がセキュリティ診断で設定ファイルを開いたときも、Base64エンコードされたDBパスワードが入っていて、開発者は一応隠したつもりだったのでしょうが、デコード一発で平文が出ました。
隠したつもり、という状態がいちばん危ないのです。

HTTP Basic認証も誤解されやすい例です。
user:pass を : でつないでBase64化し、ヘッダに載せるだけなので、HTTPSが無ければ通信を覗いた相手に中身を復元されます。
つまり、認証情報がBase64だから安全という理解は成り立ちません。
安全性を担うのはBase64ではなくTLS（HTTPS）です。
Basic認証を使うなら、暗号化された通信路の上でだけ扱いましょう。

ROT13・Base64が向いている本来の仕事

ROT13は、ネタバレやオチをそのまま見せたくないときに向いています。
フォーラムで映画・小説・ゲームの結末を隠したり、HTMLソース内のメールアドレスを簡易難読化してスパムボットの目をずらしたりする用途が典型です。
どちらも本気で守るための手段ではなく、うっかり読まれるのを防ぐ程度のカジュアルな隠蔽だと割り切るのが正解です。
実際、レビュー記事の結末をROT13で書いた読者コミュニティを見たことがありますが、読みたい人だけが13ずらして読む運用はかなりうまく機能していました。

Base64の仕事も、秘匿ではなく運搬です。
メールMIME添付でバイナリを文字に変換したり、データURIでHTMLやCSSに画像を埋め込んだり、HTTP Basic認証やJWTで文字専用のチャネルに載せたりします。
要するに、バイト列を壊さず運ぶための互換性の道具です。
安全に隠すためではなく、途中の経路で扱いやすくするために使いましょう。

本当に秘匿したいとき：暗号化(AES)とTLSの出番

本当に機密保持したいなら、AESなどの暗号化を使うべきです。
鍵を持つ者だけが復号できる仕組みなので、Base64やROT13のように見た瞬間に戻せる世界とはまったく違います。
通信路を守るならTLS（HTTPS）、パスワード保存なら暗号化ではなくソルト付きハッシュです。
ここを混同すると、守っているつもりの情報がそのまま読める状態で残ります。

道具を選ぶ基準は単純で、読めても困らないならBase64やROT13、本当に読ませたくないならAESやTLSです。
ハードコードした認証情報をBase64やROT13で包むのは、見た目を変えているだけで防御効果はゼロです。
ROT13とBase64は道具箱の外側に置き、秘匿の設計は別に組み立てましょう。
おすすめです。