This may have seemed like a great idea in 2013, but the repeated "set/clear bits", a.k.a. clamping phases at each level of the hierarchy slowly subtract key strength.
Don't use this as described. Check out Ristretto.
Semi-private keys are an expansion of the traditional idea
| #![feature(stdsimd)] | |
| // Based on the following C intrinsics implementation: | |
| // <https://github.com/noloader/AES-Intrinsics/blob/master/aes-arm.c> | |
| // | |
| // Original C written and placed in public domain by Jeffrey Walton. | |
| // Based on code from ARM, and by Johannes Schneiders, Skip Hovsmith and | |
| // Barry O'Rourke for the mbedTLS project. | |
| use core::arch::aarch64::*; |
Originally from: http://catless.ncl.ac.uk/Risks/4.73.html#subj10.1
Jordan K. Hubbard jkh@violet.Berkeley.EDU
Thu, 2 Apr 87 10:45:46 PST
[The following message was submitted to RISKS by 6 different people.
I initially thought it might already have been widely circulated, but
its repeated receipt has led me to include it here anyway. PGN]
By now, many of you have heard of (or seen) the broadcast message I sent to
| $ openssl version | |
| OpenSSL 1.1.1k 25 Mar 2021 | |
| $ openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -pkeyopt ec_param_enc:named_curve -out p256.pem | |
| $ openssl asn1parse -in p256.pem | |
| 0:d=0 hl=3 l= 135 cons: SEQUENCE | |
| 3:d=1 hl=2 l= 1 prim: INTEGER :00 | |
| 6:d=1 hl=2 l= 19 cons: SEQUENCE | |
| 8:d=2 hl=2 l= 7 prim: OBJECT :id-ecPublicKey | |
| 17:d=2 hl=2 l= 8 prim: OBJECT :prime256v1 | |
| 27:d=1 hl=2 l= 109 prim: OCTET STRING [HEX DUMP]:306B02010104208225980620669F554FB548DA7AEA8AD04307E06F4F6E27BD75D96FC069A474B3A14403420004C48CA8CF3F38BA757E0D7FB2D961C3A1914A5783DE0748BE4024E3052AA804C4232BEB7AEB6E3503F487CB5F50EBDE03AF002E0318CF2F897BA983A74B016AA3 |
The Warner-Portman-Sinema amendment to the forthcoming Bipartisan Infrastructure Framework stipulates that systems with the following property are exempt from compliance obligations:
validating distributed ledger transactions through proof of work (mining)
By default, systems which use consensus based on Proof-of-Stake (PoS) leader election mechanisms do not include a "proof of work (mining)" mechanism. To potentially comply with the proposed legislation, it would be possible to augment Proof-of-Stake consensus with a Proof-of-Work (PoW) mechanism to meet the verbeage in the amendment.
The following is a description of a minimal Proof-of-Work mechanism, inspired by the one used by Bitcoin.
| #!/usr/bin/env ruby | |
| require 'openssl' | |
| # AES-128 ECB mode test vectors | |
| # Taken from: http://www.inconteam.com/software-development/41-encryption/55-aes-test-vectors#aes-ecb-128 | |
| KEY = ["2b7e151628aed2a6abf7158809cf4f3c"].pack("H*") | |
| PLAINTEXT = ["6bc1bee22e409f96e93d7e117393172a"].pack("H*") | |
| CIPHERTEXT = ["3ad77bb40d7a3660a89ecaf32466ef97"].pack("H*") |
| #![feature(stdsimd)] | |
| // Based on the following C intrinsics implementation: | |
| // <https://github.com/noloader/SHA-Intrinsics/blob/master/sha256-arm.c> | |
| // | |
| // Original C written and placed in public domain by Jeffrey Walton. | |
| // Based on code from ARM, and by Johannes Schneiders, Skip Hovsmith and | |
| // Barry O'Rourke for the mbedTLS project. | |
| use core::arch::aarch64::*; |
| use_bpm 128 | |
| live_loop :kick do | |
| sample :bd_808, amp: 10 | |
| sleep 1 | |
| end | |
| live_loop :snare do | |
| sleep 1 | |
| sample :drum_snare_soft |
| Date: 17 Aug 2013 00:24:45 -0000 | |
| From: "D. J. Bernstein" <djb@cr.yp.to> | |
| To: cryptography@randombit.net | |
| Subject: Re: [cryptography] urandom vs random | |
| Aaron Toponce writes: | |
| > Cryptographers don't like the idea that it's possible, even if it's | |
| > excessively remote, and highly unprobable. This is why you see suggestions | |
| > to use /dev/random for long term SSH, SSL and OpenPGP keys. |