ECDSA In Bitcoin - coinjoy.io

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]

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]

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]

OpenSSL ECDSA sign and verify file (3 Solutions!!) - YouTube [New! Update] BTC Privatekey Finder With Python 3.0+ ECDSA ... Creating a Certificate Authority with OpenSSL and ECDSA Timing Attaques sur un serveur OpenSSL ECDSA distant ... Bitcoin ECDSA- Elliptic curve Digital Signature

New Powerful Attacks On ECDSA In Bitcoin Systems. Posted by admin on 23 October 2014, 10:57 pm. There is a wave of new powerful cryptographic attacks on bitcoin systems. There are several types of attacks: Attacks which use poor random number events. It has already happened hundreds of times in the bitcoin blockchain since 2012. Now there is a recent massive outbreak of such events. Here is a ... However, Bitcoin Core currently relies on OpenSSL for ECDSA operations, and changing this is very nontrivial due to consensus risk. OpenSSL recently incorporated an option with similar effect (not exactly RFC6979, but at least using private key and message data in the construction of the nonce), which is however not yet available in a release (last I checked). 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... How ECDSA was incorporated into Bitcoin. When Satoshi Nakamoto, a mystical founder of the first crypto, started working on Bitcoin, one of the key points was to select the signature schemes for an open and public financial system. The requirements were clear. An algorithm should have been widely used, understandable, safe enough, easy, and ... r/btc: /r/btc was created to foster and support free and open Bitcoin discussion, Bitcoin news, and exclusive AMA (Ask Me Anything) interviews from … Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts. Log in sign up. User account menu • ECDSA In Bitcoin. Close • Posted by 4 minutes ago. ECDSA In Bitcoin. Digital signatures are considered the ...

[index] [50221] [11396] [36988] [42930] [1937] [3130] [13704] [7762] [4664] [3487]

OpenSSL ECDSA sign and verify file (3 Solutions!!) - YouTube

The Bitcoin Operations Technology Group (Optech) works to bring the best open source technologies and techniques to Bitcoin-using businesses in order to lower costs and improve customer ... Explication de mon article http://eprint.iacr.org/2015/839 présentation donnée dans le cadre de ma soutenance de Master à l'université de Bordeaux #bitcoinPrivatekey #hotvideo #Bitcoin Python code Bib39 for finder bitcoin privatekey Buy it -- https://satoshidisk.com/pay/C8qYXr Contact Email kritcharatme... Elliptic Curve Digital Signature Algorithm ECDSA Part 10 Cryptography Crashcourse - Duration: 35:32. Dr. Julian Hosp - Bitcoin, Aktien, Gold und Co. 5,803 views You can never have enough tools in your toolbelt when it comes to working with digital certificates. In this video, StormWind security instructor Shane Sexton prepares a certificate authority ...

#