> if( *p > 0x7fff) *p -= 0x7fff;

この if 文は決して成立しないのでは？

簡単な難読化であれば、各バイトごとに特定の値と XOR するのがよくある手法です。
難読化するときも元に戻す時も同じロジックでいけます。

ところで、根本的な問題ですが、

> 理由は、ユーザ記述のコメントやユーザ情報を含むためです。

というのは？
それはユーザには見えてもいい、ということになりませんか。
他のユーザに見られたくないのであれば、ユーザごとのフォルダ（マイドキュメントや
AppData）に保存するだけでよいのでは、と思います。

元の情報量が減らない演算で、暗号に使いやすい演算には、

　１．Bitの(N)回転
　２．ある値(M)とのXOR( aetosさん既出)

等があります。両方とも複数回適用できます。
デコードは、エンコード方法の間逆を行うだけです。
もちろん、N、Mをファイルの属性とした場合は、
ファイルの「どこか」に埋め込んで保管しなければなりません。

さて、提示のコードではUnicodeか、ASCII(MBCS)かが、わかりません。
一般に暗号化などの演算を行う場合はどちらかに決め打ちして
コードした方が良いと思います(つまりTCHARを使わない)。
MBCSの場合、奇数Byteの文字列もありえますので、
たぶんchar単位でやった方が良いでしょう。

返信ありがとうございます。
XOR 0xFFFFでビット反転させるようにしました。
ビット演算子使えば簡単なこと忘れていました（＾＾；

//書き込み
if( !ar.IsLoading() ){
TCHAR* p = strBuf.GetBuffer();
while( *p != NULL ) {
*p ^= 0xffff;
p++;
}
ar << strBuf;
}
//読み込み
else {
ar >> strBuf;
TCHAR* p = strBuf.GetBuffer();
while( *p != NULL ) {
*p ^= 0xffff;
p++;
}
}

>>aetosさん
社内で使用する単純なTOOLのため、exeファイルと同じ階層にLOGファイルとして出力す
る程度です。

ちょっと気になるのが、
元の文字列に対して、直接 *p ^= 0xffff; してるところ。

演算結果が NULL文字になったりしないか心配です。
NULL文字になれば、ar << strBuf; でそこが文字列終端とみなされます。

なお、シフトJISでは、漢字の１バイト目に0xFFを認めているようです。
(仕様的にであって、実際には現状使われていない模様)

bunさんの指摘の通り、テキストファイルの場合は
コントロール文字(特に0x00とEOF)にならないようにしなければならないので、
簡単にやるにはファイルをバイナリで作らなければなりませんね。