OpenWrt – Blame information for rev 1
?pathlinks?
Rev | Author | Line No. | Line |
---|---|---|---|
1 | office | 1 | if PACKAGE_libopenssl |
2 | |||
3 | comment "Build Options" |
||
4 | |||
5 | config OPENSSL_OPTIMIZE_SPEED |
||
6 | bool |
||
7 | default y if x86_64 || i386 |
||
8 | prompt "Enable optimization for speed instead of size" |
||
9 | select OPENSSL_WITH_ASM |
||
10 | help |
||
11 | Enabling this option increases code size (around 20%) and |
||
12 | performance. The increase in performance and size depends on the |
||
13 | target CPU. EC and AES seem to benefit the most, with EC speed |
||
14 | increased by 20%-50% (mipsel & x86). |
||
15 | AES-GCM is supposed to be 3x faster on x86. YMMV. |
||
16 | |||
17 | config OPENSSL_WITH_ASM |
||
18 | bool |
||
19 | default y if !SMALL_FLASH || !arm |
||
20 | prompt "Compile with optimized assembly code" |
||
21 | depends on !arc |
||
22 | help |
||
23 | Disabling this option will reduce code size and performance. |
||
24 | The increase in performance and size depends on the target |
||
25 | CPU and on the algorithms being optimized. As of 1.1.0i*: |
||
26 | |||
27 | Platform Pkg Inc. Algorithms where assembly is used - ~% Speed Increase |
||
28 | aarch64 174K BN, aes, sha1, sha256, sha512, nist256, poly1305 |
||
29 | arm 152K BN, aes, sha1, sha256, sha512, nist256, poly1305 |
||
30 | i386 183K BN+147%, aes+300%, rc4+55%, sha1+160%, sha256+114%, sha512+270%, nist256+282%, poly1305+292% |
||
31 | mipsel 1.5K BN+97%, aes+4%, sha1+94%, sha256+60% |
||
32 | mips64 3.7K BN, aes, sha1, sha256, sha512, poly1305 |
||
33 | powerpc 20K BN, aes, sha1, sha256, sha512, poly1305 |
||
34 | x86_64 228K BN+220%, aes+173%, rc4+38%, sha1+40%, sha256+64%, sha512+31%, nist256+354%, poly1305+228% |
||
35 | |||
36 | * Only most common algorithms shown. Your mileage may vary. |
||
37 | BN (bignum) performance was measured using RSA sign/verify. |
||
38 | |||
39 | config OPENSSL_WITH_SSE2 |
||
40 | bool |
||
41 | default y if !TARGET_x86_legacy && !TARGET_x86_geode |
||
42 | prompt "Enable use of x86 SSE2 instructions" |
||
43 | depends on OPENSSL_WITH_ASM && i386 |
||
44 | help |
||
45 | Use of SSE2 instructions greatly increase performance (up to |
||
46 | 3x faster) with a minimum (~0.2%, or 23KB) increase in package |
||
47 | size, but it will bring no benefit if your hardware does not |
||
48 | support them, such as Geode GX and LX. In this case you may |
||
49 | save 23KB by saying yes here. AMD Geode NX, and Intel |
||
50 | Pentium 4 and above support SSE2. |
||
51 | |||
52 | config OPENSSL_WITH_DEPRECATED |
||
53 | bool |
||
54 | default y |
||
55 | prompt "Include deprecated APIs (See help for a list of packages that need this)" |
||
56 | help |
||
57 | Since openssl 1.1.x is still new to openwrt, some packages |
||
58 | requiring this option do not list it as a requirement yet: |
||
59 | * freeswitch-stable, freeswitch, python, python3, squid. |
||
60 | |||
61 | config OPENSSL_NO_DEPRECATED |
||
62 | bool |
||
63 | default !OPENSSL_WITH_DEPRECATED |
||
64 | |||
65 | config OPENSSL_WITH_ERROR_MESSAGES |
||
66 | bool |
||
67 | default y if !SMALL_FLASH && !LOW_MEMORY_FOOTPRINT |
||
68 | prompt "Include error messages" |
||
69 | help |
||
70 | This option aids debugging, but increases package size and |
||
71 | memory usage. |
||
72 | |||
73 | comment "Protocol Support" |
||
74 | |||
75 | config OPENSSL_WITH_TLS13 |
||
76 | bool |
||
77 | default y |
||
78 | prompt "Enable support for TLS 1.3" |
||
79 | select OPENSSL_WITH_EC |
||
80 | help |
||
81 | TLS 1.3 is the newest version of the TLS specification. |
||
82 | It aims: |
||
83 | * to increase the overall security of the protocol, |
||
84 | removing outdated algorithms, and encrypting more of the |
||
85 | protocol; |
||
86 | * to increase performance by reducing the number of round-trips |
||
87 | when performing a full handshake. |
||
88 | It increases package size by ~4KB. |
||
89 | |||
90 | config OPENSSL_WITH_DTLS |
||
91 | bool |
||
92 | prompt "Enable DTLS support" |
||
93 | help |
||
94 | Datagram Transport Layer Security (DTLS) provides TLS-like security |
||
95 | for datagram-based (UDP, DCCP, CAPWAP, SCTP & SRTP) applications. |
||
96 | |||
97 | config OPENSSL_WITH_NPN |
||
98 | bool |
||
99 | default y |
||
100 | prompt "Enable NPN support" |
||
101 | help |
||
102 | NPN is a TLS extension, obsoleted and replaced with ALPN, |
||
103 | used to negotiate SPDY, and HTTP/2. |
||
104 | |||
105 | config OPENSSL_WITH_SRP |
||
106 | bool |
||
107 | default y |
||
108 | prompt "Enable SRP support" |
||
109 | help |
||
110 | The Secure Remote Password protocol (SRP) is an augmented |
||
111 | password-authenticated key agreement (PAKE) protocol, specifically |
||
112 | designed to work around existing patents. |
||
113 | |||
114 | config OPENSSL_WITH_CMS |
||
115 | bool |
||
116 | default y |
||
117 | prompt "Enable CMS (RFC 5652) support" |
||
118 | help |
||
119 | Cryptographic Message Syntax (CMS) is used to digitally sign, |
||
120 | digest, authenticate, or encrypt arbitrary message content. |
||
121 | |||
122 | comment "Algorithm Selection" |
||
123 | |||
124 | config OPENSSL_WITH_EC |
||
125 | bool |
||
126 | default y |
||
127 | prompt "Enable elliptic curve support" |
||
128 | help |
||
129 | Elliptic-curve cryptography (ECC) is an approach to public-key |
||
130 | cryptography based on the algebraic structure of elliptic curves |
||
131 | over finite fields. ECC requires smaller keys compared to non-ECC |
||
132 | cryptography to provide equivalent security. |
||
133 | |||
134 | config OPENSSL_WITH_EC2M |
||
135 | bool |
||
136 | depends on OPENSSL_WITH_EC |
||
137 | prompt "Enable ec2m support" |
||
138 | help |
||
139 | This option enables the more efficient, yet less common, binary |
||
140 | field elliptic curves. |
||
141 | |||
142 | config OPENSSL_WITH_CHACHA_POLY1305 |
||
143 | bool |
||
144 | default y |
||
145 | prompt "Enable ChaCha20-Poly1305 ciphersuite support" |
||
146 | help |
||
147 | ChaCha20-Poly1305 is an AEAD ciphersuite with 256-bit keys, |
||
148 | combining ChaCha stream cipher with Poly1305 MAC. |
||
149 | It is 3x faster than AES, when not using a CPU with AES-specific |
||
150 | instructions, as is the case of most embedded devices. |
||
151 | |||
152 | config OPENSSL_PREFER_CHACHA_OVER_GCM |
||
153 | bool |
||
154 | default y if !x86_64 && !aarch64 |
||
155 | prompt "Prefer ChaCha20-Poly1305 over AES-GCM by default" |
||
156 | depends on OPENSSL_WITH_CHACHA_POLY1305 |
||
157 | help |
||
158 | The default openssl preference is for AES-GCM before ChaCha, but |
||
159 | that takes into account AES-NI capable chips. It is not the |
||
160 | case with most embedded chips, so it may be better to invert |
||
161 | that preference. This is just for the default case. The |
||
162 | application can always override this. |
||
163 | |||
164 | config OPENSSL_WITH_PSK |
||
165 | bool |
||
166 | default y |
||
167 | prompt "Enable PSK support" |
||
168 | help |
||
169 | Build support for Pre-Shared Key based cipher suites. |
||
170 | |||
171 | comment "Less commonly used build options" |
||
172 | |||
173 | config OPENSSL_WITH_ARIA |
||
174 | bool |
||
175 | prompt "Enable ARIA support" |
||
176 | help |
||
177 | ARIA is a block cipher developed in South Korea, based on AES. |
||
178 | |||
179 | config OPENSSL_WITH_CAMELLIA |
||
180 | bool |
||
181 | prompt "Enable Camellia cipher support" |
||
182 | help |
||
183 | Camellia is a bock cipher with security levels and processing |
||
184 | abilities comparable to AES. |
||
185 | |||
186 | config OPENSSL_WITH_IDEA |
||
187 | bool |
||
188 | prompt "Enable IDEA cipher support" |
||
189 | help |
||
190 | IDEA is a block cipher with 128-bit keys. |
||
191 | |||
192 | config OPENSSL_WITH_SEED |
||
193 | bool |
||
194 | prompt "Enable SEED cipher support" |
||
195 | help |
||
196 | SEED is a block cipher with 128-bit keys broadly used in |
||
197 | South Korea, but seldom found elsewhere. |
||
198 | |||
199 | config OPENSSL_WITH_SM234 |
||
200 | bool |
||
201 | prompt "Enable SM2/3/4 algorithms support" |
||
202 | help |
||
203 | These algorithms are a set of "Commercial Cryptography" |
||
204 | algorithms approved for use in China. |
||
205 | * SM2 is an EC algorithm equivalent to ECDSA P-256 |
||
206 | * SM3 is a hash function equivalent to SHA-256 |
||
207 | * SM4 is a 128-block cipher equivalent to AES-128 |
||
208 | |||
209 | config OPENSSL_WITH_BLAKE2 |
||
210 | bool |
||
211 | prompt "Enable BLAKE2 digest support" |
||
212 | help |
||
213 | BLAKE2 is a cryptographic hash function based on the ChaCha |
||
214 | stream cipher. |
||
215 | |||
216 | config OPENSSL_WITH_MDC2 |
||
217 | bool |
||
218 | prompt "Enable MDC2 digest support" |
||
219 | |||
220 | config OPENSSL_WITH_WHIRLPOOL |
||
221 | bool |
||
222 | prompt "Enable Whirlpool digest support" |
||
223 | |||
224 | config OPENSSL_WITH_COMPRESSION |
||
225 | bool |
||
226 | prompt "Enable compression support" |
||
227 | help |
||
228 | TLS compression is not recommended, as it is deemed insecure. |
||
229 | The CRIME attack exploits this weakness. |
||
230 | Even with this option turned on, it is disabled by default, and the |
||
231 | application must explicitly turn it on. |
||
232 | |||
233 | config OPENSSL_WITH_RFC3779 |
||
234 | bool |
||
235 | prompt "Enable RFC3779 support (BGP)" |
||
236 | help |
||
237 | RFC 3779 defines two X.509 v3 certificate extensions. The first |
||
238 | binds a list of IP address blocks, or prefixes, to the subject of a |
||
239 | certificate. The second binds a list of autonomous system |
||
240 | identifiers to the subject of a certificate. These extensions may be |
||
241 | used to convey the authorization of the subject to use the IP |
||
242 | addresses and autonomous system identifiers contained in the |
||
243 | extensions. |
||
244 | |||
245 | comment "Engine/Hardware Support" |
||
246 | |||
247 | config OPENSSL_ENGINE |
||
248 | bool "Enable engine support" |
||
249 | help |
||
250 | This enables alternative cryptography implementations, |
||
251 | most commonly for interfacing with external crypto devices, |
||
252 | or supporting new/alternative ciphers and digests. |
||
253 | Note that you need to enable KERNEL_AIO to be able to build the |
||
254 | afalg engine package. |
||
255 | |||
256 | config OPENSSL_ENGINE_CRYPTO |
||
257 | bool |
||
258 | select OPENSSL_ENGINE |
||
259 | select PACKAGE_kmod-cryptodev |
||
260 | select PACKAGE_libopenssl-conf |
||
261 | prompt "Acceleration support through /dev/crypto" |
||
262 | help |
||
263 | This enables use of hardware acceleration through OpenBSD |
||
264 | Cryptodev API (/dev/crypto) interface. |
||
265 | You must install kmod-cryptodev (under Kernel modules, Cryptographic |
||
266 | API modules) for /dev/crypto to show up and use hardware |
||
267 | acceleration; otherwise it falls back to software. |
||
268 | |||
269 | config OPENSSL_WITH_ASYNC |
||
270 | bool |
||
271 | prompt "Enable asynchronous jobs support" |
||
272 | depends on OPENSSL_ENGINE && USE_GLIBC |
||
273 | help |
||
274 | Enables async-aware applications to be able to use OpenSSL to |
||
275 | initiate crypto operations asynchronously. In order to work |
||
276 | this will require the presence of an async capable engine. |
||
277 | |||
278 | config OPENSSL_WITH_GOST |
||
279 | bool |
||
280 | prompt "Prepare library for GOST engine" |
||
281 | depends on OPENSSL_ENGINE |
||
282 | help |
||
283 | This option prepares the library to accept engine support |
||
284 | for Russian GOST crypto algorithms. |
||
285 | The gost engine is not included in standard openwrt feeds. |
||
286 | To build such engine yourself, see: |
||
287 | https://github.com/gost-engine/engine |
||
288 | |||
289 | endif |