热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

用x64汇编优化8位S盒置换(二)

2019独角兽企业重金招聘Python工程师标准在论坛上有人提出,可以考虑用空间换取时间的方式来优化S盒置换,使用8位S盒,4字节置

2019独角兽企业重金招聘Python工程师标准>>> hot3.png

在论坛上有人提出,可以考虑用空间换取时间的方式来优化S盒置换,使用8位S盒,4字节置换需要进行4次查表,哪怕是S盒数组为了内存对齐而采用64位数据宽度,其本质仍旧是8位S盒数组,数据单元总数依旧是256个,对于本文所涉及的课题,理论上可以用16位甚至是32位S盒数组,前者进行4字节置换仅需2次查表操作,后者则一步到位,1次差表就完成了4字节置换,然而从实用角度而言,16位S盒数组是唯一可行的方案,原因很简单:32位S盒数组至少要占用 (2 ^ 32) x 4 = 16GB内存,这不但浪费内存而且会因为频繁大范围内存寻址造成CPU缓存波动。

首先是内存最少的方式,S盒数组下标范围16位,每个数据单元16位,总计占用 65536 x 2 = 128KB内存,完整代码如下:

#include static uint8_t s_sbox8[256] = {0xd6,0x90,0xe9,0xfe,0xcc,0xe1,0x3d,0xb7,0x16,0xb6,0x14,0xc2,0x28,0xfb,0x2c,0x05,0x2b,0x67,0x9a,0x76,0x2a,0xbe,0x04,0xc3,0xaa,0x44,0x13,0x26,0x49,0x86,0x06,0x99,0x9c,0x42,0x50,0xf4,0x91,0xef,0x98,0x7a,0x33,0x54,0x0b,0x43,0xed,0xcf,0xac,0x62,0xe4,0xb3,0x1c,0xa9,0xc9,0x08,0xe8,0x95,0x80,0xdf,0x94,0xfa,0x75,0x8f,0x3f,0xa6,0x47,0x07,0xa7,0xfc,0xf3,0x73,0x17,0xba,0x83,0x59,0x3c,0x19,0xe6,0x85,0x4f,0xa8,0x68,0x6b,0x81,0xb2,0x71,0x64,0xda,0x8b,0xf8,0xeb,0x0f,0x4b,0x70,0x56,0x9d,0x35,0x1e,0x24,0x0e,0x5e,0x63,0x58,0xd1,0xa2,0x25,0x22,0x7c,0x3b,0x01,0x21,0x78,0x87,0xd4,0x00,0x46,0x57,0x9f,0xd3,0x27,0x52,0x4c,0x36,0x02,0xe7,0xa0,0xc4,0xc8,0x9e,0xea,0xbf,0x8a,0xd2,0x40,0xc7,0x38,0xb5,0xa3,0xf7,0xf2,0xce,0xf9,0x61,0x15,0xa1,0xe0,0xae,0x5d,0xa4,0x9b,0x34,0x1a,0x55,0xad,0x93,0x32,0x30,0xf5,0x8c,0xb1,0xe3,0x1d,0xf6,0xe2,0x2e,0x82,0x66,0xca,0x60,0xc0,0x29,0x23,0xab,0x0d,0x53,0x4e,0x6f,0xd5,0xdb,0x37,0x45,0xde,0xfd,0x8e,0x2f,0x03,0xff,0x6a,0x72,0x6d,0x6c,0x5b,0x51,0x8d,0x1b,0xaf,0x92,0xbb,0xdd,0xbc,0x7f,0x11,0xd9,0x5c,0x41,0x1f,0x10,0x5a,0xd8,0x0a,0xc1,0x31,0x88,0xa5,0xcd,0x7b,0xbd,0x2d,0x74,0xd0,0x12,0xb8,0xe5,0xb4,0xb0,0x89,0x69,0x97,0x4a,0x0c,0x96,0x77,0x7e,0x65,0xb9,0xf1,0x09,0xc5,0x6e,0xc6,0x84,0x18,0xf0,0x7d,0xec,0x3a,0xdc,0x4d,0x20,0x79,0xee,0x5f,0x3e,0xd7,0xcb,0x39,0x48
};static uint16_t s_sbox[65536];void sbox_init(void)
{uint64_t i;for(i &#61; 0; i <65536; i&#43;&#43;) {s_sbox[i] &#61; s_sbox8[i & 0xff] ^ (s_sbox8[i >> 8] <<8);}
}uint32_t sbox(uint32_t src)
{uint32_t dst;dst &#61; s_sbox[src & 0xffff] ^ (s_sbox[(src >> 16)] <<16);return(dst);
}

在原有的8位S盒数组的基础上&#xff0c;构造一个16位S盒数组&#xff0c;使用前须初始化&#xff0c;对应的测试程序代码变成&#xff1a;

#include
#include
#include
#include
#include uint32_t sbox(uint32_t src);
void sbox_init(void);int main(int argc, char *argv[])
{uint32_t i, data;sbox_init();data &#61; 0x00010203;for(i &#61; 0; i <100000000; i&#43;&#43;) {data &#61; sbox(data);}printf("data &#61; %08x\n", data);exit(EXIT_SUCCESS);
}

编译并运行&#xff0c;得到如下结果&#xff1a;

[root&#64;sxy-lenovo step4]# time ./test_sbox
data &#61; 9acd23e0real 0m0.460s
user 0m0.458s
sys 0m0.000s

相比8位S盒数组的版本&#xff0c;性能提升是明显的。

既然如此&#xff0c;可以考虑将16位S盒的数据单元大小从16位提升到64位&#xff0c;看看内存对齐对于16位S盒有何影响。只要将文件sbox.c的uint16_t数据类型改成uint64_t就行了&#xff1a;

#include static uint8_t s_sbox8[256] &#61; {0xd6,0x90,0xe9,0xfe,0xcc,0xe1,0x3d,0xb7,0x16,0xb6,0x14,0xc2,0x28,0xfb,0x2c,0x05,0x2b,0x67,0x9a,0x76,0x2a,0xbe,0x04,0xc3,0xaa,0x44,0x13,0x26,0x49,0x86,0x06,0x99,0x9c,0x42,0x50,0xf4,0x91,0xef,0x98,0x7a,0x33,0x54,0x0b,0x43,0xed,0xcf,0xac,0x62,0xe4,0xb3,0x1c,0xa9,0xc9,0x08,0xe8,0x95,0x80,0xdf,0x94,0xfa,0x75,0x8f,0x3f,0xa6,0x47,0x07,0xa7,0xfc,0xf3,0x73,0x17,0xba,0x83,0x59,0x3c,0x19,0xe6,0x85,0x4f,0xa8,0x68,0x6b,0x81,0xb2,0x71,0x64,0xda,0x8b,0xf8,0xeb,0x0f,0x4b,0x70,0x56,0x9d,0x35,0x1e,0x24,0x0e,0x5e,0x63,0x58,0xd1,0xa2,0x25,0x22,0x7c,0x3b,0x01,0x21,0x78,0x87,0xd4,0x00,0x46,0x57,0x9f,0xd3,0x27,0x52,0x4c,0x36,0x02,0xe7,0xa0,0xc4,0xc8,0x9e,0xea,0xbf,0x8a,0xd2,0x40,0xc7,0x38,0xb5,0xa3,0xf7,0xf2,0xce,0xf9,0x61,0x15,0xa1,0xe0,0xae,0x5d,0xa4,0x9b,0x34,0x1a,0x55,0xad,0x93,0x32,0x30,0xf5,0x8c,0xb1,0xe3,0x1d,0xf6,0xe2,0x2e,0x82,0x66,0xca,0x60,0xc0,0x29,0x23,0xab,0x0d,0x53,0x4e,0x6f,0xd5,0xdb,0x37,0x45,0xde,0xfd,0x8e,0x2f,0x03,0xff,0x6a,0x72,0x6d,0x6c,0x5b,0x51,0x8d,0x1b,0xaf,0x92,0xbb,0xdd,0xbc,0x7f,0x11,0xd9,0x5c,0x41,0x1f,0x10,0x5a,0xd8,0x0a,0xc1,0x31,0x88,0xa5,0xcd,0x7b,0xbd,0x2d,0x74,0xd0,0x12,0xb8,0xe5,0xb4,0xb0,0x89,0x69,0x97,0x4a,0x0c,0x96,0x77,0x7e,0x65,0xb9,0xf1,0x09,0xc5,0x6e,0xc6,0x84,0x18,0xf0,0x7d,0xec,0x3a,0xdc,0x4d,0x20,0x79,0xee,0x5f,0x3e,0xd7,0xcb,0x39,0x48
};static uint64_t s_sbox[65536];void sbox_init(void)
{uint64_t i;for(i &#61; 0; i <65536; i&#43;&#43;) {s_sbox[i] &#61; s_sbox8[i & 0xff] ^ (s_sbox8[i >> 8] <<8);}
}uint64_t sbox(uint64_t src)
{uint64_t dst;dst &#61; s_sbox[src & 0xffff] ^ (s_sbox[(src >> 16)] <<16);return(dst);
}

编译运行测试程序&#xff0c;结果是&#xff1a;

[root&#64;sxy-lenovo step5]# time ./test_sbox
data &#61; 9acd23e0real 0m0.840s
user 0m0.838s
sys 0m0.002s

这不是我想要的结果&#xff0c;这不科学&#xff01;&#xff01;&#xff01;64位数据单元可能过大了&#xff0c;改成32位再试试&#xff1a;

[root&#64;sxy-lenovo step6]# time ./test_sbox
data &#61; 9acd23e0real 0m0.530s
user 0m0.529s
sys 0m0.000s

这个结果比64位数据单元的版本强&#xff0c;依旧不如16位数据单元的版本&#xff0c;究竟是什么导致了性能劣化呢&#xff0c;答案是显而易见的&#xff1a;CPU缓存

[root&#64;sxy-lenovo step6]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i3 CPU M 370 &#64; 2.40GHz
stepping : 5
microcode : 4
cpu MHz : 2399.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes

运行程序的是一个老款笔记本电脑&#xff0c;其CPU的一级缓存为64KB&#xff0c;二级缓存为256KB&#xff0c;三级缓存为3MB&#xff0c;最初的8位S盒数组数据单元仅8位&#xff0c;占用了256字节&#xff0c;即便扩展到64位数据单元&#xff0c;也占用不过2KB内存&#xff0c;若使用16位S盒&#xff0c;当数据单元为16位时&#xff0c;占用128KB内存&#xff0c;当数据单元到达32位时&#xff0c;内存占用到了256KB&#xff0c;再依据测试消耗时间就可以得到初步结论&#xff1a;若S盒数组占用内存小于当前CPU的二级缓存大小时&#xff0c;性能将达到最优&#xff0c;若超出反而会变差。

到这里&#xff0c;可以明确地说&#xff1a;C语言的S盒置换优化之路走到了尽头&#xff0c;事态的发展真的是走投无路了吗&#xff1f;搞过单片机或是FPGA的都知道&#xff0c;通用CPU实施对称密码算法运算几乎无优势可言&#xff0c;反而是专用芯片无论是在成本还是在综合性能上都牢牢占据优势。造成这一现象的最主要的矛盾来自于CPU主频和内存芯片主频的巨大差异&#xff0c;大家都知道&#xff0c;限于PC平台的成本要求&#xff0c;与其采用高频内存芯片&#xff0c;还不如提高CPU缓存性能与大小更合算。解决S盒置换的终极方案之一早已在通用CPU中加入&#xff0c;以Intel为例&#xff0c;所谓的AESNI指令就是干这个的&#xff0c;使用AESNI指令进行AES算法运算能大幅度提高性能&#xff0c;里面的关键点就是抛弃了传统的S盒查表置换方式&#xff0c;直接用内置硬件计算AES算法专用的GF2^8有限域乘法和乘法逆&#xff0c;这使得AES算法在支持AESNI指令集的CPU上获得超乎想像的性能增益&#xff0c;而对于本文涉及的国密SMS4算法而言&#xff0c;AESNI是没有任何意义的&#xff0c;要想突破查表法的性能限制&#xff0c;就必须走另外的路。

 


转:https://my.oschina.net/safedead/blog/832940



推荐阅读
  • PHP预处理常量详解:如何定义与使用常量 ... [详细]
  • 本文详细解析了使用C++实现的键盘输入记录程序的源代码,该程序在Windows应用程序开发中具有很高的实用价值。键盘记录功能不仅在远程控制软件中广泛应用,还为开发者提供了强大的调试和监控工具。通过具体实例,本文深入探讨了C++键盘记录程序的设计与实现,适合需要相关技术的开发者参考。 ... [详细]
  • 使用 ListView 浏览安卓系统中的回收站文件 ... [详细]
  • 在使用 Qt 进行 YUV420 图像渲染时,由于 Qt 本身不支持直接绘制 YUV 数据,因此需要借助 QOpenGLWidget 和 OpenGL 技术来实现。通过继承 QOpenGLWidget 类并重写其绘图方法,可以利用 GPU 的高效渲染能力,实现高质量的 YUV420 图像显示。此外,这种方法还能显著提高图像处理的性能和流畅性。 ... [详细]
  • 在Android平台中,播放音频的采样率通常固定为44.1kHz,而录音的采样率则固定为8kHz。为了确保音频设备的正常工作,底层驱动必须预先设定这些固定的采样率。当上层应用提供的采样率与这些预设值不匹配时,需要通过重采样(resample)技术来调整采样率,以保证音频数据的正确处理和传输。本文将详细探讨FFMpeg在音频处理中的基础理论及重采样技术的应用。 ... [详细]
  • 利用ZFS和Gluster实现分布式存储系统的高效迁移与应用
    本文探讨了在Ubuntu 18.04系统中利用ZFS和Gluster文件系统实现分布式存储系统的高效迁移与应用。通过详细的技术分析和实践案例,展示了这两种文件系统在数据迁移、高可用性和性能优化方面的优势,为分布式存储系统的部署和管理提供了宝贵的参考。 ... [详细]
  • 在当前的软件开发领域,Lua 作为一种轻量级脚本语言,在 .NET 生态系统中的应用逐渐受到关注。本文探讨了 Lua 在 .NET 环境下的集成方法及其面临的挑战,包括性能优化、互操作性和生态支持等方面。尽管存在一定的技术障碍,但通过不断的学习和实践,开发者能够克服这些困难,拓展 Lua 在 .NET 中的应用场景。 ... [详细]
  • MSP430F5438 ADC12模块应用与学习心得
    在最近的实践中,我深入研究了MSP430F5438的ADC12模块。尽管该模块的功能相对简单,但通过实际操作,我对MSP430F5438A和MSP430F5438之间的差异有了更深刻的理解。本文将分享这些学习心得,并探讨如何更好地利用ADC12模块进行数据采集和处理。 ... [详细]
  • Maven Web项目创建时JSP文件常见错误及解决方案
    Maven Web项目创建时JSP文件常见错误及解决方案 ... [详细]
  • 本文详细介绍了一种利用 ESP8266 01S 模块构建 Web 服务器的成功实践方案。通过具体的代码示例和详细的步骤说明,帮助读者快速掌握该模块的使用方法。在疫情期间,作者重新审视并研究了这一未被充分利用的模块,最终成功实现了 Web 服务器的功能。本文不仅提供了完整的代码实现,还涵盖了调试过程中遇到的常见问题及其解决方法,为初学者提供了宝贵的参考。 ... [详细]
  • 本文详细介绍了在Linux系统上编译安装MySQL 5.5源码的步骤。首先,通过Yum安装必要的依赖软件包,如GCC、GCC-C++等,确保编译环境的完备。接着,下载并解压MySQL 5.5的源码包,配置编译选项,进行编译和安装。最后,完成安装后,进行基本的配置和启动测试,确保MySQL服务正常运行。 ... [详细]
  • C语言中类型自动转换的深入解析与应用
    C语言中类型自动转换的深入解析与应用 ... [详细]
  • NOIP2000的单词接龙问题与常见的成语接龙游戏有异曲同工之妙。题目要求在给定的一组单词中,从指定的起始字母开始,构建最长的“单词链”。每个单词在链中最多可出现两次。本文将详细解析该题目的解法,并分享学习过程中的心得体会。 ... [详细]
  • 在Linux系统中,通过使用`read`和`write`函数可以实现文件的高效复制操作。`open`函数用于打开或创建文件,其返回值为文件描述符,成功时返回一个有效的文件描述符,失败时返回-1。`path`参数指定了要操作的文件路径,而`oflag`参数则定义了文件的打开模式和属性。此外,为了确保数据的完整性和一致性,还需要合理处理文件读取和写入过程中的错误和异常情况。 ... [详细]
  • Python全局解释器锁(GIL)机制详解
    在Python中,线程是操作系统级别的原生线程。为了确保多线程环境下的内存安全,Python虚拟机引入了全局解释器锁(Global Interpreter Lock,简称GIL)。GIL是一种互斥锁,用于保护对解释器状态的访问,防止多个线程同时执行字节码。尽管GIL有助于简化内存管理,但它也限制了多核处理器上多线程程序的并行性能。本文将深入探讨GIL的工作原理及其对Python多线程编程的影响。 ... [详细]
author-avatar
于昕会_445
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有