ECDSA - Bitcoin

OpenSSL / Bitcoin implementation of ECDSA Flaw discovered

submitted by twowordz to Bitcoin [link] [comments]

OpenSSL / Bitcoin implementation of ECDSA Flaw discovered

OpenSSL / Bitcoin implementation of ECDSA Flaw discovered submitted by jscinoz to Bitcoin [link] [comments]

Creating a public key from a private key using secp256k1 library in C++

Hello,
I'm trying to generate a public key from a private one using the bitcoin library secp256k1 https://github.com/bitcoin-core/secp256k1 in C++:

 // private key std::string privateKey = "baca891f5f0285e043496843d82341d15533f016c223d114e1e4dfd39e60ecb0"; const char* cPrivateKey = privateKey.c_str(); // creating public key from it secp256k1_context *signingContext = secp256k1_context_create(SECP256K1_CONTEXT_SIGN); secp256k1_pubkey pkey; unsigned char *seckey = (unsigned char*) malloc(privateKey.size() * sizeof(unsigned char)); std::copy(cPrivateKey, cPrivateKey + privateKey.size(), seckey); if (secp256k1_ec_pubkey_create(signingContext, &pkey, seckey) == 0) throw "Creation error"; // print the result in hex std::stringstream ss; for (int i = 0; i < 64; ++i) { ss << std::setw(2) << std::hex << (0xff & (unsigned int)pkey.data[i]); } std::cout << ss.str() << std::endl; // parsing the result std::string pkey_data = ss.str(); secp256k1_context *noneContext = secp256k1_context_create(SECP256K1_CONTEXT_NONE); secp256k1_pubkey pubkey; if (secp256k1_ec_pubkey_parse(noneContext, &pubkey, pkey.data, 64) == 0) std::cout << "Couldnt parse using pkey.data" << std::endl; if (secp256k1_ec_pubkey_parse(noneContext, &pubkey, pkay_data, pkey_data.size()) == 0) std::cout << "Couldnt parse using hex public key " << std::endl; 
The output:
1b9e55408c5141414e8337adef57ead18f62444fdf5f8c897d0dc812696a6141a919254d3e750075a2a9ba32dc4ed30c84e65f27e431b59b94a2aafe3e80a974 Couldnt parse using pkey.data Couldnt parse using hex public key 
The idea is to parse the public key from the generated one to see if it is really correct. Also, i tried using openssl with the same private key and i get a different public key from the private one using ecdsa secp256k1.. Any help or example on how to use the library in C++ is more than welcome.
Thank you
submitted by chizisch to Bitcoin [link] [comments]

After 6 years of community pressure, RedHat legal approves Elliptical Curve algorithms to be enabled in distributed packages. This makes compiling Bitcoin related software much easier!

submitted by AgentZeroM to Bitcoin [link] [comments]

Anatomy of crypto data destruction and RNG

Ever since the post-credits scene in season 2, I've been thinking about how the stage 1 "payload" that encrypted all of the E-Corp systems might have been built, and how it might be flawed enough to permit data recovery. No sci-fi time-travel magic required for this theory.
We never get a direct look at the malware, but we do get a smattering of references to what it is throughout the episodes so far. Not enough to get a totally clear picture, but it's somewhere to start with educated guesses.
In S01E01, Mr. Robot is explicit about the aims:
If we hit their data center just right, we could systematically format all the servers, including backup. It would be impossible to enforce outdated paper records. It would all be gone.
Okay. They want to irreversibly delete the data on all of E-Corp's servers and backups.
In S01E02, when tasking Elliot with blowing up the Comet electric natural gas plant to take out the tape backups at Steel Mountain, Mr. Robot elaborates:
Once we blow up the pipeline, Darlene's worm will kick into high gear at the US datacenter, which you helped us to install. Thank you very much. The redundant backups at their eastern datacenter in China? The dark army is covering us on that.
Okay, we've learned the way they'll do it is with a worm, which Darlene wrote. A worm is malware that is designed to replicate itself and carry a payload.
In S01E08, after successfully entering the work order to remove the honeypot around CS30, Elliot states:
In 43 hours, exactly, our server will no longer be a honeypot, and that rootkit you wrote will take down Evil Corp. We did it Darlene. It's going to happen.
Despite what Lloyd might have said, rootkits are not serial rapists with very big dicks. They're malicious code designed to hide the presence of an attacker (inc. processes they might be running, alterations to system login and authentication modes to accept a backdoor credential) and their tools on a system once it has been compromised. Unqualified, the term "rootkit" commonly refers to kernel-mode rootkits, which operate directly within the context of the operating system, and frequently loaded through the same facilities provided for installing new device drivers. They can hide files/directories, running processes, network connections, and themselves (e.g. in the list of loaded drivers) from scanning entities on the same system. One way to detect a rootkit is to look for discrepancies between what tools on the system report (e.g. in terms of active network connections) versus what is observed externally (e.g. on a network monitoring device).
That makes the discussion of "honeypots" a little bit strange. A honeypot usually refers to a target on a network that's designed to be enticing to attackers, so that they try to hack it, but isn't "real" in the sense that it processes real data. It might be instrumented such that probing and reconnaissance activities targeting the honeypot are tied to network hacking alerts.
I can think of one of three interpretations of what turning server cs30 into a honeypot might mean:
  1. They've installed additional monitoring software on cs30.
  2. They've replaced cs30 with a totally different system that looks like cs30 to an outsider.
  3. They've installed additional network monitoring around cs30.
