document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-03-03 01:10:13 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'LCTT/master'

Browse Source
This commit is contained in:
wxy 2018-03-25 21:39:07 +08:00
commit b0a1d8e409
4 changed files with 105 additions and 110 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

92
published/20140225 How To Safely Generate A Random Number - Quarrelsome.md Normal file
View File

@ -0,0 +1,92 @@
如何安全地生成随机数
======
### 使用 urandom
使用 [urandom][1]！使用 [urandom][2]！使用 [urandom][3]！
使用 [urandom][4]！使用 [urandom][5]！使用 [urandom][6]！
### 但对于密码学密钥呢？
仍然使用 [urandom][6]。
### 为什么不是 SecureRandom、OpenSSL、havaged 或者 c 语言实现呢？
这些是用户空间的 CSPRNG（伪随机数生成器）。你应该用内核的 CSPRNG，因为：
* 内核可以访问原始设备熵。
* 它可以确保不在应用程序之间共享相同的状态。
* 一个好的内核 CSPRNG，像 FreeBSD 中的，也可以保证它播种之前不给你随机数据。
研究过去十年中的随机失败案例，你会看到一连串的用户空间的随机失败案例。[Debian 的 OpenSSH 崩溃][7]？用户空间随机！安卓的比特币钱包[重复 ECDSA 随机 k 值][8]？用户空间随机！可预测洗牌的赌博网站？用户空间随机！
用户空间的生成器几乎总是依赖于内核的生成器。即使它们不这样做，整个系统的安全性也会确保如此。**但用户空间的 CSPRNG 不会增加防御深度；相反，它会产生两个单点故障。**
### 手册页不是说使用 /dev/random 嘛？
这个稍后详述，保留你的意见。你应该忽略掉手册页。不要使用 `/dev/random`。`/dev/random` 和 `/dev/urandom` 之间的区别是 Unix 设计缺陷。手册页不想承认这一点，因此它产生了一个并不存在的安全顾虑。把 `random(4)` 中的密码学上的建议当作传说，继续你的生活吧。
### 但是如果我需要的是真随机值，而非伪随机值呢？
urandom 和 `/dev/random` 提供的是同一类型的随机。与流行的观念相反，`/dev/random` 不提供“真正的随机”。从密码学上来说，你通常不需要“真正的随机”。
urandom 和 `/dev/random` 都基于一个简单的想法。它们的设计与流密码的设计密切相关：一个小秘密被延伸到不可预测值的不确定流中。 这里的秘密是“熵”，而流是“输出”。
只在 Linux 上 `/dev/random` 和 urandom 仍然有意义上的不同。Linux 内核的 CSPRNG 定期进行密钥更新（通过收集更多的熵）。但是 `/dev/random` 也试图跟踪内核池中剩余的熵，并且如果它没有足够的剩余熵时，偶尔也会罢工。这种设计和我所说的一样蠢；这与基于“密钥流”中剩下多少“密钥”的 AES-CTR 设计类似。
如果你使用 `/dev/random` 而非 urandom，那么当 Linux 对自己的 RNG（随机数生成器）如何工作感到困惑时，你的程序将不可预测地（或者如果你是攻击者，非常可预测地）挂起。使用 `/dev/random` 会使你的程序不太稳定，但这不会让你在密码学上更安全。
### 这是个缺陷，对吗？
不是，但存在一个你可能想要了解的 Linux 内核 bug，即使这并不能改变你应该使用哪一个 RNG。
在 Linux 上，如果你的软件在引导时立即运行，或者这个操作系统你刚刚安装好，那么你的代码可能会与 RNG 发生竞争。这很糟糕，因为如果你赢了竞争，那么你可能会在一段时间内从 urandom 获得可预测的输出。这是 Linux 中的一个 bug，如果你正在为 Linux 嵌入式设备构建平台级代码，那你需要了解它。
在 Linux 上，这确实是 urandom（而不是 `/dev/random`）的问题。这也是 [Linux 内核中的错误][9]。 但它也容易在用户空间中修复：在引导时，明确地为 urandom 提供种子。长期以来，大多数 Linux 发行版都是这么做的。但**不要**切换到不同的 CSPRNG。
### 在其它操作系统上呢？
FreeBSD 和 OS X 消除了 urandom 和 `/dev/random` 之间的区别；这两个设备的行为是相同的。不幸的是，手册页在解释为什么这样做上干的很糟糕，并延续了 Linux 上 urandom 可怕的神话。
无论你使用 `/dev/random` 还是 urandom，FreeBSD 的内核加密 RNG 都不会停摆。 除非它没有被提供种子，在这种情况下，这两者都会停摆。与 Linux 不同，这种行为是有道理的。Linux 应该采用它。但是，如果你是一名应用程序开发人员，这对你几乎没有什么影响：Linux、FreeBSD、iOS，无论什么：使用 urandom 吧。
### 太长了，懒得看
直接使用 urandom 吧。
### 结语
[ruby-trunk Feature #9569][10]
> 现在，在尝试检测 `/dev/urandom` 之前，SecureRandom.random_bytes 会尝试检测要使用的 OpenSSL。 我认为这应该反过来。在这两种情况下，你只需要将随机字节进行解压，所以 SecureRandom 可以跳过中间人（和第二个故障点），如果可用的话可以直接与 `/dev/urandom` 进行交互。
总结：
> `/dev/urandom` 不适合用来直接生成会话密钥和频繁生成其他应用程序级随机数据。
>
> GNU/Linux 上的 random(4) 手册所述......
感谢 Matthew Green、 Nate Lawson、 Sean Devlin、 Coda Hale 和 Alex Balducci 阅读了本文草稿。公正警告：Matthew 只是大多同意我的观点。
--------------------------------------------------------------------------------
via: https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
作者：[Thomas & Erin Ptacek][a]
译者：[kimii](https://github.com/kimii)
校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://sockpuppet.org/blog
[1]:http://blog.cr.yp.to/20140205-entropy.html
[2]:http://cr.yp.to/talks/2011.09.28/slides.pdf
[3]:http://golang.org/src/pkg/crypto/rand/rand_unix.go
[4]:http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key
[5]:http://stackoverflow.com/a/5639631
[6]:https://twitter.com/bramcohen/status/206146075487240194
[7]:http://research.swtch.com/openssl
[8]:http://arstechnica.com/security/2013/08/google-confirms-critical-android-crypto-flaw-used-in-5700-bitcoin-heist/
[9]:https://factorable.net/weakkeys12.extended.pdf
[10]:https://bugs.ruby-lang.org/issues/9569

28
translated/tech/20180125 Building a Linux-based HPC system on the Raspberry.md → published/20180125 Building a Linux-based HPC system on the Raspberry.md
View File

@ -1,15 +1,14 @@
使用 Ansible 在树莓派上构建一个基于 Linux 的高性能计算系统
============================================================
### 使用低成本的硬件和开源软件设计一个高性能计算集群。
> 使用低成本的硬件和开源软件设计一个高性能计算集群。
![Building a Linux-based HPC system on the Raspberry Pi with Ansible](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/code_computer_development_programming.png?itok=4OM29-82 "Building a Linux-based HPC system on the Raspberry Pi with Ansible")
图片来源：opensource.com
在我的 [Opensource.com 上前面的文章中][14]，我介绍了 [OpenHPC][15] 项目，它的目标是致力于加速高性能计算（HPC）的创新。这篇文章将更深入来介绍使用 OpenHPC 的特性来构建一个小型的 HPC 系统。将它称为 _HPC 系统_  可能有点“扯虎皮拉大旗”的意思，因此，更确切的说法应该是，通过 OpenHPC 项目发布的 [方法构建集群][16] 系统。
这个集群由两台树莓派 3 系统作为活动计算节点，以及一台虚拟机作为主节点，结构示意如下：
在我的 [之前发表在 Opensource.com 上的文章中][14]，我介绍了 [OpenHPC][15] 项目，它的目标是致力于加速高性能计算（HPC）的创新。这篇文章将更深入来介绍使用 OpenHPC 的特性来构建一个小型的 HPC 系统。将它称为 _HPC 系统_  可能有点“扯虎皮拉大旗”的意思，因此，更确切的说法应该是，它是一个基于 OpenHPC 项目发布的 [集群构建方法][16] 的系统。
这个集群由两台树莓派 3 系统作为计算节点，以及一台虚拟机作为主节点，结构示意如下：
![Map of HPC cluster](https://opensource.com/sites/default/files/u128651/hpc_with_pi-1.png "Map of HPC cluster")
@ -17,13 +16,12 @@
下图是真实的设备工作照：
![HPC hardware setup](https://opensource.com/sites/default/files/u128651/hpc_with_pi-2.jpg "HPC hardware setup")
去配置一台像上图这样的 HPC 系统，我是按照 OpenHPC 集群构建方法 ——  [CentOS 7.4/aarch64 + Warewulf + Slurm 安装指南][17] (PDF) 的一些步骤来做的。这个方法包括 [Warewulf][18] 提供的使用说明；因为我的那三个系统是手动安装的，我跳过了 Warewulf 部分以及创建 [Ansible playbook][19] 的一些步骤。
要把我的系统配置成像上图这样的 HPC 系统，我是按照 OpenHPC 的集群构建方法的 [CentOS 7.4/aarch64 + Warewulf + Slurm 安装指南][17] （PDF）的一些步骤来做的。这个方法包括了使用 [Warewulf][18] 的配置说明；因为我的那三个系统是手动安装的，我跳过了 Warewulf 部分以及创建 [Ansible 剧本][19] 的一些步骤。
在 [Ansible][26] 剧本中设置完成我的集群之后，我就可以向资源管理器提交作业了。在我的这个案例中， [Slurm][27] 充当了资源管理器，它是集群中的一个实例，由它来决定我的作业什么时候在哪里运行。在集群上启动一个简单的作业的方式之一：
在 [Ansible][26] playbooks 中设置完成我的集群之后，我就可以向资源管理器提交作业了。在我的这个案例中， [Slurm][27] 充当了资源管理器，它是集群中的一个实例，由它来决定我的作业什么时候在哪里运行。其中一种可做的事情是，在集群上启动一个简单的作业：
```
[ohpc@centos01 ~]$ srun hostname
calvin
@ -66,9 +64,9 @@ calvin
Mon 11 Dec 16:42:41 UTC 2017
```
为示范资源管理器的基本功能、简单的和一系列的命令行工具，这个集群系统是挺合适的，但是，去配置一个类似HPC 系统去做各种工作就有点无聊了。
为示范资源管理器的基本功能，简单的串行命令行工具就行，但是，做各种工作去配置一个类似 HPC 系统就有点无聊了。
一个更有趣的应用是在这个集群的所有可用 CPU 上运行一个 [Open MPI][20] 并行作业。我使用了一个基于 [Game of Life][21] 的应用，它被用于一个名为“使用 Red Hat 企业版 Linux 跨多种架构运行 `Game of Life`“的 [视频][22]。除了以前实现的基于 MPI 的 `Game of Life` 之外，在我的集群中现在运行的这个版本对每个涉及的主机的单元格颜色都是不同的。下面的脚本以图形输出的方式来交互式启动应用：
一个更有趣的应用是在这个集群的所有可用 CPU 上运行一个 [Open MPI][20] 的并行作业。我使用了一个基于 [康威生命游戏][21] 的应用，它被用于一个名为“使用 Red Hat 企业版 Linux 跨多种架构运行康威生命游戏”的 [视频][22]。除了以前基于 MPI 的 `Game of Life` 版本之外，在我的集群中现在运行的这个版本对每个涉及的主机的单元格颜色都是不同的。下面的脚本以图形输出的方式来交互式启动应用：
```
$ cat life.mpi
@ -91,15 +89,13 @@ $ srun -n 8 --x11 life.mpi
为了演示，这个作业有一个图形界面，它展示了当前计算的结果：
![](https://opensource.com/sites/default/files/u128651/hpc_with_pi-3.png)
红色单元格是由其中一个计算节点来计算的，而绿色单元格是由另外一个计算节点来计算的。我也可以让 `Game of Life` 程序为使用的每个 CPU 核心（这里的每个计算节点有四个核心）去生成不同的颜色，这样它的输出如下：
红色单元格是由其中一个计算节点来计算的，而绿色单元格是由另外一个计算节点来计算的。我也可以让康威生命游戏程序为使用的每个 CPU 核心（这里的每个计算节点有四个核心）去生成不同的颜色，这样它的输出如下：
![](https://opensource.com/sites/default/files/u128651/hpc_with_pi-4.png)
感谢 OpenHPC 提供的软件包和安装方法，因为它们我可以去配置一个由两个计算节点和一个主节点的 HPC 式的系统。我可以在资源管理器上提交作业，然后使用 OpenHPC 提供的软件在我的树莓派的 CPU 上去启动 MPI 应用程序。
感谢 OpenHPC 提供的软件包和安装方法，因为它们让我可以去配置一个由两个计算节点和一个主节点的 HPC 式的系统。我可以在资源管理器上提交作业，然后使用 OpenHPC 提供的软件在我的树莓派的 CPU 上去启动 MPI 应用程序。
* * *
@ -107,15 +103,15 @@ $ srun -n 8 --x11 life.mpi
### 关于作者
[![](https://opensource.com/sites/default/files/styles/profile_pictures/public/pictures/gotchi-square.png?itok=PJKu7LHn)][23] Adrian Reber —— Adrian 是 Red Hat 的高级软件工程师，他早在 2010 年就开始了迁移的过程，迁移到高性能计算环境中，从那个时候起迁移了许多的程序，并因此获得了博士学位，然后加入了 Red Hat 公司并开始去迁移到容器。偶尔他仍然去迁移单个进程，并且它至今仍然对高性能计算非常感兴趣。[关于我的更多信息点这里][12]
[![](https://opensource.com/sites/default/files/styles/profile_pictures/public/pictures/gotchi-square.png?itok=PJKu7LHn)][23] Adrian Reber —— Adrian 是 Red Hat 的高级软件工程师，他早在 2010 年就开始了迁移处理过程到高性能计算环境，从那个时候起迁移了许多的处理过程，并因此获得了博士学位，然后加入了 Red Hat 公司并开始去迁移到容器。偶尔他仍然去迁移单个处理过程，并且它至今仍然对高性能计算非常感兴趣。[关于我的更多信息点这里][12]
--------------------------------------------------------------------------------
via: https://opensource.com/article/18/1/how-build-hpc-system-raspberry-pi-and-openhpc
作者：[Adrian Reber ][a]
作者：[Adrian Reber][a]
译者：[qhwdw](https://github.com/qhwdw)
校对：[校对者ID](https://github.com/校对者ID)
校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

1
sources/tech/20100419 10 Tools To Add Some Spice To Your UNIX-Linux Shell Scripts.md
View File

@ -1,3 +1,4 @@
【Pgmalion666 Translating】
10 Tools To Add Some Spice To Your UNIX/Linux Shell Scripts
======
There are some misconceptions that shell scripts are only for a CLI environment. You can efficiently use various tools to write GUI and network (socket) scripts under KDE or Gnome desktops. Shell scripts can make use of some of the GUI widget (menus, warning boxes, progress bars, etc.). You can always control the final output, cursor position on the screen, various output effects, and more. With the following tools, you can build powerful, interactive, user-friendly UNIX / Linux bash shell scripts.

94
translated/tech/20140225 How To Safely Generate A Random Number - Quarrelsome.md
View File

@ -1,94 +0,0 @@
如何安全地生成随机数 - 争论
======
### 使用 urandom
使用 urandom。使用 urandom。使用 urandom。使用 urandom。使用 urandom。使用 urandom。
### 但对于密码学密钥呢？
仍然使用 urandom[6]。
### 为什么不是 SecureRandom, OpenSSL, havaged 或者 c 语言实现呢？
这些是用户空间的 CSPRNG(伪随机数生成器)。你应该想用内核的 CSPRNG，因为：
* 内核可以访问原始设备熵。
* 它保证不在应用程序之间共享相同的状态。
* 一个好的内核 CSPRNG，像 FreeBSD 中的，也可以保证在提供种子之前不给你随机数据。
研究过去十年中的随机失败案例，你会看到一连串的用户空间随机失败。[Debian 的 OpenSSH 崩溃][7]？用户空间随机。安卓的比特币钱包[重复 ECDSA k's][8]？用户空间随机。可预测洗牌的赌博网站？用户空间随机。
用户空间生成器几乎总是依赖于内核的生成器。即使它们不这样做，整个系统的安全性也会确保如此。**用户空间的 CSPRNG 不会增加防御深度;相反，它会产生两个单点故障。**
### 手册页不是说使用/dev/random嘛？
这个稍后详述，保留你的想法。你应该忽略掉手册页。不要使用 /dev/random。/dev/random 和 /dev/urandom 之间的区别是 Unix 设计缺陷。手册页不想承认这一点，因此它产生了一个并不存在的安全问题。把 random(4) 上的密码学上的建议当作传奇，继续你的生活。
### 但是如果我需要的是真随机值，而非伪随机值呢？
Urandom 和 /dev/random 提供的是同一类型的随机。与流行的观念相反，/dev/random 不提供“真正的随机”。从密码学上来说，你通常不需要“真正的随机”。
Urandom 和 /dev/random 都基于一个简单的想法。它们的设计与流密码的设计密切相关：一个小秘密被延伸到不可预测值的不确定流中。 这里的秘密是“熵”，而流是“输出”。
只在 Linux 上 /dev/random 和 urandom 仍然有意义上的不同。Linux 内核的 CSPRNG 定期进行密钥更新（通过收集更多的熵）。但是 /dev/random 也试图跟踪内核池中剩余的熵，并且如果它没有足够的剩余熵时，偶尔也会罢工。这种设计和我所说的一样蠢；这与基于“密钥流”中剩下多少“密钥”的 AES-CTR 设计类似。
如果你使用 /dev/random 而非 urandom，那么当 Linux 对自己的 RNG（随机数生成器）如何工作感到困惑时，你的程序将不可预测地（或者如果你是攻击者，非常可预测地）挂起。使用 /dev/random 会使你的程序不太稳定，但在密码学角度上它也不会让程序更加安全。
### 这里有个缺陷，不是吗？
不是，但存在一个你可能想要了解的 Linux 内核 bug,即使这并不能改变你应该使用哪一个 RNG。
在 Linux 上，如果你的软件在引导时立即运行，并且/或者刚刚安装了操作系统，那么你的代码可能会与 RNG 发生竞争。这很糟糕，因为如果你赢了比赛，那么你可能会在一段时间内从 urandom 获得可预测的输出。这是 Linux 中的一个 bug，如果你正在为 Linux 嵌入式设备构建平台级代码，那你需要了解它。
在 Linux 上，这确实是 urandom（而不是 /dev/random）的问题。这也是[Linux 内核中的错误][9]。 但它也容易在用户空间中修复：在引导时，明确地为 urandom 提供种子。长期以来，大多数 Linux 发行版都是这么做的。但不要切换到不同的 CSPRNG。
### 在其它操作系统上呢？
FreeBSD 和 OS X 消除了 urandom 和 /dev/random 之间的区别; 这两个设备的行为是相同的。不幸的是，手册页在解释为什么这样做上干的很糟糕，并延续了 Linux 上 urandom 可怕的神话。
无论你使用 /dev/random 还是 urandom，FreeBSD 的内核加密 RNG 都不会阻塞。 除非它没有被提供种子，在这种情况下，这两者都会阻塞。与 Linux 不同，这种行为是有道理的。Linux 应该采用它。但是，如果你是一名应用程序开发人员，这对你几乎没有什么影响：Linux，FreeBSD，iOS，无论什么：使用 urandom 吧。
### 太长了，懒得看
直接使用 urandom 吧。
### 结语
[ruby-trunk Feature #9569][10]
> 现在，在尝试检测 /dev/urandom 之前，SecureRandom.random_bytes 会尝试检测要使用的 OpenSSL。 我认为这应该反过来。在这两种情况下，你只需要将随机字节进行解压，所以 SecureRandom 可以跳过中间人（和第二个故障点），如果可用的话可以直接与 /dev/urandom 进行交互。
总结:
> /dev/urandom 不适合用来直接生成会话密钥和频繁生成其他应用程序级随机数据
>
> GNU/Linux 上的 random(4) 手册所述......
感谢 Matthew Green, Nate Lawson, Sean Devlin, Coda Hale, and Alex Balducci 阅读了本文草稿。公正警告：Matthew 只是大多同意我的观点。
--------------------------------------------------------------------------------
via: https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
作者：[Thomas;Erin;Matasano][a]
译者：[kimii](https://github.com/kimii)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://sockpuppet.org/blog
[1]:http://blog.cr.yp.to/20140205-entropy.html
[2]:http://cr.yp.to/talks/2011.09.28/slides.pdf
[3]:http://golang.org/src/pkg/crypto/rand/rand_unix.go
[4]:http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key
[5]:http://stackoverflow.com/a/5639631
[6]:https://twitter.com/bramcohen/status/206146075487240194
[7]:http://research.swtch.com/openssl
[8]:http://arstechnica.com/security/2013/08/google-confirms-critical-android-crypto-flaw-used-in-5700-bitcoin-heist/
[9]:https://factorable.net/weakkeys12.extended.pdf
[10]:https://bugs.ruby-lang.org/issues/9569