不好意思，这里主要是讨论流密码加密，一般情况是不分组的，明文流被密钥流加密成密文流。但是怕穷举攻击，攻击时可通过上下文联系读懂解密后的文件而判定其是明文，从而破解完成。细分则是将明文分成若干小份，对每一小份进行流密码加密，如果对其进行分别的穷举攻击，如果穷举成功，得到的也只是一个一个的小段的内容，如果段落足够小，就不能读懂其含义，例如一个字节你能知道其含义吗？这里已经无法用上下文联系来判断含义了，所以就无法进行穷举攻击。上面的看官也说了穷举攻击怕密码很长，细分到字节的必然结果是使用和明文一样长的密码，这样长的密码穷举攻击当然无法招架了。
细分的直接结果是运算量大速度较慢，楼上的看官又说了越细分越不安全，我这里有细分到一个字节的加密程序实例，感兴趣可以索要资料拿去破解，你能破解吗？sjsjsjd@163.com
由于是流密码加密，处理的最小单位是字节，尽管分了多段也没有分组密码中配置分组的问题。

sjdkx 不好意思，这里主要是讨论流密码加密，一般情况是不分组的，明文流被密钥流加密成密文流。但是怕穷举攻击，攻击时可通过上下文联系读懂解密后的文件而判定其是明文，从而破解完成。细分则是将明文分成若干小份，对每 ...

上次贴出来的源码，怎么被破解的不记得了？
消停了十天半个月，是不是有人撑腰了，就又敢跳出来了？

流密码加密本质还是数据加密，流不过是一种数据处理方式而已。你连什么是流都没搞懂？
你细分加密，有些段不加密有些段加密，你在解密时怎么区分？是不是要加标识？
你以为细分了，别人解密时搞不懂含义就不能穷举？别人一样可以全文解密然后判断而不是局部解密判断。

@wsy   你们破解了什么？那人逆出个非驴非马的东西能不能运行还两说，拿个老程序往那一放说是破解，实际什么也没成。
@tDasm   所有段都要加密的，你还是没有看懂细分的意义。

sjdkx @wsy   你们破解了什么？那人逆出个非驴非马的东西能不能运行还两说，拿个老程序往那一放说是破解，实际什么也没成。 @tDasm   所有段都要加密的，你还是没有看懂细分的意义。

细分加密顾名思义，它不是通篇加密。
这是谁说的?
细分能解决问题，为什么加密方法不断推陈出新?加密位数越来越大?
分组不能解决任何问题。分得越细，只是增加加密运算的重复次数而已。

sjdkx @wsy 你们破解了什么？那人逆出个非驴非马的东西能不能运行还两说，拿个老程序往那一放说是破解，实际什么也没成。 @tDasm 所有段都要加密的，你还是没有看懂细分的意义。

这个也不懂，那个也不懂，就你懂

自己贴出了源码，给你找出了至少四个密码漏洞，不认账了？
是不是所有的漏洞都不重要，都与你无关啊

没关系，你有坛主、版主撑腰，继续嚣张吧
到底是怎么回事，大家都清楚。看看你的口碑就知道了
坛主、版主，继续封人。
不封，真对不起你们手里的权限

上次贴出来的源码，怎么被破解的不记得了？
消停了十天半个月，是不是有人撑腰了，就又敢跳出来了？

@wsy   你们破解了什么？那人逆出个非驴非马的东西能不能运行还两说，拿个老程序往那一放说是破解，实际什么也没成。

我说的是源码，他说的是逆向，有源码了还需要逆向，牛啊
大家都懂了怎么回事了吧？
这货就听不懂人话，所以，一切都不奇怪

这个版主 看场雪 估计也不太听的懂人话
干些不是人的事也就不奇怪了
一路货色啊

如果这个论坛是收费的，就可以法律解决了
免费的，坛主随便玩，可以不要脸皮的

@mb_humavufz  搞清楚情况在判决，那人做逆时还没贴出源码，所谓的逆只是局部，即便真做出逆和破解有什么关系，贴出的源码确实有许多缺陷，找到缺陷和破解完全不是一回事。
你可以查一查破解了什么，都是嘴仗，我倒是希望能破解的人出现可是还没有见过。

首先这贴的想法时非常naive但是是非常直观的。
其实细想之下现在常用的加密方法是对称加密方法。（非对称加密太慢常常用于签名和密钥分发）
对称加密方法现在通用的做法其实就是作者所谓的细分方法。
这里所谓的细分其实质上就是分组加密方法或流密码。
其实作者细细想一下也不存在所谓的对于整个明文直接打包加密的方法。对于整个明文进行安全加密需要和明文一样长度的密钥，这样就能够实现作者所说的一个字节一个字节的加密，密码学理论中也已经讨论过这个问题称为一次一密系统（one time pad）。另外一个直观的想法即是对明文进行分组，这样就可以使用一个较短的密钥不断变换重用进行安全加密。

结论说来，作者有一点一般性的想法，但是需要调查研究而不是重造名词

谢谢楼上的中肯回答。