But none of these interpretations really make sense. If it's #1, if the rootkit was written properly, it's likely that additional monitoring would be fruitless, and the attack could be carried out without the whole Whiterose meeting riddles.
If it's #2, then the rootkit would probably not have been copied over to the clone, and fscociety would have noticed their server misbehaving. Unless, of course, E-Corp discovers the rootkit on cs30 as part of this process, in which case, they could have just cleaned it up, and closed off fsociety access to the internal server.
If it's #3, then the periodic use of the backdoored access to cs30 by fsociety should have been noticed by looking at that network monitoring data, likewise leading to a server cleanup and removal of the backdoor.
I'll chalk this up to somewhat cavalier and imprecise use of technical terminology by a TV show, and press on.
What have we learned so far?
In S01E09, after Tyrell coerces Elliot into showing him the fsociety arcade:
Tyrell: What is it that you're doing exactly?
Elliot: Encrypting all the files. All of Evil-Corp's financial records will be impossible to access. The encryption key will self-delete after the process completes.
Wait a second? Encryption? Encryption key? I thought we were after data deletion.
Of course, there's a perfectly plausible explanation: deleting data takes time. If you go around rm -rf'ing servers, there's a good chance that recoverable data will be scattered around those hosts. By performing bulk encryption, you overwrite all data on the target systems once, can still permit access to everything on the system while the encryption is occurring, and then destroy the key once the encryption process is completed. This lowers the length of the window in which someone can realize that something has gone terribly wrong. The key is small (tens of bytes, not to gigabytes or hundreds of gigabytes), and can be deleted almost instantaneously.
Several full disk encryption systems, including FileVault in macOS, and the now-defunct TrueCrypt have the ability to do this: you start encrypting the drive, but can continue working while the data is read, encrypted, and overwritten unnoticed in the background.
Some ransomware strains also follow this practice, so it's not an unreasonable approach. However, cryptography is a loaded foot cannon for the unwary, and it's surprisingly easy to make a small mistake that unravels the whole thing.
In S01E10, as Elliot looks for Tyrell at the E-Corp building, in voice-over he says:
A simple program: a worm that can make data unreadable. Malware that took Darlene maybe 2 hours to code. Is that all it takes to kill the world?
And follows with:
I wonder what stage they're at. Denial? Muttering to themselves "no, this can be fixed." Maybe bargaining? Forcing their techs to work overtime to try to decrypt our data. Or have they come to the realization yet that Darlene encrypted everything with 256-bit AES, and it would take an incomprehensible amount of time to crack? That all of their data is actually gone, for good.
AES is a symmetric encryption algorithm in wide use. It's stood the test of time since its standardization in 2000, and lots of people trying to find weaknesses in the last 2 decades. At a 256-bit key length, it would take many multiples of lifetimes of the universe to break, at least so long as computers are still made out of atoms. A quantum computer would not meaningfully assist in this kind of attack, as Grover's algorithm would still require 2128 quantum operations, and this is still going to take many multiplies of lifetimes of the universe to break.
But it does raise questions about cryptographic hygiene. Mechanically: what mode of operation is AES being used in to encrypt files? Let's assume Darlene has heard of the ECB penguin and has picked something better like CBC with per-file random initialization vectors.
More importantly: where is that key coming from? The right answer is to read it from a operating system provided cryptographically secure random number generator like /dev/urandom on UNIX-like systems, or the equivalent on Microsoft Windows CryptGenRandom. Ideally, perform this random key generation process individually (resulting in unique keys) on every single target system. There have been cases where CryptGenRandom has produced sub-par quality randomness on earlier versions of Windows, but not since Windows XP SP2 or older.
My theory is that this is where the fsociety worm went wrong.
In S02E01, we see the night of the hack for the first time, and in the terminal we see:
[email protected]:~# ssh -l root bkuw300ps345672-cs30.serverfarm.evil-corp-usa.com [email protected] password: The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usshare/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Thu May 8 16:26:57 2015 from cs30.serverfarm.evil-corp-usa.com [email protected]:~# cd /opt/2/task/2/fd1nfo/fsociety/hscripts/ [email protected]:/opt/2/task/2/fd1nfo/fsociety/hscripts# ls fuxsocy.py loadmod.py rootkitctrl sniff-out.pcap kernel_modules nuke.py sn1ff worm.py [email protected]:/opt/2/task/2/fd1nfo/fsociety/hscripts# ./fuxsocy.py 
And then:
Executing FuxSocy Loading Source of Entropy ####################### COMPLETE Generating Keys ####################### COMPLETE Locating target files. beginning crypto operations Encrypting /bin Encrypting /boot Encrypting /dev Encrypting /etc 
"Loading Source of Entropy" you say? That sounds awfully like a userspace random number generator. If the entropy pool is too small, or if the random number generation process is otherwise flawed, the key fed into the AES encryption process might be much more predictable than the 256-bit key length would suggest.
There was a major incident of this type discovered in 2006, where the Debian GNU/Linux package maintainers for OpenSSL (a popular, and widely used, though terrible) cryptography library commented out some lines that were generating code safety warnings when packaging it for the Debian distribution. Turns out these lines were essential to introducing any kind of real randomness for uses by the library, and this includes key generation and certain signing operations.
The fallout was that the affected versions of OpenSSL on Debian GNU/Linux would only generate 32,768 or 214 distinct keys. This also affected things like ECDSA signing, which was mirrored in 2013 when a similar vulnerability in Android led to the theft of about 56 Bitcoins.
You would have to know how the flawed key generation was implemented, and it would not necessarily be obvious looking at the keys from the outside, but if there was a flaw of this magnitude, you could break that "256-bit" key almost instantly with e.g. 14-bits of effort.
The use of Debian on the E-Corp servers might be a suggestive hint to this historical fiasco too.
The screen output also suggests that there might have been a single key generated at the start of the process that was copied as part of the data destruction payload to all of the E-Corp servers. Not ideal from a cryptographic hygiene standpoint.
In the post-credits scene of S02E12, Trenton and Mobley discuss:
Trenton: Have you given any more thought to what I said?
Mobley: I don't want to discuss this.
Trenton: Mobley...
Mobley: Fredrick.
Trenton: Seriously, Fredrick, what if we could? This might work.
Mobley: And also, it might not. I've taken enough risks for one lifetime, I don't want to discuss it anymore.
Trenton: But what if we could generate the keys...
Mobley: Tanya... will you just please shut up?
Trenton: What? This is important. We need to talk about it.
...
Trenton: Please, just look at it.
Mobley: Okay, so what? Say I did. Then what?
Trenton: If what I discovered is real, do you know what that means?
Mobley: Yeah, I know exactly what it means.
Trenton: Yeah, it means we could potentially undo this whole thing. Put everything back the way it was.
Mobley: I know. I know.
Trenton: Please. Just look at what I found.
I bet they've looked over the fsociety data destruction payload code and discovered a way to reproduce the key, precisely because there's this kind of flaw in it.
Finally, during Tyrell's AMA, a.k.a. S03E03, we get another shot of stage 1 running:
Thread #7 - 233 hosts online, initiating SCP transfer Waiting on thread updates ... Thread #2 - SCP complete. launched encryption tasks Thread #6 - SCP complete. launched encryption tasks Waiting on thread updates Thread #2 - Encryption tasks completed & verified Updating process log Thread #2 - Obtaining next hosts ... read 256 addresses Waiting on thread updates Thread #6 - SCP complete. launched encryption tasks Waiting on thread updates Thread #2 - Starting tasks on 10.0.0.29/24 
I interpret this as cs30 copying (via SCP) the data destruction payload to every server on the E-Corp network. The 10.0.0.0/8 IP addresses are designated internal network addresses, and are common for large internal business networks. It's odd that E-Corp would have a totally flat network, and also odd that cs30 itself seems to be copying the payload everywhere (not very worm-like), but perhaps this is just artistic license from the VFX guys.
Given how little we see of this screen, and how it was effective at wiping out E-Corp, I think it's safe to assume that the payload being transferred over SCP is both a propagator (i.e. the worm) and a data destruction payload, which would also address it spreading over the entire E-Corp network, even if it isn't flat. It is still suggestive of the single-key possibility though.
So, did Darlene fuck up the crypto? I think so. There's a few more suggestive quotes.
In S01E06, after dropping USB flash drives in the police parking lot for Elliot, the malware is blocked by antivirus.
Elliot: Did you write that exploit yourself?
Darlene: I had an hour.
Elliot: So what? You just pulled code from Rapid9 or some shit? Since when did you become a script kiddie?
Darlene: I repeat: I had an hour.
We learn that Darlene can be sloppy when doing things quickly, and re-iterating Elliot's voice-over in S01E10:
Malware that took Darlene maybe 2 hours to code.
And another off-hand remark in S01E08:
Elliot: How'd it go with the climate control hack?
Darlene: Handled. I happen to be really smart and good at things. Not like you give a shit.
There's a lot of ways that subtle faults in a cryptographic implementation can lead to the entire system coming tumbling down. Darlene might be an expert malware coder, but that's not a universal skill that necessarily translates over to other aspects of information security.
If you're curious about not falling into "bad noob practices" with crypto, there's a great set of cryptography building and breaking challenges that don't require much more than basic algebra, statistics, and coding skills.
Wildly speculating now:
submitted by DrElectolight to MrRobot [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2016-01-28)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last summarisation
Disclaimer
Please bear in mind I'm not a developer so some things might be incorrect or plain wrong. There are no decisions being made in these meetings, but since a fair amount of devs are present it's a good representation. Copyright: Public domain

