我的算法的加密分析

Question

import string,random,platform,os,sys
def rPass():
    sent =  os.urandom(random.randrange(900,7899))
    print sent,"\n"
    intsent=0
    for i in sent:
        intsent += ord(i)
    print intsent
    intset=0
rPass()

我需要帮助确定该算法的字节码部分的总可能输出.不要担心for循环和用于下线的ord东西. - 新手加密的家伙.

Answer 1

我不会担心循环和ord东西,所以让我们把它扔掉然后看看其余部分.

此外,我不明白"我需要帮助确定此算法的unicode部分的总输出可能",因为算法中没有Unicode部分,或者实际上代码中的任何地方都没有任何Unicode.但我可以帮你弄清楚整个事物的总输出量.我们将逐步简化它.

第一:

li=[]
for a in range(900,7899):
    li.append(a)

这完全等同于:

li = range(900, 7899)

与此同时:

li[random.randint(0,7000)]

因为li恰好是6999个元素长,这与它完全相同random.choice(li).

并且,将最后两个放在一起,这意味着它相当于:

random.choice(range(900,7899))

......相当于:

random.randrange(900,7899)

但等等,那怎么样random.shuffle(li, random.random)？好吧(忽略random.random已经是第二个参数的默认值的事实),选择已经是随机但不加密 - 所以,添加另一个shuffle并不会改变它.如果有人试图在数学上预测您的RNG,那么使用相同的RNG添加一个简单的shuffle将不会使其更难预测(同时根据结果添加更多的工作可能会使定时攻击更容易).

实际上,即使您使用的是子集li而不是整个事物,也无法使您的代码更难以预测.你有一个较小的价值范围来蛮力通过,没有任何好处.

所以,你的整个事情减少到这个:

sent = os.urandom(random.randrange(900, 7899))

可能的输出是:长度在900到7899字节之间的任何字节串.

长度是随机的,并且大致均匀分布,但在加密不可预测的意义上它不是随机的.幸运的是,这并不重要,因为可能是攻击者可以看到他正在处理的字节数而不是必须预测它.

内容是随机的,均匀分布和加密不可预测,至少在您的系统范围内urandom.

这就是它的全部内容.

但是,你使阅读,编写,维护和思考更加困难的事实会给你一个主要的劣势,你的攻击者没有任何补偿性的劣势.

所以,只需使用单线.

我想在你的后续问题中,你要问的是900-7898字节的随机数据有多少可能的值.

那么,900字节有多少个值？256**900.901有多少？256**901.所以,答案是:

sum(256**i for i in range(900, 7899))

......这是关于2**63184,或10**19020.

所以,63184位的安全声音令人印象深刻,对吗？可能不是.如果您的算法没有任何缺陷,那么100位比您需要的更多.如果你的算法存在缺陷(当然它是因为它们都是),盲目地抛出数千个位也无济于事.

另外,请记住,加密的重点在于2**N,对于某些大N 来说,您希望破解比合法解密慢.因此,使合法解密慢得多使您的方案更糟糕.这就是每个真实工作加密方案使用几百位密钥,盐等的原因(是的,公钥加密使用几千位的密钥,但这是因为它的密钥不是随机分布的.一般来说,你用这些密钥做的就是加密几百位的随机生成的会话/文档密钥.)

最后一件事:我知道你说要忽略它ord,但......

首先,你可以把整个部分写成intsent=sum(bytearray(sent)).

但是,更重要的是,如果您正在使用此缓冲区进行总结,那么您将使用大量熵来生成具有更少熵的单个数字.(一旦你想到它,这应该是显而易见的.如果你有两个单独的字节,有65536种可能性;如果你把它们加在一起,只有512.)

此外,通过生成几千个单字节随机数并将它们相加,这基本上是普通或高斯分布的非常接近的近似值.(如果你是一个D&D播放器,想想3D6如何比3和18更多地给出10和11 ......以及对于3D6而言对于2D6更为正确......然后考虑6000D6.)但是,通过制作字节数在900到7899的范围内,你将它平坦化为从700*127.5到7899*127.5的均匀分布.无论如何,如果你能描述你想要获得的分布,你可以直接生成它,而不会浪费所有这些随机熵和计算.

值得注意的是,很少有加密应用程序可以利用这么多的熵.甚至像生成SSL证书这样的事情也使用128-1024位,而不是64K位.

你说:

