One thing that frustrates me about the response to the OpenSSL bug is how everyone is suddenly angry at the developers:

• "the bar needs to be higher for core internet infrastructure",
• "openssl team is unprofessional",
• "there's no pair programming / mandatory code review / full test coverage / static analysis and verification, how amateur".

But this "core internet infrastructure" that secures countless billions of dollars worth of customer data is still a volunteer project developed by about 20 enthusiasts in their spare time left over from consulting and academic work: http://www.openssl.org/about/

I've yet to see anyone actually volunteer to start writing tests, start contributing their expertise in static verification, start refactoring code to be better readable, or hell, just assigning a few employees to work on OpenSSL (or an alternative SSL library) full time. It seems just wrong to demand perfection from a volunteer team because the project is critical to you, while being unwilling to contribute anything back.

I like how this is literally all the "security advisory" from OpenSSL says about what the impact of the vulnerability is. Seriously? Maybe want to mention what exactly that 64k of memory might get an attacker, such as the private keys? This is the most pathetic advisory.

http://www.mitls.org/wsgi/tls-attacks

> More typical implementation attacks are buffer overflows [OpenSSL vulnerabilities] resulting from programming errors, or timing-based side channel attacks against cryptographic primitives [BrumleyB]. The former are largely prevented as we use a save language. The latter are outside our model, and we rely on the proper implementation of core cryptographic algorithms by the Bouncy Castle library that we rely on.

This is a pretty important caveat, I think.

Short version: OpenSSL uses a random number generator (RAND_egd (entropy gathering daemon)) to give large numbers to a primality tester. OpenSSL uses the Miller-Rabin Test.

Long version: http://www.openssl.org/docs/crypto/BN_generate_prime.html

1) Generate a "random" integer of the required size (number of bits). The randomness must be quite good, for the result to be cryptographically secure. This is what RAND_egd does. This is still a tough problem. -- This number should be odd.

2) Try to divide the number by a list of known primes (3,13, etc) to stop early.

3) If the previous step is passed, run Miller-Rabin. There are no composite numbers that will always pass this test.

4) If the odd number fails the Miller-Rabin test, increase the number by 2 and go back to step 2. Usually several iterations are necessary (more than a hundred).

The resulting number is only probably prime, called "pseudoprime". The number has a low, but nonzero probability of being composite.

> None of these companies, groups, or individuals thought to do security testing (namely trust, but verify) on this core component because what? "It's not my problem?"

Did you completely miss the fact that a guy from Google found and reported the bug? Lots of other people have found and reported OpenSSL vulnerabilities:

http://www.openssl.org/news/vulnerabilities.html

To suggest that nobody is looking for security vulnerabilities in OpenSSL is ridiculous.

I have but one response to this:

http://www.openssl.org/news/vulnerabilities.html

How long did those serious vulns sit in open source code for the world and all the experts to see but never discover? And how long for those who found them and never divulged to exploit them?

Multiple examples in any piece of software, in any OS, but the OpenSSL project gives us the clearest lesson.

There is a vibrant and lucrative 0day market for a reason.

There's a workaround for the implicit IV anyway, and it's been in OpenSSL for a while: stick an empty application data fragment in the stream before you start sending actual application data. I don't understand why this works but it's explained better here:

http://www.openssl.org/~bodo/tls-cbc.txt

Only thing is it's usually disabled by default because it breaks older clients using a severely broken TLS implementation, a phrase which roughly translates to "Internet Explorer 6".

http://www.openssl.org/news/secadv_20140407.txt

OpenSSL Security Advisory [07 Apr 2014]

TLS heartbeat read overrun (CVE-2014-0160)

A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to Adam Langley <> and Bodo Moeller <> for preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2.

Does anyone feel like giving the idiots guide to AES file decryption on Windows 7?

edit: figured it out, instructions follow

• for windows you'll need to get openssl, here (*nix should usually already have it)
• make sure openssl is in your path, or run it with an absolute path
• then run "openssl enc -d -aes256 -in sDgo3FDksdGwsrkrS.enc -out decrypt.7z" without quotes and enter the password from the headline of this post
• you'll need 7zip to open the decrypted file

rust-openssl seems to be a relatively thin wrapper around openssl. You can find the openssl documentation here: http://www.openssl.org/docs/ Once you find out how to do it in any other language, translation to rust should be simple.

So I replied before. But I've done more digging

• Python is fine. randint(a,b) does not just scale some number as you suggest. See the source
• Java provides random. nextInt is just fine and will discard all bits that will result in skew
• C there are several versions of random number generators that will give a range. http://www.openssl.org/docs/crypto/BN_rand.html

These are all correct implementations of getting a random number in a range.
These are all readily available. Libraries and Languages are not broken if the correct function isn't being used.