我一般只用流密码加密，所谓细分也没什么就是分段加密而已。一般流密码加密确定了随机函数种子后，通过计算生成密钥流，用密钥流对明文流进行加密，生成密文流。

细分是指将明文等分成小段，为每一小段分配一个种子，随机函数生成密钥流对各小段进行加密。当细分到字节时，需要很长的密码我是这样处理的：首先定义和明文一样长字节数的整形数组作为原始数组，使用用户密码的计算值，生成种子对原始数组进行随机排序，得到的新数组是种子数组，依次每个种子对应明文一个字节，依次加密即可。

tDasm 看场雪 如果分组本身不长（分组可以被穷举）且分组中存在着明显的不均衡（有的分组值出现概率大或小），那就容易被攻击 相反 如果分组长（例如：1024bit） ...

好的，我举个例子

假如要对一个.c文件加密，可以把明文进行分组
我们来看3个例子：以16byte为单位进行分组，或者以1byte为单位，或者以1bit为单位

当以16byte为单位时，攻击者已知密文，包括第一个分组的密文，想猜测第一个分组的密钥
我们知道这16byte极有可能是这样几种模式：
"#include"+????????
"#ifdef"+??????????
"/*"+??????????????
所以攻击者可以穷举所有可能的密钥 对密文解密，看看哪些key能够解出上述模式
如果找到了，那就是第一个分组的key的候选
如果加密算法的工作模式选择得不够谨慎，那么很有可能 利用第一个分组的候选key就能极大加速对后续分组的密文的破解
在这个例子中，这16byte的明文 理论上有2^128种可能的分组值，但是由于其中有少数分组的概率远大于其它可能性，所以造成了这种攻击的可能

再看1byte分组的例子
攻击者还是已知第一个分组的密文，试图破解第一个分组的key
方法与上述类似，不再赘述
但是在1byte模式下，拥有高概率的分组值 所占的比例 明显小于16byte的情形。攻击难度加大

再看1bit的情况
这种概率分布不均衡的状态被进一步弱化（尽管还是有不均衡）。攻击难度更大

在密码算法的设计中，设计者不能假设明文中的各种分组值的概率是均衡的。而为了削弱上述攻击所造成的的威胁，必须要让分组更大。
如果分组一定要很小（例如 电报加密、信道加密、浏览器加密等）则只好打破上述攻击的一个条件：“加密算法的工作模式选择得不够谨慎”。要谨慎选择加密算法的工作模式！
希望达到的效果是：
1）每个分组都是用不相关的key，例如 38楼提到的one time pad
2）明文集合中的每个可能的明文的出现概率都是均衡的（我再次强调，这一点是不容易做到的。如果有人对此还有疑问，我们还可以展开讨论）

最后，欢迎讨论技术。把事情说清楚就好，不必过多对他人进行负面评价。
贬低他人，除了能让自己感觉出了口气以外，并不有助于提高自己在圈内的身价，反而可能有损于自身的技术形象。

看场雪 好的，我举个例子 假如要对一个.c文件加密，可以把明文进行分组 我们来看3个例子：以16byte为单位进行分组，或者以1byte为单位，或者以1bit为单位 当以16byte为单位时，攻 ...

答非所问，你哪里解释了你创造的新名词?希望提供出处。
分组用不同的key加密，这有什么新意，任何人都知道1十1=2的道理。
按你这个逻辑，分组用不同的加密方法强度比你用不同key更高(例如一组用AES，另一组用RSA等)，谁不知道呢?傻子都知道！更有甚者，同一组都可以用几种组合加密。关键是这不是什么创新！！这就好比钢板可以承受2000kg的力，已知可攻击力最大只有1500kg，但是你非要再加一层钢板，有必要吗？

就这水平。。。丢脸
引用“wangring”的话
结论说来，作者有一点一般性的想法

@看场雪  文件的单元是字节，细分到字节，已经很小了，有必要到bit吗？细分到字节时密钥长度，已经和明文一样长了，再细分将超过明文长度。这都无所谓关键是安全性和实用性，能用及真理。例如有人证明一次一密就能安全加密，用一次两密也不是罪过，也不一定慢多少，总之想怎么做只要能安全加密都没错的，追求最佳当然也是不错的，这都是个人爱好。

下面举个例子，来分析你那个所谓细分到底起什么作用。

假设某加密算法是可以穷举的，现有一段明文，按正常分组只需一组就能完成加密（所谓正常分组就是按加密位数自动分组）。那么穷举只需一次就可以了，假设穷举一次的时间是1天，也就是24小时。

现在我们来进行细分，把本来一组的数据细分为10组，那么每组的位数只有原来一组的十分之一。

接下来分二种情况进行加密：

1、每组用同一个key进行加密，显然因为key相同，我们只需一次穷举就可以了，穷举时间理论上是1天，但是实际是不是需要1天，我将在第2点中进行分析。

2、每组用不同key加密，因为key不同，显然必须要10次穷举才能完成，但是穷举时间是不是需要10天呢？这是问题的关键，如果的确需要10天，那么细分的目的就达到了。但是实际是不是呢？我们来进一步分析之。