Logs

Main topics

Short topics

ajtowns has written some functional test scripts for OP_CSV which will be helpful for testing #7184(BIP 68) and #6564(BIP 112)

Refactoring window

background

jtimon asks when exactly this is and what it entails. Refactoring is moving code around to specific libraries or files to make things easier to read and to safely change parts of the code without affecting other parts. Mainly these will be moves to facilitate libconsensus, the part that will hold all the consensus-critical code.

meeting comments

Wumpus is fine with starting to merge moveonly stuff. The refactors might interfere with segregated witness, however waiting for it might cause the refactor window for 0.13 to be missed.

meeting conclusion

Refactor window is from now till -undecided- Review #7091, #7287, #7310 and #7311

outstanding issues for 0.12.0

background

Bitcoin Core 0.12 is scheduled for release around February and introduces a lot of fixes and improvements. (release notes) There's a release candidate 0.12rc2 available at https://bitcoin.org/bin/bitcoin-core-0.12.0/test/

meeting comments

We need to sign the win32 release with a new key for win7+ as the current key uses sha-1 which is broken. There's still some controversy how the changes for priority should be noted in the release notes. e.g. #7346 gmaxwell points out we never did anything about the issues with localhost being whitelisted which might cause issues with the new automatic hidden service creation. This issue was raised in the 2015/12/03 meeting