The "look just like typical BSD licenses" is the problem, more specifically clauses like this:

> 3. All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)"

While this does not make the license non-free (indeed, the old license is still very permissive), it would be a further restriction not authorized by the GPL. Hence, it is not possible to distribute software licensed under the GPL linked to OpenSSL.

OpenSSH is the tweak that allows you to SSH (see definition below) into your device.

SSH - Secure Shell (SSH), sometimes known as Secure Socket Shell, is a UNIX-based command interface and protocol for securely getting access to a remote computer.

SSL - Secure Socket Layer (SSL) It's the protocol that enables secure communication. For example, if you're banking on-line and the URL starts with https, that's secure, using SSL. SSL doesn't "open" your security, on the contrary, you don't have any without it. See http://www.openssl.org/

OpenSSL - the Cydia tweak that installs the OpenSSL code, allowing SSL command line communication between devices

They probably depend on some mutual libraries but the bug in question is only affecting GnuTLS. If you are interested in bugs that are affecting your specific version of OpenSSL you can always check http://www.openssl.org/news/vulnerabilities.html but most of them are probabl already fixed upstream.

Basically what's happening is CenOS has problem with licensing the Elliptical Curve function secp256k1 so there is a chance your installed openssl package doesn't have it enabled. So, if after trying what i suggested above it still doesn't work, you have to compile openssl yourself. Follow the instructions below:

As root (or prepend sudo):

yum groupinstall "Development Tools" -y

yum install kernel-devel -y

yum install boost-thread boost-devel boost boost-system boost-filesystem boost-program-options leveldb-devel -y

Then as your non-root user (suggested):

wget http://www.openssl.org/source/openssl-1.0.1f.tar.gz

tar -xzf openssl-1.0.1f.tar.gz

cd openssl-1.0.1f

./config

make

Now you have to compile your reddcoind again. But first you need to point the makefile to your own compiled openssl:

add the following lines to makefile.unix (change the absolute path in the first line as appropriate for you):

DSSL = /home/mypath/openssl-1.0.1f

ISSL = $(DSSL)/include

OPENSSL_LIB_PATH = $(DSSL)

OPENSSL_INCLUDE_PATH = $(ISSL)

Then to make: make -f makefile.unix USE_UPNP= BOOST_LIB_SUFFIX=-mt

>Applications only using the PEM routines are not affected.[1]

Also

>Note: although an application using the SSL/TLS portions of OpenSSL is not automatically affected it might still call a function such as d2i_X509_bio on untrusted data and be vulnerable.[1]

So, it looks like there needs to be a constellation of things to be exploitable, but I very well could be wrong. Clarification would be most welcome.

edit: you need to be calling something that uses the affected ASN.1 functions

[1]http://www.openssl.org/news/secadv_20120419.txt

P.S. @hanomalous >I just remembered that this will also make possible to compromise a client

Client?

Step 1: Reimage to CentOS 6.5

Step 2: yum install -y gcc-c++ boost-devel db4-devel zlib-devel wget git wget http://www.openssl.org/source/openssl-1.0.1h.tar.gz tar xzf openssl-1.0.1h.tar.gz cd openssl-1.0.1h ./config --prefix=/usr --openssldir=/usr/local/openssl shared make && make test && make install git clone https://github.com/rat4/blackcoin.git ~/blackcoin && cd ~/blackcoin/src

edit makefile.unix - line 5 should be USE_UPNP:=- and on line 30 should be -l boost_thread-mt$(BOOST_LIB_SUFFIX) \

make -f makefile.unix

Hopefully someone has instructions for Ubuntu :) I can try tomorrow morning if not.

Here is how I successfully compiled and ran blackcoind on an updated CentOS 6.5 minimal install. This does not include upnp support. Though it seems the official openssl 1.0.1e should support ECC, blackcoind throws an error so I needed to install a newer version of openssl from source. Let me know if there are any problems or typos. This will be copypasted to www.kentuckypaws.com. Unfortunately, I don't know how to help with the second part of your request.

• yum install -y gcc-c++ boost-devel db4-devel zlib-devel wget git
• wget http://www.openssl.org/source/openssl-1.0.1h.tar.gz
• tar xzf openssl-1.0.1h.tar.gz
• cd openssl-1.0.1h
• ./config --prefix=/usr --openssldir=/usr/local/openssl shared
• make && make test && make install
• git clone https://github.com/rat4/blackcoin.git ~/blackcoin
• cd ~/blackcoin/src
• #edit makefile.unix - line 5 should be USE_UPNP:=- and on line 30 should be -l boost_thread-mt$(BOOST_LIB_SUFFIX) \
• make -f makefile.unix

