用绘制笔划解密数据的算法

Sen*_*ful 13 encryption algorithm drawing

假设我在iPhone上有一个加密文件,每次我要解密它时,我想"画"一个解密符号,而不是用键盘输入.

如果您要求用户在每次需要时绘制符号来解密文件(例如,每次他们启动您的应用程序时),他们可能更喜欢它必须在小键盘上键入20个字符左右的密码,并且他们仍然会得到一个20字符密码给他们的安全性(取决于他们绘制的形状/符号有多复杂).

他们绘制的符号很可能是一个笔划(例如,一旦你抬起手指就会结束),但可能非常复杂,以至于其他人很难重复它,即使他们确实看到你画了它.比如每个人的签名是如何独特且难以复制的.实际上,如果它必须防止被复制,这可能会使它过于复杂,所以现在可以忽略它,我们可以假设其他人不会看到符号,因此它是否可以重复无关紧要他们与否.

我想真正的问题是你如何将相同(合理)的笔划一致地转换为相同的密钥(例如哈希值).在算法中显然应该有一些宽恕的门槛,因为用户不能期望完全重复100%的笔画.

使用符号作为解密方法会为此问题添加一个完整的其他维度.您永远不希望以未加密的形式将生成的哈希值存储在任何位置,因此有人可能能够访问硬盘驱动器的该部分并获取解密密钥,而无需完成整个绘图过程并手动解密文件.您也很可能不想存储有关如何绘制形状的任何信息.

用户可能用作其解密符号的笔划的一个很好的例子是"&"符号.想象一下,用户每次需要解密文件时都会在iPhone上绘制此符号.每次绘制时,符号的大小可能不同.而且,符号的旋转可以根据用户如何握住他们的设备而不同.理想情况下,在两种情况下,因为绘制符号,相对于用户笔划,相同,它应该能够生成相同的哈希值,从而解密文件.

我认为形状或字符识别之类的东西是类似的算法.用户绘制某些东西(合理地表示形状)然后将其固定为正确的形状,每次绘制时都具有相同的散列值.但是,对于像这样的东西,你很可能需要一个可以绘制的形状数据库,如果你选择像字母表中所有字母的东西,你只能得到26个字母.假设用户只需要绘制一个符号来解密文件,那么你就有了一个极不安全的密码,只有26种可能性.

我想到的另一件事是你可以分解绘制成小段的符号,然后对它们进行符号识别.因此,假设您在数据库中有4个符号:垂直线,水平线和两个方向的对角线.现在,当用户绘制时,每个段被识别为其中之一,然后它们被组合以形成一些散列值.因此,假设用户选择小写字母"r"作为其解密符号.因此,他们首先绘制一条垂直线,然后是垂直线,然后是对角线和右边.这种方法的一个问题是你怎么知道何时将笔划分成单个部分?您可能还需要考虑每个单独段的粗略长度(例如,以40像素为增量).这样,如果有人画了一个变形的"r",其中驼峰出现在底部附近,它不会被识别为相同的符号,因此不会解密文件.

第三种方法可能是将屏幕划分为一个网格(不确定哪个尺寸)并简单地查看绘制笔划的单元格,并以某种方式使用此数据生成字符串.

关于如何实现这一点的任何其他想法?你听说过这样的事吗?是否存在任何阻碍此类系统工作的根本缺陷?

谢谢

Acc*_*dae 2

使用可能存在小错误的密钥材料加密数据的问题已经得到了相当广泛的研究。特别是,有许多使用生物识别数据(例如指纹或视网膜扫描)作为密钥来保护数据的建议。典型的方法是使用适当的纠错码,获取原始密钥材料 K,计算其校正子并仅存储校正子。一旦您第二次读取密钥材料 K',如果 K 和 K' 足够接近,则可以使用该综合症从 K' 恢复 K(其中“足够接近”当然取决于纠错方案。)

为了帮助您入门,这里有一篇提出模糊金库方案的论文。这是使用“模糊”密钥的加密方案的一般建议。当然,您仍然需要研究如何从足够稳定的图形中提取特征以使用这种纠错方案。您还必须检查可以从这些绘图中提取多少熵。尽管密码在熵方面很糟糕,但它们可能仍然难以被击败。