试图杀死密码.

如果您正在尝试加密密码,以便它可以存储在磁盘上或通过网络发送,这几乎总是错误的方法.您想使用某种零知识证明存储密码的哈希值,或使用质询 - 响应而不是发送数据等.如果您想构建"保持登录功能",请通过实际保留用户登录(创建并存储会话身份验证令牌,而不是存储密码).有关基础知识,请参阅Wikipedia文章密码.

有时,您确实需要加密和存储密码.例如,也许你正在构建一个"密码锁"程序,供用户存储一堆密码.或者是客户端到设计糟糕的服务器(或70年代设计的协议).管他呢.如果你需要这样做,你需要一个带有相对较小密钥的加密层(请记住,典型的密码本身只有大约256位长,并且实际信息少于64位,因此使用绝对没有任何好处只要他们一千倍的关键).使其更安全的唯一方法是使用更好的算法 - 但实际上,加密算法几乎永远不会是最好的攻击面(除非你试图自己设计一个); 把你的努力投入到基础设施最薄弱的地方,而不是最强大的地区.

你问:

urandom的输出是否依赖于它正在使用的汇编程序？

嗯...没有它正在使用的汇编程序,我无法想到你可能指的任何其他任何意义.

所有urandom依赖的是您的操作系统的熵池和PRNG.正如文档所说,urandom只是读取/dev/urandom(Unix)或调用CryptGenRandom(Windows).

如果您想确切了解系统的工作原理,man urandom或CryptGenRandom在MSDN中查找.但是所有主要操作系统都可以生成足够的熵并将其混合得足够好,基本上你根本不用担心这个问题.在封面下,它们都有效地拥有一些熵,一些加密安全的PRNG来"拉伸"该池,以及一些内核设备(linux,Windows)或用户空间守护程序(OS X),它们可以收集任何熵.从用户行为等不可预测的事情中获取,将其混合到池中.

那么,那依赖于什么？假设您没有任何浪费大量熵的应用程序,并且您的计算机没有受到损害,并且您的操作系统没有严重的安全漏洞......它基本上不依赖于任何东西.或者,换句话说,它取决于这三个假设.

引用linux手册页,/dev/urandom对于"除了长期存在的GPG/SSL/SSH密钥之外的所有东西"都足够了.(在许多系统上,如果有人试图运行一个程序,就像你的代码一样,读取数千个字节urandom,或者试图杀死熵播种守护进程,或者其他任何东西,它都会被记录下来,并希望用户/ sysadmin可以处理它.)

hmmmm python经历了自己的翻译,所以我不确定它是如何发挥作用的

它没有.显然调用urandom(8)会在系统调用之前和之后执行一系列额外的操作来读取8个字节而/dev/urandom不是你所做的,例如,一个C问题...但实际的系统调用是相同的.因此urandom设备甚至无法区分两者之间的差异.

但我只想问urandom是否会在不同的架构上产生不同的结果.

嗯,是的,很明显.例如,Linux和OS X使用完全不同的CSPRNG和不同的累积熵的方式.但重点是它应该是不同的,即使在同一台机器上,或在同一台机器上的不同时间.只要它在每个平台上产生"足够好"的结果,那就重要了.

例如,processor\assembler\interpreter会导致特定于所述体系结构的指纹,这在合理范围内是可随机预测的吗？

如上所述,解释器最终使得与编译代码相同的系统调用.

至于汇编程序......可能在任何地方都没有任何汇编程序.Python解释器的相关部分,随机设备,熵收集服务或驱动程序等很可能用C语言编写.即使它们是在汇编中手工编码,汇编中的整个编码点就是你几乎可以直接控制生成的机器代码,因此不同的汇编程序不会有任何区别.

处理器可能在某种意义上留下"指纹".例如,我敢打赌,如果您了解RNG算法并直接控制其状态,您可以根据时序编写可以区分x86与x86_64,甚至可能是i7与另一代相比的代码.但是我不确定那会对你有什么好处.该算法仍将从相同的状态生成相同的结果.并且针对RNG使用的实际攻击是关于攻击算法的熵累加器和/或熵估计器.

无论如何,我愿意投入大量资金,而这些资金urandom比你自己提出的任何东西更安全.如果你需要更好的东西(而你没有),实施 - 或者更好的是,找到经过充分测试的Fortuna或BBS实施,或购买硬件熵产生设备.