meeting conclusion

There will be a new key, if it takes too long to get it someone else can sign it this time. gmaxwell will change #7082 to only remove the privledging of localhost. The rest of the PR can be done for 12.1/0.13

how does this new "critical" OpenSSL release affect us

background

There's a new openSSL release which fixes some security issues. https://mta.openssl.org/pipermail/openssl-announce/2016-January/000061.html Question is if and how this affects bitcoin. Since 0.12 bitcoin-core uses their own libsecp256k1 for ECDSA signature verification instead of openSSL.

meeting comments

BIP70 (Payment Protocol) might be affected. The parts of core that still depend on openSSL are entropy, AES (wallet) and BIP70. There's a plan to replace openSSL for entropy with fortuna (build by sipa and gmaxwell), which needs to be build into a separate library. There are many complications in making a safe random number generator, first among them is fork detection (fork= a unix operation which duplicates the entire process state which will lead to reuse of random numbers) Wumpus notes openSSL has the same issues and we only have to be better than openSSL, also bitcoin never forks so the problem is mainly for other applications using the library. It would be good if this was an effort which included non-bitcoin users (e.g. mailinglist & tor)

meeting conclusion

Long term goal is leaving openSSL only for BIP70.

Participants

wumpus Wladimir J. van der Laan jonasschnelli Jonas Schnelli gmaxwell Gregory Maxwell petertodd Peter Todd jtimon Jorge Timón cfields Cory Fields btcdrak btcdrak Luke-Jr Luke Dashjr paveljanik Pavel Janik maaku Mark Friedenbach 

Comic relief

19:47 wumpus note also that bitcoin never forks 19:48 wumpus gmaxwell: just add a disclaimer 'not fork safe' 19:48 jonasschnelli 'not fork safe'? HF or SF.... 19:48 jonasschnelli  
submitted by G1lius to Bitcoin [link] [comments]

ECDSA Playground

ECDSA Playground
ECDSA Playground https://8gwifi.org/ecsignverify.jsp

Elliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners.
This tool is capable of generating key the the curve


https://preview.redd.it/9fwcnzijrgu11.png?width=1127&format=png&auto=webp&s=a4f36c49b74f3122b2bc903f7582c17ea041dec1
"c2pnb272w1", "c2tnb359v1", "prime256v1", "c2pnb304w1", "c2pnb368w1", "c2tnb431r1", "sect283r1", "sect283k1", "secp256r1", "sect571r1", "sect571k1", "sect409r1", "sect409k1", "secp521r1", "secp384r1", "P-521", "P-256", "P-384", "B-409", "B-283", "B-571", "K-409", "K-283", "K-571", "brainpoolp512r1", "brainpoolp384t1", "brainpoolp256r1", "brainpoolp512t1", "brainpoolp256t1", "brainpoolp320r1", "brainpoolp384r1", "brainpoolp320t1", "FRP256v1", "sm2p256v1" 
secp256k1 refers to the parameters of the elliptic curve used in Bitcoin’s public-key cryptography, and is defined in Standards for Efficient Cryptography (SEC)
A few concepts related to ECDSA:
  • private key: A secret number, known only to the person that generated it. A private key is essentially a randomly generated number. In Bitcoin, a private key is a single unsigned 256 bit integer (32 bytes).
  • public key: A number that corresponds to a private key, but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine (in other words, produced with the proper key) without requiring the private key to be divulged.
  • signature: A number that proves that a signing operation took place.
Openssl Generating EC Keys and Parameters
$ openssl ecparam -list_curves secp256k1 : SECG curve over a 256 bit prime field secp384r1 : NIST/SECG curve over a 384 bit prime field secp521r1 : NIST/SECG curve over a 521 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field 
An EC parameters file can then be generated for any of the built-in named curves as follows:
$ openssl ecparam -name secp256k1 -out secp256k1.pem $ cat secp256k1.pem -----BEGIN EC PARAMETERS----- BgUrgQQACg== -----END EC PARAMETERS----- 
To generate a private/public key pair from a pre-eixsting parameters file use the following:
$ openssl ecparam -in secp256k1.pem -genkey -noout -out secp256k1-key.pem $ cat secp256k1-key.pem -----BEGIN EC PRIVATE KEY----- MHQCAQEEIKRPdj7XMkxO8nehl7iYF9WAnr2Jdvo4OFqceqoBjc8/oAcGBSuBBAAK oUQDQgAE7qXaOiK9jgWezLxemv+lxQ/9/Q68pYCox/y1vD1fhvosggCxIkiNOZrD kHqms0N+huh92A/vfI5FyDZx0+cHww== -----END EC PRIVATE KEY----- 
Examine the specific details of the parameters associated with a particular named curve
$ openssl ecparam -in secp256k1.pem -text -param_enc explicit -noout Field Type: prime-field Prime: 00:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:fe:ff: ff:fc:2f A: 0 B: 7 (0x7) Generator (uncompressed): 04:79:be:66:7e:f9:dc:bb:ac:55:a0:62:95:ce:87: 0b:07:02:9b:fc:db:2d:ce:28:d9:59:f2:81:5b:16: f8:17:98:48:3a:da:77:26:a3:c4:65:5d:a4:fb:fc: 0e:11:08:a8:fd:17:b4:48:a6:85:54:19:9c:47:d0: 8f:fb:10:d4:b8 Order: 00:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:fe:ba:ae:dc:e6:af:48:a0:3b:bf:d2:5e:8c:d0: 36:41:41 Cofactor: 1 (0x1) 
submitted by anish2good to u/anish2good [link] [comments]

