当前位置: 首页 > 面试题库 >

什么是java.security.egd选项?

夔波
2023-03-14
问题内容

在我正在处理的项目中,该应用程序是使用类似于以下命令的启动的:

java -Djava.security.egd=file:/dev/urandom -jar app.jar

我从未见过该java.security.egd选项。进行一点搜索,似乎可以用来配置Java应用程序中的随机数生成。

这样对吗?什么时候应该使用?


问题答案:

Java应用程序可以并且应该使用 java.security.SecureRandom
类通过使用加密强度高的伪随机数生成器(CSPRNG)来生成加密强度高的随机值。
java.util.Random 类的标准JDK实现在密码学上不强。

类似于Unix的操作系统具有/dev/random特殊文件,该文件提供伪随机数,以访问从设备驱动程序和其他来源收集的环境噪声。但是,
如果可用的熵比请求的少它将阻塞
/dev/urandom即使自启动以来没有用熵完全初始化伪随机数生成器种子,通常也不会阻塞。还有一个第3个特殊文件,/dev/arandom该文件在启动后会阻塞,直到种子被足够的熵安全地初始化为止,然后再也不会阻塞。

默认情况下,JVM 使用来播种 SecureRandom/dev/random,因此 您的Java代码可能会意外阻止
-Djava.security.egd=file:/dev/./urandom用于启动Java进程的命令行调用中的选项告诉JVM
/dev/urandom代替使用。

多余的东西/./似乎使JVM使用SHA1PRNG算法,该算法使用SHA-1作为PRNG(伪随机数生成器)的基础。它比/dev/urandom指定时使用的NativePRNG算法强。

最后,有一个神话 /dev/urandom
是伪随机数生成器PRNG,而又/dev/random是“真”随机数生成器
。这是不正确的,这两个/dev/random/dev/urandom由相同CSPRNG(密码安全伪随机数发生器)被馈送。只有它们的行为不同:/dev/random根据某些估计,当其随机池耗尽熵时会阻塞,而/dev/urandom不会。

低熵的系统呢? 还算不错

事实证明,“看起来随机”是几个加密组件(如Web服务器的临时会话密钥)的基本要求。而且,如果采用加密哈希的输出,则它与随机字符串是无法区分的,因此密码将接受它。这就是使用SHA1PRNG算法的原因,因为它使用哈希函数和计数器以及种子。

应该什么时候使用?

我总是说。

资料来源:
https : //gist.github.com/svrc/5a8accc57219b9548fe1
https://www.2uo.de/myths-about-urandom

编辑06/2020:
我已更改此更新以反映对Java 11的测试,因为它是当前的长期支持(LTS)版本。

评论提到Java 8中 SecureRandom 类的行为发生了变化。

SHA1PRNG和NativePRNG已修复,以正确遵守java.security文件中的SecureRandom种子源属性。(不再需要使用file:///
dev / urandom和file:/ dev /./ urandom的变通方法。)

上面“源”部分中引用的测试已经指出了这一点。额外/./需要改变所使用的算法 的SecureRandom
在Java中8从NativePRNG到SHA1PRNG。

但是,我确实有一些要分享的新闻。根据JEP-273,从Java 9开始,
SecureRandom 类实现了NIST
800-90Ar1中描述的三种
确定性随机位生成器(DRBG)
机制。这些机制实现了强度高达SHA-512和AES-256的现代算法。

JDK以前有两种 SecureRandom 实现:

  • 一种是平台相关的,并且基于本地调用或OS设备,例如/dev/{u}random在Unix上阅读或在Windows上使用CryptoAPI。最新版本的Linux和Windows已经支持DRBG, 但是较早的版本和嵌入式系统可能不支持
  • 另一种是使用较旧的基于SHA1的RNG实现的纯Java实现,它不如已批准的DRBG机制使用的算法强大。

同时,《Java
11安全开发人员指南》仍为

