可用信息转换方法概述
信息保护可以为不同的目的而实施,因此使用不同的方法。特别地,可能需要向外部观察者完全隐藏信息的本质,或者确保其传输,同时保证其状态不变,但信息本身仍然可用。第一种情况,我们谈论的是加密;第二种情况指的是数字指纹(哈希)。因此,加密和哈希都归结为使用原始数据(如果需要,还包括附加参数)处理成新的表示形式。
加密和哈希都有许多变种。
最普遍的分类将加密分为公钥(非对称)加密和私钥(对称)加密。
非对称方案意味着数据交换的每个参与者都有一对密钥―公钥和私钥。公钥和私钥对是使用特殊算法预先生成的。每个私钥只有其所有者知道。每个人的公钥则为众人所知。在传输加密数据之前,需要以某种方式交换公钥。接下来,数据提供者使用只有他们自己知道的私钥,并结合一个或多个数据接收者的公钥。而接收者则使用他们自己的私钥和发送者的公钥来解密。
对称加密方案对加密和解密使用相同的秘密(私钥)密钥。
MQL5 支持开箱即用的私钥功能(对称加密)。MQL5 内置工具不提供使用非对称加密的电子签名功能。
在加密方法中,还有一类比较特别的是无密钥的原始算法。借助它们,用户可以实现有条件地隐藏信息或转换信息类型。这些包括,例如,ROT13(将其字母数字代码移位 13 来替换字符,特别用于 Windows 注册表)或 Base64(将二进制文件转换为文本,反之亦然,通常用于 Web 项目)。另一个流行的数据转换任务是数据压缩。从某种意义上说,这也可以被认为是加密,因为数据变得对人或应用程序不可读。
哈希方法也有很多。最著名且最简单的可能是 CRC(循环冗余校验)。与允许从加密消息中恢复原始消息的加密不同,哈希仅基于原始信息创建一个指纹(一组特征字节),这样,在后续重新计算时其不变状态(高概率地)保证了原始信息的不变性。当然,这假设信息对相应软件系统的所有参与者/用户都是可用的。无法通过哈希恢复信息。通常,哈希的大小(其中的字节数)对于每种方法都是有限且标准化的,因此对于一个 80 个字符长的字符串和一个 1 MB 的文件,我们将得到相同大小的哈希。大多数用户会发现哈希的一个真正有用的应用是网站和程序对密码进行哈希处理,即后者以哈希形式存储在家中,并在登录时与密码哈希进行验证,而不是原始形式的密码。
应该指出的是,我们在前一章中已经遇到过“哈希”这个术语:我们使用了一个哈希函数来索引经济日历结构。那个简单的哈希保护程度非常弱,特别表现在碰撞(不同数据的结果相同)的概率很高,我们在算法中对此进行了特殊处理。它适用于将数据均匀伪随机分布到有限数量的“桶”中的问题。相比之下,工业标准的哈希专门用于验证信息的完整性,并使用复杂得多的计算方法。但在这种情况下,哈希的长度是几十个字节,而不是一个单独的数字。
MQL 程序可用的信息加密和哈希方法收集在 ENUM_CRYPT_METHOD 枚举中。
常量 |
说明 |
---|---|
CRYPT_BASE64 |
Base64 重编码 |
CRYPT_DES |
使用 56 位(7 字节)密钥的 DES 加密 |
CRYPT_AES128 |
使用 128 位(16 字节)密钥的 AES 加密 |
CRYPT_AES256 |
使用 256 位(32 字节)密钥的 AES 加密 |
CRYPT_HASH_MD5 |
MD5 哈希计算(16 字节) |
CRYPT_HASH_SHA1 |
SHA1 哈希计算(20 字节) |
CRYPT_HASH_SHA256 |
SHA256 哈希计算(32 字节) |
CRYPT_ARCH_ZIP |
使用 "deflate" 方法进行压缩 |
指定的枚举用于两个加密 API 函数中―CryptEncode(加密/哈希)和 CryptDecode(解密)。这些内容将在后续各节中介绍。
AES 和 DES 加密方法除了数据外,还需要加密密钥―一个预定义长度的字节数组(在表格的括号中指出)。如前所述,密钥必须保密,并且只有程序的开发者或信息的所有者知道。加密的密码强度,即攻击者计算机破解密钥的难度,直接取决于密钥的大小:密钥越大,保护越可靠。因此,DES 被认为是过时的,并在金融领域被其改进版本 Triple DES 所取代:它意味着使用三个不同的密钥连续应用 DES 三次,这在 MQL5 中很容易实现。Triple DES 有一个流行的版本,在第二次迭代中执行解密而不是使用密钥 2 进行加密,也就是说,在最终的第三轮 DES 之前,它将数据恢复到一个中间的、故意不正确的表示。但是 Triple DES 也计划在 2024 年后从行业标准中移除。
同时,密码强度应与秘密(密钥和信息)的生命周期相称。如果需要快速的安全消息流,定期更新的较短密钥将提供更好的性能。
在哈希方法中,最现代的是 SHA256(SHA-2 标准的一个子集)。SHA1 和 MD5 方法被认为不安全,但为了与现有服务兼容仍被广泛使用。对于哈希方法,括号中指出了包含数据数字指纹的结果字节数组的大小。哈希不需要密钥,但在许多应用中,会将“盐”(salt) 附加到哈希数据上―这是一种秘密组件,使攻击者难以重现所需的哈希(例如,在猜测密码时)。
CRYPT_ARCH_ZIP 元素提供 ZIP 归档以及互联网上的数据请求传输/接收(参见 WebRequest)。
尽管该方法的名称中包含 ZIP,但压缩数据不等同于普通的 ZIP 存档,后者除了 "deflate" 容器外,总是包含元数据:特殊的头部、文件列表及其属性。在 mql5.com 网站上,文章和源代码库中,你可以找到将文件压缩到 ZIP 存档并从中提取的现成实现。压缩和提取由 CryptEncode/CryptDecode 函数执行,所有其他必要的 ZIP 格式结构都在 MQL5 代码中描述和填充。
Base64 方法旨在将二进制数据转换为文本,反之亦然。二进制数据通常包含许多不可打印的字符,并且不受编辑和输入工具(例如 MQL 程序属性对话框中的输入变量)的支持。例如,在处理流行的 JSON 对象数据交换文本格式时,Base64 可能很有用。
每 3 个原始字节在 Base64 中编码为 4 个字符,导致数据大小增加三分之一。本书附带了我们将在以下示例中进行实验的测试文件,特别是网页 MQL5/Files/MQL5Book/clock10.htm 和其中使用的时钟图像文件 MQL5/Files/MQL5Book/clock10.png。在这个介绍阶段,你已经可以清楚地看到二进制数据和 Base64 文本在内部表示上的可能性和差异,同时保持外观相同。
嵌入二进制图像和 Base64 格式的网页
相同的钟面图像作为外部文件 clock10.png 插入到页面中,同时其 Base64 编码也包含在 img 标签中(在其 src 属性中:这就是“数据 URL”)。直接在网页本身的文本中,它看起来是这样的(没有必要将长的 Base64 字符串按 76 个字符的宽度换行,但标准允许这样做,并且这里为了出版方便就这样做了):
<img src="data:image/png;base64,
|
很快我们将使用 CryptEncode 函数重现这个字符序列,但现在,只需注意使用类似的技术,我们可以从 MQL5 生成带有嵌入式图形的 HTML 报告。