细分为10组，加密时因位数不足会自动进行填充数据，我们来看看加密前的数据结构：十分之一位的明文+十分之9的填充数据。换句话说，就是1/10的数据是变动的，9/10的数据是不变的。也就是说加密前的数据动态范围显著变小了。如果针对这一特点进行穷举，那么一次的穷举时间会明显减少，理想状态应该只有原来的十分之一的时间，当然实际会有所增加。那么10次穷举的总时间是：10乘以1/10，还是1天。当然这是理想状态。实际会有所增加，但是肯定的是不需要10天。

综上所述，我的结论就是，细分不能解决任何问题，只是增加加密次数，和穷举次数，但是不能成倍增加穷举时间。

欢迎批评指正。

tDasm 下面举个例子，来分析你那个所谓细分到底起什么作用。假设某加密算法是可以穷举的，现有一段明文，按正常分组只需一组就能完成加密（所谓正常分组就是按加密位数自动分组）。那么穷举只需一次就可以了，假设穷举一次 ...

首先，欣赏你这次发言的务实态度，好！

按照你的例子，把大分组切成小分组，只是
1）在小分组里面填充攻击者已知的内容
2）每个小分组使用的key是相同的
这样的切分，当然是对安全没有贡献的

我并不认为，单纯的分组动作 就能提高安全性
相反，实际上现代分组密码算法的分组长度是越来越长了。其目的就是为了让相邻的更多的明文在被加密的时候能产生相互扩散混淆作用

共识讲了，再来谈分歧
为什么有的地方还在用流密码呢？（流密码可以被认为是一类小分组的密码算法，例如 1B的RC4，1bit的A5，ZUC等）其必然有存在的价值，在此不赘述了

显然流密码不能使得多个相邻明文产生扩散混淆作用，是一个坏消息。那么它们该如何保障安全性的？
有几种办法：
1）在密钥上做文章：足够长的密钥，一次一密。至于这密钥是哪来的？我们丢给其它算法去解决吧
2）在明文上做文章：消除明文值之间的不均衡，使得对手即使猜对了密钥也不知道他猜对了
3）在算法上做文章：通过扩展算法空间，使得对手不能猜测新分组所使用的算法
以上3种手法，在密码学中都有理论描述且都有实践尝试，在此不再赘述

最后，我并未创造什么新概念。谢谢参与讨论。

看场雪 首先，欣赏你这次发言的务实态度，好！ 按照你的例子，把大分组切成小分组，只是 1）在小分组里面填充攻击者已知的内容 2）每个小分组使用的key是相同的 这样的切分，当然是对安全没有贡献的 ...

你说的三种手法，我只赞同1和3，第二点不敢苟同。
从局部看的确是猜对了密钥也不知道，但是从全局看呢?未必。

@看场雪  @tDasm  你们两位都认为细分对提高安全性没有帮助。
请问：例如对一首唐诗加密，现在细分到了字节，依旧使用穷举攻击，现在即使穷举对了一个字节属于哪个汉子都不清楚，您们是如何判断阶段性成功的？能使用上下文关联吗？

sjdkx @看场雪 @tDasm 你们两位都认为细分对提高安全性没有帮助。 请问：例如对一首唐诗加密，现在细分到了字节，依旧使用穷举攻击，现在即使穷举对了一个字节属于哪个汉子都不清楚，您们是如何判断阶段性 ...

作为正常用户，可以把一句诗（我们假定是7个汉字），从1个大分组拆成了14个小分组（每个汉字2个字节），看起来 这样每个小分组的‘粗糙度’（这是一个在密码分析中的专业名词）会比1个（明明知道是汉语一句诗的）大分组 要好一些
但攻击者不会约束自己的攻击手法，会把这14个字节联合起来分析。其分析难度与大分组是一样的。
所以，单纯的细化分组并不能对安全提供贡献。

要想细化分组之后能够有所安全收益，还是要对细化后的分组的各种可能数值的出现概率（以及组合的概率）进行专门的设计优化。

tDasm 你说的三种手法，我只赞同1和3，第二点不敢苟同。 从局部看的确是猜对了密钥也不知道，但是从全局看呢?未必。

你的这个说法，我完全赞同。
我只是指明了，有这3种努力的方向，但我没说这些方向都一定能成功，也没说一定能在工程上可行。
（其实这些方向也不是我指明的。这些都是密码界的基本共识）

我前面已经反复说过：“这一点是不容易做到的。”

@看场雪  没人约束你的攻击手法，像你说的假定是 7个汉字吧，这14个相关的字节，假定你穷举正确也要在千万个字节中寻找可能的字节，这可不像不细分的情况，结果就在那里你只要去发现就行了。现在你需要首先找到可能构成汉字的字节，然后去拼凑汉字，并找出上下文联系，你说难度是一样的没有说服力！
另外提醒，细分是将明文细分，每一部分都是独立加密的，有多少份就需要多少种子，由于这些种子是受你控制的所以得以连续处理，所以看上去像是一下子处理的，实际是分段处理的。