最近搬砖学到一种用按位 xor 实现加密一小段字符串的操作,具体模式大概是这样的:

加密:密文 = 原文 xor 密钥
解密:原文 = 密文 xor 密钥

在想这种模式的安全性如何,想起原来上安全学课的时候有涉及相关内容(当时没认真听、都忘了= =,对不起@Bintou 老师),趁周末看一看写一写。

大致总结:

  1. C语言 int/short/char 等类型下的加减乘除运算,实质是类似钟表的模型,构成一种有限位数下的 mod 运算。各类密码算法也是利用了同余和 mod 运算的数学性质,把抽象代数相关的理论落地,去做各种各样的事情。
  2. 开头说的那种 xor 的机制的学名叫「Vernam密码」,只要密钥比原文长,且这个密钥本身无任何规律的话,用这种方式加密,在只有密文的情况下是不可能破解出原文的。

大部分场景无法达到这种理想情况,主要通过两种路径去增大统计猜测破解的难度:
一种是「流密码」:基于有限长度的密钥,去生成理论上无限长度、且无法找出规律的密钥流,最后用 Vernam 的 xor 姿势实现最终的加密解密过程。

另一种是「Feistel 密码结构」:除了常规的代替和置换手段,还会利用混淆和扩散等姿势,把输入分成特定长度的组,再分别加密解密;

另外,还涉及到不同使用场景的工作模式(其中也用到很多类似 Vernam xor 运算)。

具体的数学和算法有点难(感觉只有专职搞密码学的大佬才有空研究),有机会再搞些题目训练训练= =

参考:

抛砖引玉,欢迎密码佬们分享相关的入门话题,即使是日常搬砖写业务,也蛮实用的~

XOR加密不仅仅局限于小段字符串,理论上可以是"很长“的任意二进制比特串,学名是:流密码。

    Bintou 嗯,感觉密码学着力的地方是原始的二进制比特,字符串可能更多关注的是从人类的视角去解读这些比特吧。

    我这里提到的这种场景(原文的二进制比特串很短,可以保证密钥比原文长)感觉直接用 XOR 还蛮适合的。

    这么看「流密码」解决的是如何产生一个比原文更长的密钥用于 XOR 的问题🤔

    Vernam密码(或称One-time pad),是满足perfect secrecy(完美安全)的加密方式。

    Shannon对perfect secrecy的定义如下:

    For every probability destribution over MM and KK , every plain-text m0,m1Mm_0,m_1 \in M and every cipher text cCc \in C , the following holds:
    Pr[C=cM=m0]=Pr[C=cM=m1]Pr[C=c|M=m_0]=Pr[C=c|M=m_1]

    这个定义讲的是:从攻击者的角度来看,给定明文空间中的任意两个明文m0,m1m_0,m_1,和密文空间中的任意一个密文ccccm0m_0加密而来的概率,和ccm1m_1加密而来的概率是相等的。
    简单来说,就是攻击者如果截获了一个密文c,这个密文所对应的明文可能是明文空间中的任意一个明文。所以攻击者单凭密文c是绝对无法破解出对应的明文,因为他们的概率是相等的。(任一密文,都可能由任一明文,通过任一密钥加密而得到的)。所以One-time pad是绝对安全,无法被攻破的!

    举个例子,如果将一篇文章编码成一个长度为n的比特串,与一个作为密钥的长度为n的比特串异或进行加密,得到了一个长度为n的比特串密文。假设一个拥有无限算力(computational unbounded)的攻击者,想通过穷举密钥并与密文比特串异或进行破解,他能得到的是所有可以用n比特串所表示的文章,但他不知道究竟是哪篇文章才是被加密了的那篇文章!

    所以任何满足perfect secrecy的加密系统是无法被破解的。

    但任何满足perfect secrecy的加密系统都受制于以下两个前提:
    1密钥空间的大小要至少等于明文空间的大小(密钥长度至少等于明文长度)。
    2.一个密钥只能用于一次加密。

    只要这两个前提中有一个不被满足,那么这个加密系统是不满足perfect secrecy的!(证明略,可以参考Inroduction to modern cryptography)

    所以这导致了满足perfect secrecy的加密系统是impractical的。(密钥太长,而且只能用一次)

      流密码考虑的问题是:我能不能用一个较短的密钥k,生成一个和明文等长的“随机”比特串,再与明文进行异或加密,达到近似于One-time pad的完美安全性。所以流密码其实是Vernam密码在现实中的实现,而其核心就是——伪随机数生成器(pseudorandom generator)。

      完了,我们就经常这么干。效率优先的情况下安全性已经足够了

      © 2018-2025 0xFFFF