How to convert 65 char private key to WIF compressed 52 char base 58?

I recently used a utility to search my old HD's for private keys. It worked well. The utility (https://www.makomk.com/gitweb/?p=bitcoin-wallet-recover.git) spit out a list of 209 public and private keys, for example (not real numbers)
$ sudo ./wallet-recover /dev/sdg recovered-wallet.dat pubkey_comp = 0297699ca958ada8e31cfc180b46a8b5db95dfbed9d16d4ca82ad2265dc0e97d26 privkey = de0f5a37ba4b69096385b00655f7f2d55bc114c3051993f24d2d46926ca05ad8 
So, I now have these private keys, and supposedly they are also in recovery_wallet.dat. However, the old bitcoin client (v0.7.0) seems to only recognize one address and using "importprivkey" in the console reports an error when I try to manually import these private keys.
These found keys are valid, as I am able to test them in https://www.bitaddress.org and then test the resulting address in blockchain.info.
These keys seem to be ASCII string of hexadecimal of the 256-bit ECDSA private key.
My problem is, I need to now convert these 64 character private keys to something I can import, like the WIF format.
I have this little script to convert to base58check
#!/bin/bash export PRIV_KEY=${1} export VER=ef echo ${VER}${PRIV_KEY} -n | xxd -r -p | openssl dgst -sha256 -binary | openssl dgst -sha256 > tmp export R=`cat tmp|awk '{print $2}'` echo ${R} | perl -p -e 's/^(........).*/$1/gmi' > tmp export CHECKSUM=`cat tmp` export PRE=`echo ${VER}${PRIV_KEY}${CHECKSUM}` echo ${PRE} 
This script tests ok when comparing to https://bitcointalk.org/index.php?topic=1801519.0
The output number is in a WIF format, but, when I go to Electrum and create a new wallet with "import private keys", Electrum does not recognize the number :/
I can't seem to create any number from the private keys that can be imported. What DOES work is if I go to http://bitaddress.org, enter the private key, then cut the new "Private Key WIF Compressed 52 characters base58" they make...
So, the question is... HOW DO I MAKE A "PRIVATE KEY WIF COMPRESSED 52 CHAR BASE 58" STRING FROM THE PRIVATE KEY THE SCRAPPER FOUND?
I know I can cut and paste hundreds, thousands, of private keys into bitaddress.org, but I hoping someone here knows how to do it programmatically, like, a utility or an algo or something.
Thanks
submitted by duncan_stroud to Bitcoin [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2016-01-28)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last summarisation
Disclaimer
Please bear in mind I'm not a developer so some things might be incorrect or plain wrong. There are no decisions being made in these meetings, but since a fair amount of devs are present it's a good representation. Copyright: Public domain

Logs

Main topics

Short topics

ajtowns has written some functional test scripts for OP_CSV which will be helpful for testing #7184(BIP 68) and #6564(BIP 112)

Refactoring window

background

jtimon asks when exactly this is and what it entails. Refactoring is moving code around to specific libraries or files to make things easier to read and to safely change parts of the code without affecting other parts. Mainly these will be moves to facilitate libconsensus, the part that will hold all the consensus-critical code.

meeting comments

Wumpus is fine with starting to merge moveonly stuff. The refactors might interfere with segregated witness, however waiting for it might cause the refactor window for 0.13 to be missed.

meeting conclusion

Refactor window is from now till -undecided- Review #7091, #7287, #7310 and #7311

outstanding issues for 0.12.0

background

Bitcoin Core 0.12 is scheduled for release around February and introduces a lot of fixes and improvements. (release notes) There's a release candidate 0.12rc2 available at https://bitcoin.org/bin/bitcoin-core-0.12.0/test/

meeting comments

We need to sign the win32 release with a new key for win7+ as the current key uses sha-1 which is broken. There's still some controversy how the changes for priority should be noted in the release notes. e.g. #7346 gmaxwell points out we never did anything about the issues with localhost being whitelisted which might cause issues with the new automatic hidden service creation. This issue was raised in the 2015/12/03 meeting

meeting conclusion

There will be a new key, if it takes too long to get it someone else can sign it this time. gmaxwell will change #7082 to only remove the privledging of localhost. The rest of the PR can be done for 12.1/0.13

how does this new "critical" OpenSSL release affect us

background

There's a new openSSL release which fixes some security issues. https://mta.openssl.org/pipermail/openssl-announce/2016-January/000061.html Question is if and how this affects bitcoin. Since 0.12 bitcoin-core uses their own libsecp256k1 for ECDSA signature verification instead of openSSL.

meeting comments