I don't think that's a valid thing to say. Keys are not generated by a single call of the rand() function. Perhaps there is no builtin LGC that will give you more than 32 bits of entropy, but crypto libraries have matured over the last several decades and are operating with far more entropy than 32 bits.

You'll notice that libraries like OpenSSL have all implemented their own random functions to address this issue.

I understand that the site says "If you're using private keys generated from standard pseudorandom sequence of numbers," implying nothing more than a call to rand(), but that seems very misleading seeing as current Bitcoin key generation software is not implemented that way.

~~You have a good advice about not using OpenSSL for this (if you're correct about it not using key derivation function)~~[see edit], but in your advice about using public key encryption as a way to "harden" passwords you're making stuff up.

To encrypt files that only you will open:

1. If you want to have your encryption keys stored somewhere else (e.g. USB drive), then yes, use public key encryption (surprise, surprise -- most programs, including PGP, use symmetric encryption that you're so afraid of underneath, see my other comment).

2. In every other situation, use secret key encryption with password (gpg -c). There's no need to invent stupid schemes. "Each individual file is encrypted with a different key" is also the case for any respected encryption program. How? Key derivation with salt, that's how.

Your idea about how it's harder to brute-force 1 than 2 is just a misunderstanding that complexity is somehow more secure. It's not.

tl;dl WTF is wrong with people on reddit giving wrong cryptography advice? May I point everyone to this blog post (or this presentation [PDF]), written by a person who knows this stuff.

Edit: OpenSSL uses key derivation function and salt for file encryption -- http://www.openssl.org/docs/apps/enc.html (see "-salt" option, default)

socat -d -d -d -T 5 tcp:localhost:8333 -

The three -d options to get a lot of info

2017/08/23 01:34:10 socat[17933] I socat by Gerhard Rieger - see www.dest-unreach.org 2017/08/23 01:34:10 socat[17933] I This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/) 2017/08/23 01:34:10 socat[17933] I This product includes software written by Tim Hudson () 2017/08/23 01:34:10 socat[17933] N opening connection to AF=2 127.0.0.1:8333 2017/08/23 01:34:10 socat[17933] I starting connect loop 2017/08/23 01:34:10 socat[17933] I socket(2, 1, 6) -> 5 2017/08/23 01:34:10 socat[17933] N successfully connected from local address AF=2 127.0.0.1:59112 2017/08/23 01:34:10 socat[17933] N reading from and writing to stdio 2017/08/23 01:34:10 socat[17933] I resolved and opened all sock addresses 2017/08/23 01:34:10 socat[17933] N starting data transfer loop with FDs [5,5] and [0,1] 2017/08/23 01:34:15 socat[17933] I poll timed out (no data within 5.000000 seconds) 2017/08/23 01:34:15 socat[17933] N inactivity timeout triggered 2017/08/23 01:34:15 socat[17933] N exiting with status 0 2017/08/23 01:34:15 socat[17933] I shutdown(5, 2)

This is wrong; openssl (and its clones) can be used by GPL applications. See their FAQ; http://www.openssl.org/support/faq.html#LEGAL2

You are also wrong about Bitcoin Core not being usable with non-free software. Their approach is that you run bitcoind (the gui-less service) and connect to it over RPC. This makes license discussions irrelevant.

FWIW; a relicense would get my thumbs up.

> 2.1.5 was released 2 weeks ago

Released publicly 2 weeks ago, but the devs knew of the issue since Aug 8 and reverted someone's commit to fix the issue.

> Had you explored simply reverting to 2.1.4?

Not a wise suggestion. 2.1.5 addresses a lot of security issues, even beyond OpenSSL.

> Or even using a browser other than Firefox?

I actually use Chromium and not Firefox. I don't know where you got that notion.

> You ditched a top-rated...

I did, I expect anything top-rated to fix known issues with acceptable solutions or put the issue in the release notes before releasing it to the public.

> Over a browser specific rendering issue?

Read your own link, literally the first post: "I've tested it in both Chrome 37.0.2062.94 (64-bit) and Firefox 31.0"

> Most report...

You mean one person "Fenu", with only 37 posts to the forum. Not exactly a reputable source.

> ...the issue was resolved by refreshing the browser

That's not how browsers work. Refreshing the page makes your browser see if there's a new copy of anything it already has. If not, the browser uses it's local copy. To do what he's suggesting you have to completely clear the browser's cache, which does work. However, that's a pretty annoying workaround.

> And BTW, there is already a fix in the works

Doesn't look that that's been committed yet to the main git repo. Again, known fixes where submitted before 2.1.5 was released.

back up your android wallet. download openssl and the c++ libraries from http://www.openssl.org. and http://www.microsoft.com/en-us/download/details.aspx?id=29 install those two. get the android backup from /mnt/sdcard/Download/.. put that in the bin folder of openssl. name it something simple like a single letter but put .dat at the end. open command prompt and navigate to your openssl folder (hopefully you put it somewhere easy to find when you installed it). when you get to the proper directory run this command... openssl enc -d -aes-256-cbc -a -in <filename> it will spit out a key with a time stamp at the end. it looks like a public key but different. keep this window open for reference and go to dogecore. go to the debug window of dogecore 1.8 under the help menu and choose the console tab and enter importprivkey "key" into the console. double check to make sure you entered it correctly. press enter and let it do it's thing. it will run a progress bar for a while and your android wallet will be added alongside your existing wallet(s) in dogecore and they will show up in your history in the proper places as well. i did this just now and it hung up on 61% so i closed it and reopened my wallet and it had worked so...

Not sure how much I would trust OpenSSL. Have heard, from people I trust, that the coding standards are awful, making code reviews difficult.

The Debian flaw you mention is a good example, he asked on the upstream mailing list before making the change, and was basically told to go ahead. "If it helps with debugging, I'm in favor of removing them." "There's your first clue, build with -DPURIFY", etc. Not even the people on the upstream mailing list understood the implications of making the change.

See entire thread starting with http://marc.info/?l=openssl-dev&amp;m=114651085826293&amp;w=2

There have been a long list of security vulnerabilities found in openssl. See http://www.openssl.org/news/vulnerabilities.html . There are several independent projects announced to clean up the code (e.g. libreSSL). Not to mentioned the well publicised heartbleed bug, however this was just one security issue in a list of many.

Considering that not verifying input is a rather basic mistake, and presuming that the people who, if not submitting the code, then approving it at least for something like OpenSSL would be quite competent programmers (as opposed to some random dev who can barely run a server...but still knows enough to validate input), then yes, the idea that the introduction of this bug being intentional becomes rather plausible.

It would help if we could take a look at the changelog and see the patch that got committed. Eh, here's their website. March 14, 2012 is supposed to be when the bug introduced. This log from that date lists heartbeat as an added feature. Now just need to trawl around for the patch itself...

Indeed. Some software does, doesn't it? I believe the setup procedure for OpenVPN, for example, requires that you to generate distinct DH parameters with openssl dhparam. Is this the same thing?

> "I'm not quite sure what you are trying to say here. Calculate what? I don't know the in's and out's of intelligent packet analysis,"

They wna't to decrypt Gmail SSL. Basically, It's a http stream (which can be converted to a file; & vice versa). To decrypt it, first you need the entire sequence (not missing anything before i mean). Secundly, you need to sorta decompress it with the key. That's the job of your browser and the web server. SSL requires a lot of cpu time (which is why we use datacenters for massive web sites like gmail.). Technically speaking, it's really like file compression in reality. Except in the compress case you try to win place with your data instead of fudging it to make it illisible.

Edit : thought of the openSSL man which might interest you :http://www.openssl.org/docs/apps/openssl.html

As such, it requires a shitload of processing power. For a handful of connexion, no prob. Like you can run 5x winrar without crashing your computer. For (tens of. hundreds of ?) thousands, you need an entire datacenter; or even several, like the NSA. Which cost billions. Just for that.

It's technically feasible. Just not economicaly viable in our situation. Like you CAN technicaly build 10 aircraft carrier. But we can't afford em. For frak sake, we're on the verge of budget collapse, we can't handle the US DOD budget. Neither can the provider who would bankrupt.

Edit : And yes technically google himself could afford it. but then, they wouldn't be any better than when they gave users names, adress and data to the chinese government.

My aim was to just hit the first 8 lines. And it actually depends what the iv is for. In this case cbc actually requires an unpredicatable iv. The issue with a predictable iv is actually a few. http://www.openssl.org/~bodo/tls-cbc.txt gives some the the issues with tls and predictable iv's. I can give you more examples but actually iv's matter in different contexts

14 years ago things that were true are no longer true, and this is one of the issues with applied cryptography. There are more bad cipher implimentations of people who read that book than anywhere else in the world.

The sha constants actually come from the fractional parts of the first 64 primes. It's an interesting way of nothing up your sleeve numbers.

A checksum or hash of the plaintext would have been a horrible horrible thing. CBC mode should pretty much be just seeded from dev urandom and nothing else. It does the job perfectly.

Didn't get to the sbox generation actually stopped after i went well theres a lot of crying, I'll just leave it be.

Better inform the OpenSSL project then. They use urandom for random number generation. If it's good enough for OpenSSL, why is it not good enough for us?

Openssl is available on windows, linux and mac. EasyPHP includes a Apache with SSL support, so you can use SSL with that stack.

A SSL certificat from RapidSSL is cheap for about 10-20$. But for delevopment purposes a SelfSigned certificate should do. Link to generator.