在Linux和macOS上,如果java.security中的熵收集设备设置为file:/dev/urandomfile:/dev/random,则NativePRNG优于SHA1PRNG。否则,首选SHA1PRNG。

为了阐明新的DRBG机制如何与以前的PRNG一起使用,我在MacOS(Darwin)上使用AdoptOpenJDK(内部版本11.0.7 +
10)进行了一些测试。结果如下:

-Djava.security.egd=file:/dev/random这等于默认选项
默认算法: NativePRNG
提供程序: SecureRandom.NativePRNG算法来自:SUN

-Djava.security.egd=file:/dev/urandom
默认算法: NativePRNG
提供程序: SecureRandom.NativePRNG算法来自:SUN

-Djava.security.egd=file:/dev/./urandom
默认算法: DRBG
提供者: SecureRandom.DRBG算法来自:SUN

最后,/dev/urandom即使在使用现代OS时,用作随机源的问题仍然至关重要,因为我们可以在这篇非常有趣的文章中阅读:多租户Linux容器平台中的随机性挑战。

结论:

我建议继续使用-Djava.security.egd=file:/dev/./urandomJava 11以确保:

  1. 无论使用什么平台(DRBG),都可以利用最强大的 SecureRandom 实现
  2. 避免使代码意外阻塞(securerandom.source=file:/dev/urandom

资料来源:
https : //www.openssl.org/blog/blog/2017/08/12/random/



 类似资料:
  • 在我正在做的一个项目中,应用程序是使用类似于以下命令启动的: 我从未见过选项。稍微搜索一下,它似乎用于在Java应用程序中配置随机数生成。 是这样吗?什么时候应用?

  • 问题内容: 我看到了一些命令所在的教程: 该选项是什么意思? 在Google上找不到答案。 问题答案: 更新npm 5: 从npm 5.0.0开始 ,默认情况下已安装的模块作为依赖项添加,因此不再需要该选项。其他保存选项依然存在并在中列出的文件的。 原始答案: 在版本5之前,NPM 默认情况下只是安装了一个软件包。当您尝试为应用程序/模块安装依赖项时,您需要先安装它们,然后将它们(以及适当的版本号

  • 问题内容: 它以空字符串开头,而不是nil。即使将其显式设置为nil,它仍然是一个空字符串。我不明白 也许通过分配nil使其易于清除?用它编写代码很麻烦。 问题答案: 这是历史性的事情。空字符串和字符串之间没有任何区别。在Objective- C中,无需在两者之间进行区别,因为您可以在Objective-C中调用方法。 同样,在Objective-C中也无法阻止用户分配给属性。生成的合同可以是可选

  • 问题内容: 我已经看过几次CSS代码中使用的“大于”(),但是我无法弄清楚它的作用。它有什么作用? 问题答案: 选择直系子女 例如,如果您有这样的嵌套div: 然后在样式表中声明css规则,如下所示: 您的规则仅适用于具有“中级”类的div,因为这些div是元素为“外部”类的元素的直接后代(直接子代)(当然,除非您声明其他更具体的规则来覆盖这些规则) 。见小提琴。 边注 如果您>>`。 注意:IE

  • 问题内容: 我对加密一无所知。我想知道会话秘密是什么。 我看到这样的代码: 什么是秘密,我应该更改吗? 问题答案: 是的,您应该更改它。连接中的会话秘密仅用于 计算哈希 。没有字符串,对会话的访问实质上将被“拒绝”。看一下connect docs ,应该会有所帮助。

  • 问题内容: 从Apple的文档中: 您可以使用和一起使用可能缺少的值。这些值表示为可选值。可选值包含一个值或包含一个指示该值丢失的值。在值的类型后写一个问号(),以将该值标记为可选。 为什么要使用可选值? 问题答案: Swift中的可选类型是可以保存值或不保存值的类型。通过将a附加到任何类型来编写可选内容: 可选(以及泛型)是最难理解的Swift概念之一。由于它们是如何编写和使用的,很容易对它们是