ea83cc0ad0
One of the disadvantages of x25519 and ℘256 is it only provides 126 bits of security, so that seems like a weak link in the chain, if we're using ECDHE-ECDSA-AES256-GCM-SHA384. The U.S. government wants classified data to be encrypted using a curve at least as strong as ℘384, which provides 192 bits of security, but if you read the consensus of stack exchange it would give you the impression that ℘384 is three times slower. This change (as well as the previous one) makes ℘384 three times as fast by tuning its modulus and multiplication subroutines with new tests that should convincingly show: the optimized code behaves the same way as the old code. Some of the diff noise from the previous change is now removed too, so that our vendored fork can be more easily compared with upstream sources. So you can now have stronger cryptography without compromises. ℘384 modulus Justine l: 28𝑐 9𝑛𝑠 ℘384 modulus MbedTLS NIST l: 127𝑐 41𝑛𝑠 ℘384 modulus MbedTLS MPI l: 1,850𝑐 597𝑛𝑠 The benchmarks above show the improvements made by secp384r1() which is an important function since it needs to be called 13,000 times whenever someone establishes a connection to your web server. The same's true of Mul6x6Adx() which is able to multiply 384-bit numbers in 73 cycles, but only if your CPU was purchased after 2014 when Broadwell was introduced |
||
|---|---|---|
| .. | ||
| alg | ||
| bits | ||
| calls | ||
| crt | ||
| dns | ||
| elf | ||
| fmt | ||
| integral | ||
| intrin | ||
| isystem | ||
| linux | ||
| log | ||
| mem | ||
| nexgen32e | ||
| nt | ||
| ohmyplus | ||
| rand | ||
| runtime | ||
| sock | ||
| stdio | ||
| str | ||
| stubs | ||
| sysv | ||
| testlib | ||
| time | ||
| tinymath | ||
| unicode | ||
| x | ||
| zipos | ||
| assert.h | ||
| complex.h | ||
| dce.h | ||
| disclaimer.inc | ||
| dos.h | ||
| errno.h | ||
| inttypes.h | ||
| libc.mk | ||
| limits.h | ||
| literal.h | ||
| mach.h | ||
| macho.internal.h | ||
| macros-cpp.internal.inc | ||
| macros.internal.h | ||
| macros.internal.inc | ||
| math.h | ||
| notice.inc | ||
| notice.internal.h | ||
| paths.h | ||
| README.md | ||
| zip.h | ||
SYNOPSIS
Cosmopolitan Standard Library.
OVERVIEW
This directory defines static archives defining functions, like printf(), mmap(), win32, etc. Please note that the Cosmopolitan build configuration doesn't link any C/C++ library dependencies by default, so you still have the flexibility to choose the one provided by your system. If you'd prefer Cosmopolitan, just add $(LIBC) and $(CRT) to your linker arguments.
Your library is compromised of many bite-sized static archives. We use the checkdeps tool to guarantee that the contents of the archives are organized in a logical way that's easy to use with or without our makefile infrastructure, since there's no cyclic dependencies.
The Cosmopolitan Library exports only the most stable canonical system calls for all supported operating systems, regardless of which platform is used for compilation. We polyfill many of the APIs, e.g. read(), write() so they work consistently everywhere while other apis, e.g. CreateWindowEx(), might only work on one platform, in which case they become no-op functions on others.
Cosmopolitan polyfill wrappers will usually use the dollar sign naming convention, so they may be bypassed when necessary. This same convention is used when multiple implementations of string library and other performance-critical function are provided to allow Cosmopolitan to go fast on both old and newer computers.
We take an approach to configuration that relies heavily on the compiler's dead code elimination pass (libc/dce.h). Most of the code is written so that, for example, folks not wanting support for OpenBSD can flip a bit in SUPPORT_VECTOR and that code will be omitted from the build. The same is true for builds that are tuned using -march=native which effectively asks the library to not include runtime support hooks for x86 processors older than what you use.
Please note that, unlike Cygwin or MinGW, Cosmopolitan does not achieve broad support by bolting on a POSIX emulation layer. We do nothing more than (in most cases) stateless API translations that get you 90% of the way there in a fast lightweight manner. We therefore can't address some of the subtle differences, such as the nuances of absolute paths on Windows. Our approach could be compared to something more along the lines of, "the Russians just used a pencil to write in space", versus spending millions researching a pen like NASA.