BIP70 (Payment Protocol) might be affected. The parts of core that still depend on openSSL are entropy, AES (wallet) and BIP70. There's a plan to replace openSSL for entropy with fortuna (build by sipa and gmaxwell), which needs to be build into a separate library. There are many complications in making a safe random number generator, first among them is fork detection (fork= a unix operation which duplicates the entire process state which will lead to reuse of random numbers) Wumpus notes openSSL has the same issues and we only have to be better than openSSL, also bitcoin never forks so the problem is mainly for other applications using the library. It would be good if this was an effort which included non-bitcoin users (e.g. mailinglist & tor)

meeting conclusion

Long term goal is leaving openSSL only for BIP70.

Participants

wumpus Wladimir J. van der Laan jonasschnelli Jonas Schnelli gmaxwell Gregory Maxwell petertodd Peter Todd jtimon Jorge Timón cfields Cory Fields btcdrak btcdrak Luke-Jr Luke Dashjr paveljanik Pavel Janik maaku Mark Friedenbach 

Comic relief

19:47 wumpus note also that bitcoin never forks 19:48 wumpus gmaxwell: just add a disclaimer 'not fork safe' 19:48 jonasschnelli 'not fork safe'? HF or SF.... 19:48 jonasschnelli  
submitted by G1lius to btc [link] [comments]

OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection. | Gregory Maxwell | Jan 10 2015

Gregory Maxwell on Jan 10 2015:
OpenSSL 1.0.0p / 1.0.1k was recently released and is being
pushed out by various operating system maintainers. My review
determined that this update is incompatible with the Bitcoin
system and could lead to consensus forks.
Bitcoin Core released binaries from Bitcoin.org are unaffected,
as are any built with the gitian deterministic build system.
If you are running third-party or self-compiled Bitcoin Core
or an alternative implementation using OpenSSL you must not
update OpenSSL or must run a Bitcoin software containing a
workaround:
https://github.com/bitcoin/bitcoin/commit/488ed32f2ada1d1dd108fc245d025c4d5f252783
(versions of this will be backported to other stable branches soon)
The tests included with Bitcoin Core in the test_bitcoin
utility already detect this condition and fail. (_Do not ignore or
disable the tests in order to run or distribute software
which fails_)
The incompatibility is due to the OpenSSL update changing the
behavior of ECDSA validation to reject any signature which is
not encoded in a very rigid manner. This was a result of
OpenSSL's change for CVE-2014-8275 "Certificate fingerprints
can be modified".
While for most applications it is generally acceptable to eagerly
reject some signatures, Bitcoin is a consensus system where all
participants must generally agree on the exact validity or
invalidity of the input data. In a sense, consistency is more
important than "correctness".
As a result, an uncontrolled 'fix' can constitute a security
vulnerability for the Bitcoin system. The Bitcoin Core developers
have been aware of this class of risk for a long time and have
taken measures to mitigate it generally; e.g., shipping static
binaries, internalizing the Leveldb library... etc.
It was somewhat surprising, however, to see this kind of change show
up as a "low" priority fix in a security update and pushed out live
onto large numbers of systems within hours.
We were specifically aware of potential hard-forks due to signature
encoding handling and had been hoping to close them via BIP62 in 0.10.
BIP62's purpose is to improve transaction malleability handling and
as a side effect rigidly defines the encoding for signatures, but the
overall scope of BIP62 has made it take longer than we'd like to
deploy.
(Coincidentally, I wrote about this concern and our unique demands on
cryptographic software as part of a comment on Reddit shortly before
discovering that part of this OpenSSL update was actually
incompatible with Bitcoin:
https://www.reddit.com/Bitcoin/comments/2rrxq7/on_why_010s_release_notes_say_we_have_reason_to/cnitbz3
)
The patches above, however, only fix one symptom of the general
problem: relying on software not designed or distributed for
consensus use (in particular OpenSSL) for consensus-normative
behavior. Therefore, as an incremental improvement, I propose
a targeted soft-fork to enforce strict DER compliance soon,
utilizing a subset of BIP62.
Adding a blockchain rule for strict DER will reduce the risk of
consensus inconsistencies from alternative implementations of
signature parsing or signature verification, simplify BIP62,
and better isolate the cryptographic validation code from the
consensus algorithm. A failure to do so will likely leave us
in this situation, or possibly worse, again in the future.
The relevant incompatible transactions are already non-standard on
the network since 0.8.0's release in February 2013, although there
was seemingly a single miner still mining incompatible transactions.
That miner has been contacted and has fixed their software, so a
soft-fork with no chain forking should be possible.
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-January/007097.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Disclosure: consensus bug indirectly solved by BIP66 | Pieter Wuille | Jul 28 2015

Pieter Wuille on Jul 28 2015:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all,
I'd like to disclose a vulnerability I discovered in September 2014,
which became unexploitable when BIP66's 95% threshold was reached
earlier this month.

Short description:

A specially-crafted transaction could have forked the blockchain
between nodes:

Upgrade instructions:

None. Transactions that could trigger this problem have become invalid
on the network since BIP66's deployment of version 3 blocks reached 95%
on July 4th, 2015.

Long description:

The problem is related to the signature encoding rules.
Bitcoin's signatures are ASN.1 BER encoded. BER is a complex standard
that allows many different encodings for the same data. Since Bitcoin
Core 0.8, a standardness rule has been in effect that only allowed
subset of encodings (DER) for relay and mining, even though any BER
remained valid in the blockchain - at least in theory.
In practice, BER has many weird edge cases, and I have not found a
single cryptographic codebase that can parse all of them correctly.
This includes OpenSSL, Crypto++, BouncyCastle, btcec, and our own
libsecp256k1 library.
This on itself would not be a problem, as full nodes on the network
currently use OpenSSL. However, while researching what was needed to
make libsecp256k1 compatible with it, I discovered that OpenSSL is even
inconsistent with itself across different platforms.
One of the features of BER is the ability for internal structures to
have a length descriptor whose size itself is up to 126 bytes (see
X.690-0207 8.1.3.5). A 1 terabyte data structure would for example use
a 5-byte length descriptor. However, there is no requirement to use the
shortest possible descriptor, so even a 70-byte ECDSA signature could
use a 5-byte length descriptor and be valid. Unfortunately, OpenSSL
supports length descriptors only as long as their size is at most that
of a C 'long int', a type whose size depends on the platform (Windows
and 32-bit Linux/OSX have a 4-byte long int, 64-bit Linux/OSX have an
8-byte long int). See
https://github.com/openssl/openssl/blob/bfa34f551c2d38e826deb44a269cb0f720f9f63b/crypto/asn1/asn1_lib.c#L178.
Some non-OpenSSL based signature validation
systems don't support such length descriptors at all, resulting in an
extra forking risk on top for them if used for blockchain validation.
This effectively means that a block chain containing a transaction with
a valid signature using such a 5-byte length descriptor would be
accepted by some systems and not by others, resulting in a fork if it
were mined into a block.

Timeline:

signatures non-standard. No release since then would relay or mine
transactions that could trigger the vulnerability. However, such a
transaction was still valid inside blocks.
The BIP62 draft includes a rule that would make version 2 transactions
with non-DER signatures invalid.
depend on OpenSSL's specific parser, I modified the BIP62 proposal to
have its strict DER signatures requirement also apply to version 1
transactions. No non-DER signatures were being mined into blocks
anymore at the time, so this was assumed to not have any impact. See
https://github.com/bitcoin/bips/pull/90 and
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-July/006299.html.
Unknown at the time, but if deployed this would have solved the
vulnerability.
discovered the architecture dependency listed above and the associated
vulnerability. The best means to fix it at the time was by getting
BIP62 adopted.
Several proposed changes to BIP62. See
https://github.com/bitcoin/bips/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+bip62.
for CVE-2014-8275. The fix introduced a restriction on ECDSA signatures
to be strict DER, which would have solved all problems related to
signature encodings, except Bitcoin's consensus-critical nature
requires bug-for-bug compatibility between nodes. Worse, it seemed that
there was again a small (1%) number of blocks being created with
non-DER signatures in it, resulting in actual forks. The only immediate
solution that did not introduce more risk for forks was parsing and
re-encoding signatures using OpenSSL itself before verification to
bypass the restriction, making the problem persist. See
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-January/007097.html.
revealed the vulnerability, and the presence of miners not enforcing
strict DER might have made the vulnerability actually exploitable.
BIP62 was still a moving target, so we wanted a faster means to solve
this. Therefore, a new BIP was proposed with just the strict DER
requirement, numbered BIP66. This would both allow non-OpenSSL
verification, and solve the vulnerability, without needing to fix the
less urgent malleability problem that BIP62 wanted to address. See
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-January/007156.html.
BIP66. See
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007480.html.
rule for strict DER signatures in the blockchain. This solved the
vulnerability, and opens the door to using non-OpenSSL signature
verification in the near future.
Pieter Wuille
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBAgAGBQJVt5FGAAoJEFeJbS/48LZX3ccMAJdPrpa8ggcYEyy8naqc7ewL
1Mwv24p/6Q8+T7Q6EWmgoApY1jljF+AzgSpfaf310QZf9yuC/JC++AmHfUaa9UQG
Mq1+duX64uDWIeNKTfuCwZvU0ataARZKmFUpp60UF+VtiJyLo9tpHTVajM0lv9Oq
OX40qHVC/iBogRLNREC1ggWH1JPMTbEch50YX1bgNi3gE5gtMggSQ2OXrGCCtrvR
7cVFlIyOhlLtvSAnxzmHyY8Iol+qVhIZi4mCmDgOoQKVaiYm1cODQ+nrMHx02DKC
Wqstwb/mET/vbCX4qxSNQ2B+mQk0WO/gSrWiQkBLi/AfLBh/8A/kL1RpKxVQzoaP
O165LbXye42w8Js/sE/zT6d4CIbYaW0GpF6m4agwDYgPLomhdk/elPRojKYsEab+
oFWPVagqKI9e/pjFBxqfIv3iyx1hHB6YIaX5TfFRVjsWzag5Qi2ssQYOQymyjg4J
UHNxW0PMPAOg5KS/uFja4OWxstHhTW9G+rslEK9g==
=7F3K
-----END PGP SIGNATURE-----
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

"By placing a probe near a mobile device while it performs cryptographic operations, an attacker can measure enough electromagnetic emanations to fully extract the secret key that authenticates the end user's data or financial transactions."

