C++ 从OPENSSL-1.0.1r中删除OPENSSL_clean

我发现

OPENSSL\u clean

在我的工作中浪费了很多时间。例如，如果它运行25秒，则OPENSSL_clean会浪费3秒。我检查了这个函数的代码，认为它对我没有什么用处。我知道这是出于安全考虑，但我真的不在乎。所以我决定放置

return在此函数中任何操作开始之前

void OPENSSL_cleanse(void *ptr, size_t len)
{
    return;
    // original OpenSSL code goes here
}

我正在使用Mac OS和Xcode。我已经编译了lib并通过
配置
脚本的
--openssldir
选项将其安装在
/Users/ForceBru/Desktop/openssl
中。我已经在
Build Settings->linkbinary With Libraries
中将它添加到我的项目中，并在
Build Settings->Search path->Header Search path
和
Build Settings->Search path->Library Search path
中添加了include dirs

该项目编译得很好，但是时间分析器仍然显示了对
OPENSSL\u cleanse
的非常昂贵的调用

 < >编辑：>代码> C>代码>标签，因为OpenSSL是用C编写的， C++ +/Cuth>标签是因为我的代码是C++的。也许这些信息会有帮助
问题是，我做错了什么？如何删除对
OPENSSL\u clean
的调用？我认为这与链接有关，因为命令行包括
-lcrypto
，这意味着这个库实际上可以从任何地方获取（对吗？），而不一定是从
/Users/ForceBru/Desktop/openssl
获取的

编辑#2:我已经编辑了链接器选项，以使用
/Users/ForceBru/Desktop/openssl
中的
.a
文件，并将其从
构建设置->链接二进制库中删除。仍然没有效果。
事实证明，OpenSSL有许多由位于
crypto
目录（
*cpuid.pl
）中的一些Perl脚本生成的汇编代码。这些脚本为以下体系结构生成汇编代码：
alpha
，
armv4
，
ia64
，
ppc
，
s390x
，
sparc
，
x86
和
x86\u 64

当运行
make
时，相应的脚本将触发，生成
*cpuid.S
（其中
*
是前面提到的体系结构之一）。这些文件被编译到库中，似乎覆盖了
crypto/mem\u clr.c
中实现的
OPENSSL\u clean

我所要做的只是在
x86\u 64cpuid.pl
中将
OPENSSL\u clean
的主体更改为
ret
：

.globl OPENSSL_cleanse
.type OPENSSL_cleanse,\@abi-omnipotent
.align 16
OPENSSL_cleanse:
    ret
    # loads of OPENSSL assembly
.size OPENSSL_cleanse,.-OPENSSL_cleanse

这不是你一直在寻找的答案，但它可能会帮助你


从OPENSSL-1.0.1r中删除OPENSSL_clean…

我检查了这个函数的代码，认为它对我没有什么用处

这可能是个坏主意，但我们需要更多地了解您的威胁模型。归零允许您确定地从内存中删除敏感材料

它也是一个认证和认可（C&a）项目。例如，即使在级别1也需要归零

另外，您不能删除
OPENSSL\u cleanse
本身，因为
OPENSSL\u clear\u realloc
，
OPENSSL\u clear\u free
和朋友们称之为它。另请参见手册页


例如，如果它运行25秒，OPENSSL_Clean会浪费3秒

好的，这是一个不同的问题。这有点复杂，为了在优化过程中生存下来，它确实浪费了一些周期

如果您进行检查，您将看到它在OpenSSL 1.1.0中已更改为以下内容。也许你可以用它来代替

diff --git a/crypto/mem_clr.c b/crypto/mem_clr.c
index e6450a1..3389919 100644 (file)
--- a/crypto/mem_clr.c
+++ b/crypto/mem_clr.c
@@ -59,23 +59,16 @@
 #include <string.h>
 #include <openssl/crypto.h>

-extern unsigned char cleanse_ctr;
-unsigned char cleanse_ctr = 0;
+/*
+ * Pointer to memset is volatile so that compiler must de-reference
+ * the pointer and can't assume that it points to any function in
+ * particular (such as memset, which it then might further "optimize")
+ */
+typedef void *(*memset_t)(void *,int,size_t);
+
+static volatile memset_t memset_func = memset;

 void OPENSSL_cleanse(void *ptr, size_t len)
 {
-    unsigned char *p = ptr;
-    size_t loop = len, ctr = cleanse_ctr;
-
-    if (ptr == NULL)
-        return;
-
-    while (loop--) {
-        *(p++) = (unsigned char)ctr;
-        ctr += (17 + ((size_t)p & 0xF));
-    }
-    p = memchr(ptr, (unsigned char)ctr, len);
-    if (p)
-        ctr += (63 + (size_t)p);
-    cleanse_ctr = (unsigned char)ctr;
+    memset_func(ptr, 0, len);
 }


与此相反：

void OPENSSL_cleanse(void *ptr, size_t len)
{
    return;
    // original OpenSSL code goes here
}

也许您可以删除该函数，然后：

#define OPENSSL_cleanse(x, y)

然后函数调用变成一个宏，在优化过程中会消失。从函数更改为宏后，务必执行
清除

但我不建议这样做


该项目编译得很好，但是时间分析器仍然显示了对OPENSSL_clean的非常昂贵的调用

我的猜测是：（1）在对OpenSSL库进行更改后，您没有执行
make clean
，或者（2）您编译并链接到错误版本的OpenSSL库。但我可能在这两方面都错了

您可以通过
otool-L
查看可执行文件的运行时依赖项。确保它是预期的。还要记住OpenSSL不使用
-install\u name

在运行可执行文件之前，可以设置以确保正在修改的动态库已加载。另请参见手册。
我认为您是正确的，这可能就是原因所在。您可能希望将修改后的openssl实例静态链接到您的项目（我不建议链接完全静态的二进制文件，只链接openssl库）@Ctx，我该怎么做？找到自定义openssl库libssl.a和libcrypto.a的正确版本，并在链接器命令行中使用完整路径指定这些版本。依次从中删除
-lssl
和
-lcrypto
。@Ctx，我已经这样做了，但是它
OPENSSL\u cleanse
仍然在那里。您可以检查您使用的libcrypto.a是否确实是使用
objdump-d libcrypto.a的修改版本，并查看它是否确实返回而不做任何其他操作。否则，定制openssl就已经出了问题。我提供了一个指向我的项目的链接，所以你可以看到我真的不在乎这个安全原因。这只是一个暴力程序，我需要的只是速度，所以任何时候都必须删除消费者。不，将
OPENSSL\u clean
更改为宏会导致链接器错误，因为我在回答中提到了汇编代码。我现在不明白的是
mem\u clr.c
中函数的用途。为什么它会在这里，而这里却有集会？@ForceBru-“我不明白的是
#define OPENSSL_cleanse(x, y)