This is an automatic summary, original reduced by 71%.
Researchers have devised an attack on Android and iOS devices that successfully steals cryptographic keys used to protect Bitcoin wallets, Apple Pay accounts, and other high-value assets.
"An attacker can non-invasively measure these physical effects using a $2 magnetic probe held in proximity to the device, or an improvised USB adapter connected to the phone's USB cable, and a USB sound card," the researchers wrote in a blog post published Wednesday.
While the researchers stopped short of fully extracting the key on a Sony-Ericsson Xperia x10 Phone running Android, they said they believe such an attack is feasible.
CoreBitcoin developers told the researchers they plan to replace their current crypto library with one that's not susceptible to the attack.
The researchers said they reported the vulnerability to OpenSSL maintainers, and the maintainers said that hardware side-channel attacks aren't a part of their threat model.
At the moment, the attack would require a hacker to have physical possession of-or at least have a cable or probe in close physical proximity to-a vulnerable mobile device while it performed enough operations to measure "a few thousand ECDSA signatures." The length of time required would depend on the specific application being targeted.
Summary Source | FAQ | Theory | Feedback | Top five keywords: attack#1 research#2 vulnerable#3 key#4 version#5
NOTICE: This thread is for discussing the submission topic only. Do not discuss the concept of the autotldr bot here.
submitted by autotldr to autotldr [link] [comments]

New attack steals secret crypto keys from Android and iOS phones

This is an automatic summary, original reduced by 71%.
Researchers have devised an attack on Android and iOS devices that successfully steals cryptographic keys used to protect Bitcoin wallets, Apple Pay accounts, and other high-value assets.
"An attacker can non-invasively measure these physical effects using a $2 magnetic probe held in proximity to the device, or an improvised USB adapter connected to the phone's USB cable, and a USB sound card," the researchers wrote in a blog post published Wednesday.
While the researchers stopped short of fully extracting the key on a Sony-Ericsson Xperia x10 Phone running Android, they said they believe such an attack is feasible.
CoreBitcoin developers told the researchers they plan to replace their current crypto library with one that's not susceptible to the attack.
The researchers said they reported the vulnerability to OpenSSL maintainers, and the maintainers said that hardware side-channel attacks aren't a part of their threat model.
At the moment, the attack would require a hacker to have physical possession of-or at least have a cable or probe in close physical proximity to-a vulnerable mobile device while it performed enough operations to measure "a few thousand ECDSA signatures." The length of time required would depend on the specific application being targeted.
Summary Source | FAQ | Theory | Feedback | Top five keywords: attack#1 research#2 vulnerable#3 key#4 version#5
NOTICE: This thread is for discussing the submission topic only. Do not discuss the concept of the autotldr bot here.
submitted by autotldr to autotldr [link] [comments]

The Elliptic Curve Digital Signature Algorithm and raw transactions on Bitcoin 2014 02 14 - Elliptic Curve Digital Signature Algorithm in the SageMathCloud Bitcoin Hack 2020 method How to recover your Bitcoin private key-Facebook like @findBTC Threshold ECDSA from ECDSA Assumptions

At the very beginning, Bitcoin adopted the ECDSA signature mechanism based on secp256k1 implemented in OpenSSL, where there is no targeted optimization for the secp256k1 curve leading to the low ... О ecdsa [править] Сравнение размера ключа и подписи с dsa [править]. Как и в случае криптографии с эллиптическими кривыми, размер бит открытого ключа, который, как полагают, необходим для ecdsa, примерно в два раза превышает ... ECDSA In Bitcoin. Digital signatures are considered the foundation of online sovereignty. The advent of public-key cryptography in 1976 paved the way for the creation of a global communications tool – the Internet, and a completely new form of money – Bitcoin. Although the fundamental properties of public-key cryptography have not changed much since then, dozens of different open-source ... Dies ermöglichte es Hackern, private Schlüssel wiederherzustellen, wodurch Bitcoin-Transaktionen genauso kontrolliert werden konnten wie die Besitzer legitimer Schlüssel, wobei derselbe Exploit verwendet wurde, mit dem der PS3-Signaturschlüssel bei einigen Android-App-Implementierungen verfügbar gemacht wurde, die Java verwenden und ECDSA zur Authentifizierung von Transaktionen verwenden . Bitcoin SV Fiyatı Craig Wright'ın Bitcoin Servetine… Artık Dünya Çapında 90.000 Konaklama Yerinde… O zaman, çevrimiçi iletişimin gizliliğini artırmak için deneyimli şifre bankaları tarafından geliştirilen açık bir şifreleme araçları seti olan OpenSSL’de ECDSA’ya yerel destek sağlanmıştır .

[index] [13466] [34687] [41984] [10440] [16765] [31846] [37902] [39136] [46168] [15206]

The Elliptic Curve Digital Signature Algorithm and raw transactions on Bitcoin

Timing and Lattice Attacks on a Remote ECDSA OpenSSL Server: How Practical Are They Really? - Duration: 32:54. David Wong 783 views. 32:54. Elliptic Curve Cryptography & Diffie-Hellman - Duration ... Bitcoin ECDSA- Elliptic curve Digital Signature - Duration: 8:43. Dr Abdel lam 3,174 views. 8:43 . How-To Use Skype - Duration: 29:27. ArvigHQ Recommended for you. 29:27. Breaking ECDSA (Elliptic ... Skip navigation Sign in. Search Threshold ECDSA from ECDSA Assumptions Jack Doerner (Northeastern University), Yashvanth Kondi (Northeastern University), Eysa Lee (Northeastern University), abhi shelat (Northeastern University) Get your private keys from the Android Bitcoin Wallet with OpenSSL - Duration: 11:13. Bitcoin Daytrader Recommended for you. 11:13 . No One Can Beat a Shaolin Master and Here Is Why - Duration: 10 ...

#