gnupg - Retrieving GPG Private Sub-Key ID - Information ...

A slightly overboard response to my threat model.

For what I hope are obvious reasons, I don't want, and probably will never post my threat model publicly online. However, regardless of that, what I'm sure you will extrapolate from this post is that I live my life, digitally in particular, with a fairly high level threat model. This is not because I'm some super sophisticated criminal mastermind, but rather, I am at this level because I genuinely love playing around with this stuff. And I just happen to understand the importance of privacy and just how vital it is to a truly healthy society. I would like to extend a thanks to ProgressiveArchitect for the sharing of the knowledge they have done on this subreddit, /privacytoolsio, and the like. We may have never interacted, but nevertheless, your input into this community is truly interesting and extremely informative and educating. I'm sure those of you familiar with PA's setup will be able to draw some parallels with mine and their's.
Thank you.
I hope you all enjoy reading this write up.
I run Qubes OS on a Lenovo ThinkPad X230 laptop. Specs for it are as following: - i7-3520M - 16GB RAM - 1TB Samsung 860 Evo SSD - Qualcomm Atheros AR9285 wireless card
Additionally, I used a Raspberry Pi Model 3B+ and a Pomono SPI clip to replace the stock BIOS firmware with coreboot+me_cleaner. This wasn't done out of any "real" concern for the Intel ME (though of course proprietary black-boxes like it should be avoided at all costs and not trusted), but rather for open source enthusiasm and for increased security and faster boot times than what the stock BIOS firmware allows for. On that note about the ME, I don't believe the conspiracy theories that claim that it is a state-sponsored attack method for surveillance. I believe that Intel had good intentions for improving the lives of IT professionals who need to manage hundreds, if not thousands of remote machines. However, it has proven time and time again to be insecure, and I don't need the remote management and the "features" that it provides on my machines.
In Qubes, I use a combination of AppVMs and StandaloneVMs for a variety of different purposes. All VMs use PVH over HVM, except for the Mirage Unikernel Firewall, which uses PV, and the sys-net and sys-usb StandaloneVMs which have to use HVM because of PCI device passthrough. Right now most of my VMs are AppVMs, but for maintenance and compartmentalization reasons, I am considering moving more towards StandaloneVMs, despite the increase in disk space and bandwidth usage for updates.
General route of from Qubes to the Internet for anonymous browsing, general private browsing, accessing Uni services, and Uni-related anonymous browsing respectively: 1. Qubes->sys-mirage-firewall->sys-vpn-wg->sys-corridor->sys-whonix->whonix-ws-15-dvm to the internet. 2. Qubes->sys-mirage-firewall->sys-vpn-wg to the Internet. 3. Qubes->sys-mirage-firewall->uni-vpn-wg to the Internet. 4. Qubes->sys-mirage-firewall->uni-vpn-wg->uni-corridor->uni-whonix->uni-anon-research to the Internet.

(Note: the VPN name is substituted in the "vpn" above. I had to remove it to comply with this subreddit's rules. It is easy to identify what VPN it is as it randomly generates a long numaric string and has fantastic support for WireGuard.)

Web Browsers: - Tor Browser (primary) in a disposable Whonix VM. - Firefox (secondary) with the about:config changes listed on privacytools.io and the following extensions: Cookies AutoDelete, Decentraleyes, HTTPS Everywhere, uBlock Origin (advance user, all third party content blocked and JavaScript disabled), and Vim Vixen. Used in my personal AppVM. - Ungoogled Chromium (Uni only) with standard uBlock Origin and cVim. Used only for Uni-related access in my uni-campus and uni-home AppVMs.
Search Engine: SearX, Startpage, and DuckDuckGo.
Password Manager: KeePassXC.
Office: LibreOffice.
Notes: Standard Notes.
Messaging: Signal Desktop.
Media Playback: mpv.
Emails: I access my personal email within my personal Qubes domain and my Uni email using my Uni Qubes domains. My emails are downloaded to a local repository using isync, send using msmtp, and read using neomutt with html emails converted to plain text using w3m. Emails are sent in plain text too. All of the attachments in the emails (PDFs mostly) are automatically opened in DisposableVMs.
My personal Posteo email account has incoming encryption setup. This means that I emailed my public GPG key to an address correlated to my actual Posteo email address so that all email that I receive is encrypted with my public key and can only be decrypted using my private key. So even if my emails were intercepted and/or my account broken into, the contents of them are safe since they are encrypted as soon as they hit Posteo's servers.
I have setup a number of Posteo aliases that are completely segregated from the email I used to register my account. One of those is considered my "professional" email for my current job. I have another couple aliases, one dedicated for 33mail and another dedicated for Abine Blur. I make use of 33mail alias addresses for catch-all email addresses for registering for accounts that need to be under a username associated with my name anyways. This is for purposes like putting different compartmentalized, but still related emails to put onto my Resume. I use a different alias for each Resume I put out online. That way, when that information gets sold, traded, etc., I can easily trace it back to who sold the information. For example, if I applied for a job online that required me to go through the process of registering an account through a third-party, say 'xyz Inc', the address I would register that account with would be [email protected], or something along those lines. Abine Blur is used much in the same manner but for accounts that don't need to be associated with my real name in any way, say online shopping on Amazon that I do under an many aliases, then ship to various address that I don't live at, but that I can visit with no problems. I use a different Blur address with each service like with 33mail for the same reasoning shown above.
The passwords for the accounts are encrypted and stored locally in each of the domains, however, my private key is stored in my vault domain, so even if an adversary were to compromise the domains, they wouldn't be able to steal my private key without exploiting the hypervisor. They would only be able to wait for me to authorize the usage of my private key in that domain, and even then, it could only be used to decrypt files. That is a concern that they can use my private key to decrypt messages, but they wouldn't be able to steal the key. With my personal email, the emails would also be encrypted locally anyway so they wouldn't be able to read them. My Uni email, in contrast, uses Outlook unfortunately, so there isn't any option to enable incoming encryption, and even if it was, I'm not sure how private it would be anyways.
For those looking for an in depth list of all my VMs, with explanations for the more obscure ones, I have listed them below. I have got a lot of templates, hence why I am considering moving over to StandaloneVMs, but as of right now:

Templates:

StandaloneVMs:

AppVMs:

Phone: Motorola Moto G5s running Lineage OS 16.0 Pie no G-Apps or micro-G with the following Apps: - AdAway: Open Source hosts file-based ad blocker. (Requires root.) - AFWall+: Linux iptables front end. (Requires root.) - Amaze: File manager. - andOPT: 2FA app. I like it since it can export the entries to an AES encrypted file. - AntennaPod: Podcast manager. - AnySoftKeyboard - Simple Calendar - Simple Contacts Pro - DAVx5: CalDav syncronization with my calendar on my Posteo email account. - F-Droid - Fennec F-Droid: Web Browser. Has the same Firefox addons like on Qubes minus Vim Vixen. I used the app Privacy Settings to configure the about:config. - KeePassDX: Password manager. - KISS launcher - Magisk Manager - NewPipe: YouTube app replacement. - S.Notes: Standard Notes. - OsmAnd~: Maps and navigation. - Red Moon: Blue light filter. - SELinuxModeChanger: Exactly as it sounds. (Requires root.) - Shelter: Work profile manager. - Signal: Messaging. - Vinyl Music Player: Music player. - WireGuard: VPN protocol frontend. Is configured to use my VPN account. Is setup as an always-on and connected VPN.
As mentioned, I use Shelter to manage my work profile. In it I isolate the following apps: - Clover: *chan browser. - Orbot: For routing apps through Tor. Is setup as an always-on and connected VPN. - RedReader: Reddit client. - Tor Browser
Over the last several years, I have started using my phone less and less and taking advantage of less of what it has got to offer. I don't check email on my device. I have no real need to browse the Internet on it outside of watching videos using NewPipe, browsing Reddit, and various *chan boards.
On the Smart Phone side of things, I am considering purchasing an older used iPhone SE or 6S for use with MySudo when outside of my home as well as an iPod Touch for use on WiFi only for use inside my home. The iPhone would be kept inside of a faraday bag when I am at home and not using it. It would also be kept in the faraday bag whenever at home to avoid associating that device with my home address. The iPod Touch would be used for MySudo calls instead.
Future outlook and plan for my privacy and security:
To avoid as much deanonymisation of my privacy as possible, I'm only going to specify enough so that anyone reading this can get the jist of my situation in life. I am quite young (age 16 to 25) and I started along this privacy journey when I was even younger. I was never a very heavy social media user, however I did have an online presence if you looked hard enough. My name fortunately is a very common and short name, so that does help to bury information that I was not able to remove further in the vast trenches that is the Internet.
On the digital side of things, I mentioned that I have a dedicated Crypto AppVM for handling crypto currency transactions using Bisq. I have setup a dedicated bank account that I have periodically been transferring money into so that I can trade crypto. Unfortunately, I do not live in the US, so being able to effectively start trades with others is more difficult. I also do not have access to a credit card masking account like privacy.com (that I absolutely would use given the ability). I plan on getting an anonymous VPS to host my own Tor exit node for better speeds and to mitigate the possibility of malicious exit nodes. The country I live in has been a proponent of absolute dragnet surveillance on all activities occurring online and in real life, though the former is far more visible on this subreddit. I will be using crypto with cleaned Bitcoin (as seen with ProgressiveArchitect's setup) for purchasing my VPN service, etc.
With future hardware, to replace my aging laptop, I am very hopeful for Xen, then eventually Qubes OS getting ported to Power9. When that happens I'll be getting a Raptor Computing Blackbird as a desktop. Maybe in the future I'll get a Purism Librem laptop, but for now my corebooted X230 works perfectly for my use cases. On that note, I have successfully build the Heads firmware for the X230 and I was able to get the minimal 4MB image flashed on my laptop. I did revert it back to my coreboot setup after playing around a little with it, and unfortunately I haven't had time since to do a full, complete flash of it.
On the physical/real life side of things, I plan on making use of various Trusts in order to hold assets, say to keep my name from being immediately visible on the title of my car. As of right now I am fortunate enough to have the title of my car under the name of someone who I trust. Unless I am legally required, and where there are immediate and absolute consequences, I use fake names in real life. With Uni, I am enrolled under my real name and address. This is a requirement and it is verified, so there is nothing that I can realistically do about it. As for other services, I plan on setting up a personal mailbox (PMB), etc if possible to use as a real, physical address that is associated with my real name and that is used for things like Government issued ID. In the future when I move again, I plan on renting a place in cash to try and keep my name dissociated with my real address. For those looking for reasoning on why one would want to do that, please read How to be Invisible by J.J. Luna. It's truly the Bible of physical privacy.
At this stage I am just going off on a ramble, so I should cut it short here.
I have just started and I live for this shit.
submitted by ComprehensiveAddict to privacy [link] [comments]

Ultimate Software Verification Gude - Never get Hacked or Phished again!

Due to the amounts of scams and phishing websites and malwared softwares, I made this quick easy to understand tutorial how to verify that the Bitcoin Cash software that you use is legitimate.
The core concept is that you should not rely on any 3rd party to prove the authenticity of files, not even this text, because any website can get potentially hacked so just do all the verification by yourself, as much as you can. It might be a longer work every time you update the software but it's worth it, since the alternative is being a victim of theft.
 
There are 3 ways to verify the authenticity of the software you download:
 
 
 

EASY WAY

In case your IP address is specifically targeted it's advised to have a VPN connection at hand too, and do the verification both on your VPN and on your clearnet IP. I am using Firefox for this example and you should too. This method can be used to verify any website you want by cross-examining their authenticity against eachother relying on 3-4 more or less trusted authority figures.
What you would do is just use 3-4 different search engines that you more or less trust: DuckDuckGo.com, startpage.com, bing.com, wikipedia.org.
Open each search engine in a different tab in your browser, and enter in each one of them the software you search for, in this example "Bitcoin Cash".
In the first search results you will see a link to the supposed bitcoin cash official website (on wikipedia you will just see the link at the right side of the article about bitcoin cash), click on that link from each tab and you will have the official website opened in 4 different tabs.
Now the websites might look the same, but they might not be the same websites, since the connection could be hijacked so you could be on a fake website.
In order to determine the authenticity of the website, click on the green lock icon in Firefox before the HTTPS mark, click on More Information, and click on View Certificate, then you will see there a SHA256 fingerprint, paste that into a text file.
Now go to the other tabs you have opened the website in, and put that SHA256 fingerpring in the text file itself.
Now see if all 4 of them match in the text file by pressing a CTRL+F and copying it in the search box. If they are the same, then you are very likely on the official website, assuming that all search engines remove phishing websites quickly and wikipedia is not hacked.
You might also want to redo this verification from a different IP address in case you think a hacker is speficially targeting your IP address.
Now just download the software from the genuine official website and you are ready to go.
(Note I am not giving you the fingerprint I got from my verification so that you don't have to rely on my authority, you should do the verification yourself!)
 
 

MODERATE WAY

You have to know how to use GnuPG software. I would use a Linux machine for verification since it's very easy to do it there. You can always burn a quick Live Linux DVD and boot that up to do the verification. Just watch some videos to learn how to do that, I assume you already know how to do that.
Now regardless of whether the website is hacked or not, we only care about the software itself here, and if the verification is done properly, any discrepancy can be detected regardless of the website itself. A website can be far easier hacked than an offline private key used to sign softwares, so this method is much more secure.
Every Bitcoin Cash software is usually signed with a GPG key. The issue here is to verify the authenticity of the key itself, once you have that, you can verify any package with that, regardless of source, assuming the developer is honest, so it's not fullproof, but good enough.
Going with the example above you download the Bitcoin Cash software or Electron Cash or whatever, and you grab the software file, the GPG signature file and the GPG Public Key. Then import the GPG key gpg --import keyfilename.txt for example.
The only thing you need to do is to verify the GPG Public Key itself. Let's go with Electron Cash in this example.
Fyookball (the lead developer)'s official key is allegedly 0x4FD06489EFF1DDE1. We don't know if this is true or not, we can either e-mail him directly, but then who knows his e-mail could be hacked or whatnot, so we need are more extensive verification here.
Each GPG key has a fingerprint which is your main point of reference, so the fingerprint you got for the downloaded key, which you can see in SeaHorse or by entering gpg --fingerprint 0x4FD06489EFF1DDE1 in a linux console after you have imported the key.
You need to create a web of trust, enough reputable people vouching that this is indeed his genuine key, usually relying on people who have either met him or has extensively verified his identity.
So we look the key up like in a phone address book, on the MIT server: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x4FD06489EFF1DDE1
Also it's recommended to install Gnome Seahorse, a gui interface to manage GPG keys: sudo apt-get install seahorse
It appears to be signed only by 2 people, I don't know them, but if you do and you have their keys too, then you can rely on their authority to confirm the authenticity of the key.
If by the time you read this, the key will be signed by a trustworthy person from the broader Bitcoin Cash development team or some other well known entity, then what you would do is grab their key (and verify it) and in SeaHorse set their key to Trusted.
Then automatically in Fyookball's key, the other people's signatures will show up, proving that other trusted entities who's keys you have already verified have signed this key, so on their authority you could trust Fyookball's key too.
For example in Bitcoin ABC and other softwares, this is the case, unfortunately not for Electron Cash yet.
So the only thing you can do is grab and verify fyookball's e-mail address, and message him and ask him his GPG key's signature.
I have already done that so based on my authority his key fingerprint is: D56C 110F 4555 F371 AEEF CB25 4FD0 6489 EFF1 DDE1
The only other place that has the key referenced is Github, so you have to rely on their authority to host the genuine key and not get hacked in the process.
There is only 1 electron cash repository which is a fork of the original electrum software: https://github.com/fyookball/electrum, again you could verify the authenticity of Github.com based on the previous method, but there is only 1 repository for Electron Cash so it's not hard to find it.
There you can see the public keys in a separate branch: https://github.com/fyookball/keys-n-hashes
It's not a lot of evidence, so I hope in the future more people will vouch for it, but for now this is all we have, for other softwares you can find a more extensive web of trust.
So after you established the legitimacy of the key, just save it or write down the fingerprint on a piece of paper and put it in a safe, and from then on you can verify any new Electron Cash release against that.
Simply just verify the signature file for example for the latest release: gpg --verify ElectronCash-3.2.tar.gz.sig
And it should give back the fingerprint of it, if the fingerprint matches the one of your verified key, then the software is genuine. But again this relies on the assumption that fyookball is honest, which in my opinion he is, he is a trustworthy developer.
 
 

HARD WAY

The ultimate way to verify the trustworthyness of a software is to:
  • Download and inspect the source code yourself
  • Compile the software from source
  • Verify the output against the downloaded package (verified by the previous step)
This is very complex, but if you want to have a fullproof guarantee that the software is genuine and untampered then this has to be done.
It might be a bit paranoid but dozens of malware clients come out each day, most of them have sneaky code in them that sends out your private key like in this example:
If the developer is both shady and the source code doesn't match the binary, then you can easily get hacked and lose all your money.
What you need to do to be fully secure in a fully trustless verification model is the following:
 
1) Do the previous step for verifying the signed package with the developer's genuine public key, all verified. So now you have an output package that is tied to the developer that is allegedly derived from the source code securely, assuming the developer is honest, and is compiling it securely. So in this case the risk is limited only developer malice or negligence.
2) Download the source code, from the main website, it should be correctly downloaded, so just download it multiple times to verify that the package was downloaded correctly.
3) Inspect the source code yourself or pay a programmer to do it. Especially watch out for the sensitive parts of the code, like the part that does the encryption and the part that does the communication. You should make sure that the private keys are never sent out. You could also use a network inspector software and test whether the private key is sent out.
Now if you have verified that the source code is genuine, then assuming that Github is honest, many other developers will verify this too, so we can establish that the source code does exactly what it meant to do, with no backdoors.
4) Now you need to compile the source code and make it identical to the package you have just verified previously. Determinism is crucial, the package must match the source code 1:1.
Now there may be some config files or cache files that will not but that is not an issue, the Electron Cash software is very messy so there will be a few files that will not match but usually it should.
Open the README.rst file in the Electron Cash source code to see the instructions how to compile it for different OS's. By default I recommend Linux because it's easier to work on.
5) Now that you have a compiled source code folder, every single file in it should match the signed output package you have verified it earlier.
Now you can write a quick code to parse through each file and check for discrepancies. You are lucky because I have already did it:
Download my script, unpack both archives in the same directory and put the script there too and make sure the root directory ElectronCash-3.2 is where the files are, sometimes it might be ElectronCash-3.2/ElectronCash-3.2 depending on how you unpack it with the archive manager.
Now run the python script, and it will show you exactly which files don't match and which files are missing.
Ignore the missing files, in fact just delete them from the other package where they are, since they are surplus files. The script verifies the untrusted package (the one you verified previously, yet untrusted because we don't know whether it's derived from the source yet)
The missing files can't cause problem because they are just extra files put in the output package, if they don't exist in the source, then they are harmless. So just delete the missing files and you are left to deal with the corrupt files.
Also do a search for .pyc extension files and delete all of those too, these are just cache files that get recompiled every time you run Electron Cash, so they can't be malware.
And there are the corrupt files which are modified. Now this could be due to some discrepancies the way the compiler worked or it could be a backdoor we don't know, so we need to verify each corrupt file 1 by 1.
6) Now we need to verify each corrupt file one by one and see the discrepancy.
Get diffuse, which is a simple tool to look for differences in the code:
sudo apt-get install diffuse
Open both of the same named files in it and check out in each pair the differences. Usually it will just be a few misc stuffs so in that case just copy 1 difference over to the other and make them identical.
Do this for every corrupt file pair, and check whether any malicious code was added.
After you are done run the script again and it should give out Packages are Identical!
If you get that, you have now verified beyond the reasonable doubt that:
  • The source code is genuine and secure
  • The package file is certainly created by the developer and based on his reputation it's secure
  • Your compilation is secure
  • Your compilation mathes deterministically the source code
  • Your compilation matches the package file provided by the developer
Therefore the softare is secure and genuine and hasn't been tampered with.
I have verified the ElectronCash-3.2.tar.gz file with the HARD WAY and based on my verification the SHA256 checksum da355ac3d198750e01acb8f1ada82c4d481036bee36fd9d3e2fdff972d9fc082 is genuine.
But don't rely on my authority, verify it all yourself. That is the whole point of the trustless setup.
submitted by alexander7k to btc [link] [comments]

How-To: Building an offline cold wallet with a Raspberry Pi, Pidora and Electrum.

After piddling with Bitcoin for ~2 years and seeing my balance wax and wane, I find myself with a dollar value now in the low 5 figures. Small for some, but still enough to make make me grin like an idiot...
However, while I run Linux everywhere, and have multiple encrypted backup copies of my wallet seeds and private keys the chance of getting hacked is (while small) not zero. More importantly, the odds of fat-fingering a transfer and sending someone 1000x what I intend are far more likely. So I just spent a couple of hours installing Electrum onto my Raspberry Pi, and testing it out. Seems to work. :)
Required:
Installing the base OS:
Your setup of the Pi is now complete. None of the secret information for the wallet has been generated yet, so even if something got in as you built the platform, as long as you never connect it to the network again, you should be secure.
Electrum setup:
Your offline wallet is ready. Now you need to set up your online wallet.
Online wallet:
Your online wallet is now ready. You have public addresses in the online watch only wallet that you can use to fund the offline wallet. To move funds from the offline wallet, do the following: (Blatantly stolen from http://electrum.org/tutorials.html#offline-mpk)
Performing an offline transaction:
That's it. Enjoy.
1grnbrg3Ea4t6bxHvQKRvorbBeLNDXv2N
EDIT: Added instructions to add "--offline" to the Electrum launch icon on the desktop.
submitted by bgrnbrg to Bitcoin [link] [comments]

SR1 trial: DPR's private key

One of the released evidence exhibits (torrent, 538MB) is GX 296.pdf (mirror), which is a PGP private key, specifically: SilkRoad.asc, "dated modified 11/22/2011 8:21:46 AM".
This is the ASCII-armored private key of the main DPR public key, the one he signed forum posts with and messaged with people. I was surprised to see it screenshotted like that, and I thought it would be hilarious if I could take the private key and announce that I was actually the real DPR by signing it with his key (since I've occasionally been accused of it).
But it's a screenshot and not something one can copy-paste, which makes things difficult since every letter has to be perfect for the key to be valid. So I took an evening to carefully transcribe it; it took multiple passes to figure out each and every transcription error (mostly 1/l, O/0, which look nearly identical in the font*), but I finally did it:
-----BEGIN PGP PRIVATE KEY BLOCK----- Version: GnuPG v1.4.11 (GNU/Linux) lQO+BE2VWMwBCADcoI5qldde46EI80fHSTCS4CuJn1Py4AQjJvpAqFColeAm9xb1 /hb0ZUsG3vwod7uiPJdMlq3+1o3TSv9JlO3DPf7I50owQ9+S1ixXebouTvfpEKSb dq1IWAu+O4PtlmFEb76MOmjOzoeV8We8kCRFq8ThoK979A1DR09KsaDfSjCITdsU mQyVaRN0dCaj33V/QAPQybYAjNDEiNd0e1tV22n1dl6z2oVUgfJiuTVI5C0FhSKP c3odexbKUSVk9tkUWcfnk8+9HF5jGNHnUSjWxMkG1uZUDdWKl4yJqQhBHdYqcz8A hcJ6xADbFeoYEO6z5NEjXV0KmoDRCi4C7gdfABEBAAH+AgMC7Hbd7rIjH9vHfrZp /lhwGpLJknlcg/xD4nhaFtrlAVW5Lqn/oL/JqXKX6buPMGWsqrc+E/7A1ZMMHTl0 bn99MSQi1mTkCVyJP4xTpKouLmLIxvzy2/GOMGS03QX8iSzbE4j0el/c5YlYEQr4 genr8Xq9Iyv73W+1n+yOQvJ9PqaMFdyAZLIdNuEgBzvXSt00a5bLKjbL/KuoTdrA C3D1bc0HDlKnzVLcSAFat+y6A5B4EuI/d1oW2Id1tq3azuUpEb9ctG26sYtw7ipE edNjcwsO9XA+vNTnPy9ms698yf615Bwioih5FYNM3Vsqc1zLpv5XwdYWWRW4WRIW xiqqgv6oGh6+HU9XMV937+1VNDf4k4sNXECjxQ4B0MX/F5eWEsfIlqt4V2HMEDE/ eQ0zQbVRhf2MBJ6n6Vw6DDEUEv+4Dn9CUdYSyJPsK7/0JLO/VnKoPqvwhq+p7hZ4 JMHPWwFoMsT3Nuj15Nk3CrgDGE9C6GSyP88BTnSbgyqe9erFHXTOm80r6OfKpDVB h8/nt7iCFxlPcTLqkUoZf1ZwmlJCSD5fB9/yaAwTc3klFdkiPe0ZFODa/aLOqZrG AoYLsPMt9fntzrnXfwsTthkBxDSFiTxxxlRe1eQeRlALO2Bm5Qfn6jRGhrIraX RksscWcFWptjVlm9CDr2al7otX/RPqFjX3uiJMZfBFoYDmb49xdGaptlMCHaD6Wm XJFb4Wiu1ovERN38AT6IxXFPmPJw6SKrSmVeV5Pmn9+SHtfjAA+st0EMGhzBtW2N uZr0wwO1/EcrzaOP4So7n7IqmG3nKafibY2q5Occn/BHqvTKaik+q4b6a/vVdTtl Erp3hXlGk/6UpBLT5RYbU4p7WLGAj5r8DAyH0kI1+tcCxBKD9WVLSFzYqH9Ea59g 77QkU2lsayBSb2FkIDxzdGFmZkBzaWxrcm9hZG1hcmtldC5vcmc+iQE4BBMBAgAi BQJNlVjMAhsPBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRACIkI7Z7f6JV/P B/92DrCPpqfzF6EPu1g6Mxt/39EAosKr4YwmVE5DuY+g6pR2dOtDfvkt3QxQkURB QeyaKOQNuXus4vDQi4kcmzHD3DLmc0A0wQzGOyl0a+LwdqUOtckL4SIPbEzSDP9e sOZOweGkBkSDB13KBkW4fFbDGkEcYHZyUt/jFgxflMLtnxAksR1fH0NbmZnUr1e4 L7p+QylRuXOhGLObOTU0n7KDbuZijgqKDKyV6yEXfLJDrZqzlqmoh+DJisn+53Br glDwt7p3MHR3ejyausNeodK7FJ0sY0uHUHuUOmF2xDGvHVb/jrwS5sb7k8YMuq ptRgsMLFLebgM3jrCg78g23k =D+ez -----END PGP PRIVATE KEY BLOCK----- 
This imports into my GPG without any CRC problems and with correct metadata, so it should be right. But it turns out to be passphrase-protected! Dammit! My first try to decrypt it was to take the server exhibit, write down every password given in it, and try those:
109j7IAier 2n3fh4n3o 2t31fKF5hm 2WBx5obj 34534r3f 384jdridh 3j483r87yfn38 _47JB+p1\j}[email protected](L[nZ)#W- 4B5HMiJYy0N0bbK5 4pVAW9bv 4W8IWDjInLguJD8T 83drj3984 8pz2PGGEmn3h3hGJ 8sa7dhf8a7 938ru39 9MPGCtBK abrault66 abstractapproachfillsthemindwithjoy acharlton66 achrlton66 ameeraissa66 [email protected] [email protected] bTyL5RbC cbrady66 cdigby66 dboone66 dFDrN345DSftX dQsQRighnXczcphJ dsmith66 dwallace66 dwiurhi37n EgXcn1ANYF eK5nJgfDqERQ3K96 fahu6wq4ue fwarren66 gboyle66 gtilly66 hallahaa hR6vpCxaGY HuKKtaoLLa hulluh832 J39hlF4n Je)pae]yuxeif7xi jknCRfR3yq3hbtzp k8JqM7Cijw kborunda66 kclark66 LaQXhcURAGMME3gq lmackrell66 lzielinski66 mgatewood66 nlbosm42093 nsj8jdke oh3bdc8wcn rlvrGdex RPGLdgjjveBtHpEN SD8rcicL sfa76ht7 sofas-qxsch sums-XATq86P the2Fieshaqu tkiW23GL U5f305OX Uha4zFYo v6ay080942 w732ihrw7e w8j374847dhw wefi7y4mwh wjBSGHvfEQdfh9oZ x4TiJfRE XUVYNGBgvu7fb5Hw yMrEATSQ7BsBEouV zFAvzSBUXcC0 zS08HbISvSZcB5Ex 
None of these seemed to work for me. (imposter also tried the Elcom dictionary +0-9, 6-9 characters, alphabet, lowercase.)
So then I turned to a password cracker, specifically John the Ripper (WP), whose bleeding-jumbo edition I compiled with OpenCL (so it could use my wimpy GPU, which for Bitcoin mining could do something like 50mh/s); John doesn't handle GPG natively, but it apparently does ship with a tool gpg2john to convert the passphrase hash to something it can work with, which yields:
Silk Road:$gpg$*1*668*2048*c992795c83fc43e2785a16dae50155b92ea9ffa0bfc9a97297e9bb8f3065acaab73e13fec0d5930c1d39746e7f7d312422d664e4095c893f8c53a4aa2e2e62c8c6fcf2dbf18e3064b4dd05fc892cdb1388f47a5fdce58958110af881e9ebf17abd232bfbdd6fb59fec8e42f27d3ea68c15dc8064b21d36e120073bd74add346b96cb2a36cbfcaba84ddac00b70f56dcd070e52a7cd52dc48015ab7ecba03907812e23f775a16d88775b6addacee52911bf5cb46dbab18b70ee2a4479d363730b0ef5703ebcd4e73f2f66b3af7cc9feb5e41c22a2287915834cdd5b2a735ccba6fe57c1d6165915b8591216c62aaa82fea81a1ebe1d4f57315f77efed553437f8938b0d5c40a3c50e01d0c5ff17979612c7c896ab785761cc10313f790d3341b55185fd8c049ea7e95c3a0c311412ffb80e7f4251d612c893ec2bbff424b3bf5672a83eabf086afa9ee167824c1cf5b016832c4f736e8f5e4d9370ab803184f42e864b23fcf014e749b832a9ef5eac51d74ce9bcd2be8e7caa4354187cfe7b7b88217194f7132ea914a197f56709a5242483e5f07dff2680c1373792515d9223ded1914e0dafda2cea99ac602860bb0f32df5f9edceb9d77f0b13b61901c43485893c71c6545ed5e41e46500b3b6066e507e7ea344686b22b697aff464b2c7167055a9b635659bd083af66a5ee8b57fd13ea1635f7ba224c65f045a180e66f8f717466a9b653021da0fa5a65c915be168aed68bc444ddfc013e88c5714f98f270e922ab4a655e5793e69fdf921ed7e3000facb7410c1a1cc1b56d8db99af4c303b5fc472bcda38fe12a3b9fb22a986de729a7e26d8daae4e71c9ff047aaf4ca6a293eab86fa6bfbd5753b6512ba7785794693fe94a412d3e5161b538a7b58b1808f9afc0c0c87d24235fad702c41283f5654b485cd8a87f446b9f60ef*3*254*2*2*8*7eb669fe58701a92*6029312*ec76ddeeb2231fdb:::Silk Road ::/home/gwern/sr.asc 
I think one could also try pgpry but I didn't since I got john up and running before I saw it.
Since the server passwords failed, and I saw a variety of characters and capitalizations, I had john do bruteforce:
john --format=gpg-opencl --incremental=ASCII sr-hash 
I ran it for about a week, and finally lost my patience. I was hoping it'd be like one of the short passphrases in the server password list, which would have been bruteforced by now. I wound up ending john at
0g 9:13:13:11 0g/s 74.14p/s 74.14c/s 74.14C/s dsssii..dlshk2 
(john.log, john.rec)
Oh well. It was worth a shot. Not everything pans out.
But maybe someone with a GPU cluster or better at password cracking wants to give it a shot and reveal the passphrase? I can't pretend to be DPR after posting this, but it would still be interesting to go back and decrypt some of the messages to DPR on the SR1 forums. (Why should LE have all the snooping fun?)
* these characters also mean OCR is not very useful for transcribing crypto keys; every character has to be perfect, so since you're going to be going character-by-character anyway... One thought I had was that the right key was only maybe 5-10 edits away from the OCR version or my first hand-draft, so it should be feasible to brute-force all versions within a certain edit distance to see if their CRC is right or brute-force specific transpositions. But I don't transcribe keys nearly often enough to bother writing such a tool.
submitted by gwern to SilkRoad [link] [comments]

A helpful discussion about wallet security (esp. Electrum)

I was recently contacted via private message by a redditor who read a comment of mine about wallet storage (I assume this comment). I think there was quite a bit of useful information in it for other bitcoin beginners, so I am reposting it here in full (with permission). The redditor in question wanted to remain anonymous though.
I hope this is of use to some of you here!
From: Anonymous Redditor
I saw your post regarding your wallet storage and had a few noob questions if you don't mind.
My plan is similar to yours but I was unsure whether to use armory or electrum (electrum's seed creation scares me a bit).
You mentioned you have a bootable LINUX (ubuntu?) USB stick that you keep your wallet on....do you only boot this onto an always offline computer?
Do you use something like Truecrypt to further protect your wallet.dats?
Thanks for your time!
From: SanderMarechal
My plan is similar to yours but I was unsure whether to use armory or electrum (electrum's seed creation scares me a bit).
For me it is the other way around. Armory (and bitcoin-qt) scare me. Armory is just a wallet. It still needs bitcoin-qt running in the background. For me the problem is two-fold:
1) Size
bitcoin-qt (and armory) need to download the entire blockchain. That 13+ GB that takes hours to download and days to verify. And if you ever lose it, you need to do it again.
2) Random keys
armory and bitcoin-qt generate random private keys. You get 100. If you use a few (you use them when you send coins for example) then new ones are created. So, if you create an armory wallet and make a backup, that backup will have 100 keys. Then, if you make 33(!) transactions, your 100 keys are used up and you will have 100 different random keys. If someone then steals your computer (or your house burns down) then you cannot use your backup anymore. It only has the 100 old keys and none of the new keys. So you have lost all your bitcoins.
Why 33 transactions and not 100? Because of change addresses. If you have 10 BTC and send me 2 BTC then most wallets will create 2 transactions. 2 BTC from your old addres to me, and 8 BTC from your old address to a new (random) address. This process costs 3 private keys. 2 keys for the transactions and 1 key to create a new address.
This means that after every few dozen transactions you need to refresh your backup so it has the newer keys. For me that is impractical. It means that I need to keep my backup close by because I often need it.
Electrum does not have this problem. The seed solves this. Private keys are not random but are created from the seed. If you have the seed then you have, by definition, all the private keys you will ever need. Your backup can never be out-of-date. This is easy for me. I save the seed in a file, encrypt it, put it on an USB stick and give copies to a few family members who have safes in their homes.
If my computer is ever stolen, or my house burns down, I can go to a family member, decrypt the seed file and use the seed to restore my electrum wallet. Even if that USB stick is 10 years old.
You mentioned you have a bootable LINUX (ubuntu?) USB stick that you keep your wallet on....do you only boot this onto an always offline computer?
It depends on how secure you want to be. For maximum security, keep the computer always offline. But if you want to spend the bitcoins from your wallet, you will need to be online.
I use the USB stick for my savings account. It only receives coins and I do not send. So I do not need to boot up my USB stick. I have created a second wallet on blockchain.info that I use for day-to-day transactions. All BTC I receive goes to my blockchain account. Then I transfer a part of that to my savings account and only keep a bit of change that I need in the blockchain account.
Do you use something like Truecrypt to further protect your wallet.dats?
No. Electrum does not have a wallet.dat. It has the seed. I simply copy the seed to a TXT file and encrypt it using GPG and symmetric encryption. Example:
gpg --armor --symmetric --cipher-algo AES256 seed.txt 
Make sure you use a password that is strong and that you cannot forget! If you need to write the password down on paper and your house burns down, then you cannot decrypt the seed anymore!
From: Anonymous Redditor
Forgive the naivety here: Correct me if I'm wrong - The safest way to generate your wallet seed is on an offline computer correct? So, theoretically, generate the seed on an offline-only computer, copy to txt...encrypt. back up on multiple USB's. Then on your online computer, load electrum and import Seed?
Thanks so much for the thorough explanation! I'm a potato when it comes to reddit's bitcoin tip bot. Send me an address - would like to send some internet magic money your way.
From: SanderMarechal
The safest way to generate your wallet seed is on an offline computer correct? So, theoretically, generate the seed on an offline-only computer, copy to txt...encrypt. back up on multiple USB's. Then on your online computer, load electrum and import Seed?
Not quite. The risk with an online computer is malware and people breaking in. If you generate the seed on an offline computer and then move it to an online computer, you don't really take that risk away. You still have your wallet on an online computer which you use for day-to-day work and which is exposed to hackers and malware.
I suggest you make two wallets. One wallet is your "savings" wallet. You can use the USB stick Linux for this. Generate the wallet offline, backup and encrypt the seed onto multiple USB sticks and note down the bitcoin address somewhere so you can transfer funds to it. The only time you should use the USB stick to go online is when you want to transfer funds out of your savings wallet.
The, on your normal computer (or your smartphone if you prefer), create a second wallet using a different password. This is the wallet you keep only a little money in for your day-to-day transactions. Note down the seen, encrypt (with a different password than you used to encrypt the seed from your savings wallet) and add it to the USB keys. You can use Electrun for this second wallet as well, but you can also use something different. I use a blockchain.info wallet for my day-to-day expenses.
Whenever you have a larger amount of bitcoins in your day-to-day wallet, transfer some to the wallet on the USB stick. You don't need to boot up the USB stick for this. You only need the address you wrote down.
When you want to spend a large amount of money, boot up from the USB stick and transfer coins from your savings wallet to your day-to-day wallet. Reboot into your normal computer and use the day-to-day wallet to pay for what you wanted to buy.
The core of the issue is simple: Don't store a lot of money in a wallet on a computer that you use a lot. Computers that are used a lot get attacked a lot. Simple :-)
Thanks so much for the thorough explanation! I'm a potato when it comes to reddit's bitcoin tip bot. Send me an address - would like to send some internet magic money your way.
That is very kind! My address is: 1PAXiscvKoGRJ5XxMZvri3CMNeKYYb8wMQ
From: Anonymous Redditor
You are awesome:) Thank you again for the insight! Sent some your way.
From: SanderMarechal*
Your welcome. And thanks for the coin!
From: Anonymous Redditor
Last question(s) (I promise)...
Would a netbook like this be appropriate to 1)dban 2) boot up via USB ubuntu and 3) create the electrum seed?
This would of course never go online, be backed up and encrypted, etc.
http://www.newegg.com/Product/Product.aspx?Item=N82E16834131403
Thanks again.
From: SanderMarechal
I don't know. You would be better off asking this on www.ubuntuforums.org for example. I don't know if that computer's hardware is compatible with Ubuntu. Speed-wise the bottleneck will be the USB stick and not the CPU or memory. USB sticks are much slower than hard drives.
Note that you don't have to buy a computer for this. You can use the computer you already have and still run Ubuntu off an USB stick for your Electrum wallet.
What I said in my previous post about not using your day-to-day computer for your wallet, with that I mean the operating system and software. Not the hardware. Unless you're afraid someone put a hardware keylogger inside your computer :-)
From: Anonymous Redditor
Fascinating!
My tin foil hat is in full effect:) Thanks again for your time and patience.
From: SanderMarechal
Your welcome. Have fun with bitcoin!
Oh, I have a question for you now. Would you mind if I repost our entire private conversation here to /BitcoinBeginners? I think other redditors there would also be interested. And if I can repost it, do you want your username in there or should I replace it with "Anonymous Redditor" or something?
From: Anonymous Redditor
You can certainly repost it! And yes, if you wouldn't mind removing the username I would very much appreciate it.
Thanks for asking btw!
Anyway, I hope this is useful for some people out here.
submitted by SanderMarechal to BitcoinBeginners [link] [comments]

[Warning] basically every https site was vulnerable, every coin/bitcoin server was vulnerable too. Update private keys and certs.

Better summary and implications of same news, because I will ask mods to sticky this important warning.
Please, do copy this summary to other coin's channels subs; this is very wide spread bug affecting many projects.
There is a huge bug that causes most programs that do encryption like https, or bitcoin-API, or secured IRC, or many communicators, possibly also emails - to be vulnerable (links below)
Attacker could easily steal your identity, your passwords, your private keys, read your data from such programs, on most (all?) operating systems.
Fix is released just now, at least for linuxes, e.g. for Debian.
What to do about it.
  1. do not panick.
  2. If you run any https website - pool, exchange, download site with coin (e.g. bitcoin, dogecoin) software, forum, wiki, web wallet etc - you should consider past keys to be compromised. You should generate new SSL certificates. You should at some point get all users to reset passwords in secure way.
  3. If you USE any https website - pool, exchange, all of above, then you should make sure owners upgraded AND USE NEW CERTIFICATES. Otherwise it could be easy to hack such service with your data/money in it.
  4. If you use bitcoind/dogecoind (same for all coins) and possibly some of other clients/wallets that would open SSL even to localhost, then if you ever had non trusted program, local user or anything then you really must, and otherwise you should, consider the existing addresses as possibly burned.
To be really safe you should move the money carefully to new addresses, from new wallet (to not use the previously pre-generated pool of addresses etc).
You decide, if that is just few bucks worth of currency then maybe not, and if you have thousands euro worth then you will probably want to move this coins.
  1. communication channels like emails, IRC, IM (jabber and others) also were potentially exploited. Responsible operators of such servers should issue new certificates for their services, and ask you to reset passwords. For some time you should perhaps trust a less communication over this channels.
Luckily best methods already are prepared for "server got owned" scenarios: on jabber we have OTR encryption (didn't yet doublechecked if it is secure, but afair yes), and on irc #bitcoin-otr for example we had the bot requring GPG signed messages adding layer of protection.
LT;DR: demand upgraded certs in services you use, if you have (or plan to have) considerable amount of coins then you better move to new wallet (after upgrading system) and be more carefully about https, irc, chats etc.
Links:
Nice site describing the SSL bug in depth: http://heartbleed.com/
Bitcoin insightful technical discussion: http://www.reddit.com/Bitcoin/comments/22gquw/psa_vuln_in_libssl_allows_to_read_64kb_of/
Debian on some aspects of debugging this bug on linuxes: http://www.reddit.com/debian/comments/22gshl/critical_vulnerability_in_libssl_allows_to_read/
Mempo's (secure private linux) report: http://mempo.org/memposec/issue2.html
submitted by rafalfreeman to Bitcoin [link] [comments]

GPG instructions and public key list for verifying Bitcoin clients.

I have noticed their is a growing problem of fake bitcoin clients, and I expect the frequency and elaboratness of these fake clients to increase.
Verifying the signatures for these clients will detect if you are receiving anything other than what the signer the of the software signed. The exception to this is if the attacker acquires the signer's private key, which should be a lot more difficult than tricking users to visit the wrong site or hacking servers. This can also be addressed by using multiple signatures per client.
An important part of this process is acquiring the public keys for the sofware signers in a secure manner.
To help with this I have included a signed list of fingerprints and where to acquire the public keys to act as another source to verify the keys used to sign bitcoin clients.
I have also included instructions for verifying the fingerprint list and bitcoin clients.
To deal with the issue that posts and comments on Reddit can be easily modified I suggest other users (especially well known ones) post a signature of the fingerprint list in a comment in this thread, or at least a hash of the fingerprint list (not as secure but still better than nothing).
List of Fingerprints:
+++ Bitcoin-Qt: Signer: Gavin Andresen (CODE SIGNING KEY) [email protected] Fingerprint: 2664 6D99 CBAE C9B8 1982 EF60 29D9 EE6B 1FC7 30C1 Key ID: 1FC730C1 Key Link: bitcoin.org/gavinandresen.asc
Electrum: Signer: ThomasV [email protected] Fingerprint: 6694 D8DE 7BE8 EE56 31BE D950 2BD5 824B 7F94 70E6 Key ID: 7F9470E6 Keyserver: pool.sks-keyservers.net Signer: Animazing [email protected] Fingerprint: 9914 864D FC33 499C 6CA2 BEEA 2245 3004 6955 06FD Key ID: 695506FD Keyserver: pool.sks-keyservers.net
Multibit: Signer: Jim Burton (multibit.org developer) [email protected] Fingerprint: 299C 423C 672F 47F4 756A 6BA4 C197 2AED 79F7 C572 Key ID: 79F7C572 Keyserver: pgp.mit.edu
Armory: Signer: Alan C. Reiner (Offline Signing Key) [email protected] Fingerprint: 821F 1229 36BD D565 366A C36A 4AB1 6AEA 9883 2223 Key ID: 98832223 Keyserver: pgp.mit.edu +++
My Key:
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.12 (GNU/Linux) mQINBFLB9nUBEAC/klZvqQkWP/NUD0pT09PzhKh0xIQ0XM7MxqUZLa1OytF3iUCX /fNwQD5OnSFQoEg1O4bGzrrRb+PiuKCvH19dp7sFVj3q7Dhwfb6EvsX39xqzxCr6 2AQFQ3esz4nNodnQWa48t2ujihaf/vpTn6n7+jCl6a124r+U4wNGiNIEWxLLUNNb ec8S1RcjtTp6Ue/yRpThgJN9e4rj19+vJMqKCiqL03NBZWVoCEkL6iIdjwlQK8/r CpP9m5yAsc8wkelRkZvuLmjJ1GgSFrO0WteGnURMshy59LetaSRyiIDeHaPdV5rk /n3mBv8hsK/39O6H7fYWDx/ZLnZE4rMghcndexIFLhsuPx6FJNATqQ2gHT4ijb8K NlwZ0LatlXyUEMKfC1aroa3/9RkQSf0y0GKS0XrvUWGVRn/X7gk1DRhuaHWuacCf k3w0XZOA2WpWw1w/rjZSeHbKG1w4B2/kWH3K4sXsfcLltlY85zH03HUYSx+leMFc yxiHz60ZfuV2aGjYFPL8dzF6DS106lHz51j608OZkAEO8Xssincii1k/PR1h1y2P AqgrEADzgl52iBbNw+tdnxSAIy/asEyxU/VwkUFjOzSyP7ZmBxg8ss966w2Kl6WE o9R5tkVuUG8WTMTnF0FeMxO9YOqx4KhN9bhP7RjBL7BFTvRXYVVJUGabIQARAQAB tBVkY2M0ZSA8ZGNjNGVAZ214LmNvbT6JAj4EEwECACgFAlLB9nUCGwMFCQlmAYAG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJECO6L0dAOWOhsNIQAKUN9Z4e0hM3 DbaUjYJx93JGdJArLmz+Ko10N/lGcao4lCNVA+xM73Ga1GBnPlhPFW9iD2VQocOv tY2PYNsPrHgGlzyMKAMSpZ8364wVEyCHdJVKFORUjhyuJGYfyhDt2iZuzQwxWbmQ 1gmlbiGvxRysmaSW5+M8CDhja/fI8+EOp5NbH/EvHJClul3cO72UBUXBPxRv4Eb+ j8k0Uozob70A3bD894F8bJ9wZ3XBX/9DEkAbvDyW7CxIZwUiCeYTQylH++8S91A1 wL3z35ELdOLzGqwetYY6gSZRwY/W+rewEfPfBDSRjXKOBfhraMBYV1Sdg0IUj10W 2XVAzkqmqaej0T/xTt6aNjFtiH1u18BUpYIcCAAZ6TJ7325bnqnI+0xWFdonyggL +AIX1nzhx5niw8ZkCX0/jlJAx3TXAuxX/Tfy7cVSVi33v0fiwoDb8ZIDBzg0P2uc PUpR13B3AevFpxuAuAFPWfTDOJQmZyn9YNswVOhNb9rfq5bkmaSBlMRefTtUKIjW XjrRhSULPJ73H+R1DNL1Y0vhclnkOVCFRB+VPChkO+6RitGQDTg/Z60fBHpnYiDz sysnsoojLwBGanHO5mZMprxADc9CmeRGRmfHwvx7eJvW1HqN+5JR3Ai+JDlT+IxX RNUQxUbOry4D8TwRn9nBEtumNyNQcBmUuQINBFLB9nUBEACyRFYCrOXxC8yWm92U qPPNa3YC+W17O4rHW/thKTze1/TeZAKTNaIMPCS7iSVBBRbuijG+8NsgFd6W9acC ihMD4VUdFhVPjRGM3HmqzsxudVI4kGlQl8w86pYZu8ceGB4LQcoUFbPmWgXDIszH NV7kIFO/2oCRJ7VIBllUMP97RRdIfDND7EZMWvDveZ40BZCBLfnD9f6VSs4Lgn2C ow/ko01ijnvUxA/BGPJKI7JTLJHbdL//RQwT3AacLSc/etIurY2Ef926XbYYI1gi qboCU/dYUkGG2D+BDcGdukwpksdZZSXPyNhkZQAPPViHuFFtHI3C+FNb5L+lnC0h /dfF73U1lN3jp/VX11U1tIsHJyPjs8aael2UJO7Qy3vgVRM6KOywNNjVRv79Z/rF YHkNzBwXrGKdwV16SdRWjgkzkB4JeNQME096SqrwAEj/j5fwMqHjR8dKqWKDT6s9 V2Z83go3n9kI8JWFh33OksBh/qpKghhwtGWrUsbVcEDOVmUn2ozXvARDzqnNw3DN PcQvzUtasD8hxGHo7fW4TczdtgS3b/DfU2VJo68Fmo1C4eqYX+Ixx05khFCtP7d0 POqX6jIIQqZq8NTea8/M8Xx1YGhR5RpA4vZe7bCLgD2VUXHL43Npmq2nuZ0/7AwY H0hc/y/T+SU70xn28XyWHHLkCwARAQABiQIlBBgBAgAPBQJSwfZ1AhsMBQkJZgGA AAoJECO6L0dAOWOhIcgP/ioKYiJFAsolS4ep1PenCPvQFjvZTq4xJnsubEJ/ERU8 zdgET0Rh5jcCLqRAxQbGW3lVsewR3N+S9Rt3zHApqfZBFg5XJkZxsk0u+0qGPHWA 4oC7U3E4ZwMfVzUDcfKrzD1h0JaiSW1+1qgCh9/YVCUYakR1n/9LgzPP8ekQLTeb nWE+ZQQfeTDgoTNFWZvUlEbh4zcHLvcay78PnK3uT3UbWPyltSxon/eD47s1dt03 P/8nqaXCZhhRZ9N3EbJyudLBgA3ctySSJJSKKQHYynH5qUQqKp4Wq1KY80161xvW FqKwN/Jr4tTpRVZPu8P82cxhwrWJdf1U3/M2F2aIgXbGS4fHbzsLZ+6zZ3AuT4D8 auW55GOrnoF9XzZV6IavtluILUXMjVzF13slo5PKzS8yyJRNxE22krbeEyUum4Zu dDiERxIB6B+RDMM9qvV9svGJoEXG+4ugwkA3R7a6LWApmkvH3eXpULfDN2g5eNcr 5efFMrI/myxmpsP3nUp5EZFJyp8+ZSzIMJ1jSzXH8mHajIGTG49xDyZGpbog3wd2 7aQf5D9WOuKfYZM9MU9PBF+ZgtNrAxWuYJcCOr4WEd/2IjayMWvLxNA/RVW66oVj puaaDc3m3hXg1fwUWv9ZJyMUv7NARLgig3KEMVZiVzos7ZMn9mZNrOk2fnkKpVJB =ufyu -----END PGP PUBLIC KEY BLOCK----- 
Signature for fingerprint list:
-----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.12 (GNU/Linux) owGFk31QFGUcx48XIU/KU0YSZOhHToraHeze3u4tqd2+HZ6g4ks6ZBTLsXdud7eH ewtCV4mp4/hGKmlTQbyEkgoZxpg6kReML0RWaoohOWWN0mhK4WSZje0Zxw0zzfTP 7rPf5zfP7/N8nn22PRyliYyYfDQ9y0La6yNaotYW6hyi5BTkYlmUFJ9BKVMWdZyu mDFjhpYWFbtXlPQLlUztYtEpCXImZPGlogSUVCQLPkGCNGYBy8FiW9Z82/wsyOby poEzWMEPFVicHl50G+xeD1jDXTIBxXEMcJYkgaEpDhiSNgNCmlHgrHgGoCRLAsfh NCBWhgBjBoNos4VysLGZD5LhIEeUXJlQ+C+nwSs700d0N/A+u5ZzC3ZFLvGE97Bk hdfD+5aC8uBdiqiQZYYiQTuCEMdJDFizujuC5swqjQkHI0JzwJImlZBmTWBGMRoI q1pHZHD4MGEwCQU+QS4Ntiz2et0Gn8und4Uyn0ESlGEkShI9/Etqf5jJh4Zhd7NH opEkgoEZx1iwMkYjYCTJAM5QKADNcRSgKGZSnWWogkmTCTJwKzvMFkxCwf+xzStx K6LqNixurugBukRWvOrBe4Zmg9ahSCgV3N5iQZ4GL4oeHDFbHLxPGcI3lLhG8qNB YAw1qtQEagWMsKoGTTgFOE1hwCAkASjFsUCQVgIYE4GG1apJKBjGdxYbPCqHUFSi pWSPVy4PA1NuXgLGAIsEUf2GtAUOh1sdQXA+KFtdZhrwapFl6B/iHywQdD4S2Ywi VkBQlAQjTrPAmnBVMa4iM0b1gVE0AjiluifNZqN6AKhxGDmYhIL/Qg5etI2RydGa iEhNzKjI4N3TaEfrQjf0brJOs692U9vbzb2jMs51uP1Jl/6KXf7NoTEHolxXvvRf SjzbEylrjFvH1jXefbJxd9/tK8u8SVdLC9yv5N88N/v1Cyu7N1deXDPJMeVs8obj b9zvtW84sv9OWeJJ8tXyPX2/N+zqGn+ZnxCdGz++QXqzYGzthSRE7JJaflRu4/01 jqsFuat62ifvHujc8ZhupW1P59OBjoMtgz+crx08mdN/sDkwtUmfLecN2Hb8duuz Lxq6Aztjz3RsWV1d3TJBc4D86cbfuqjvn0iJemqvfk1/ToHQFZhtWrT555eZwh45 +vNj/jX7Fubnd/3adNxf+EhF7sWmMX+Q184dSvygFdFXBF6b2m1KjLvnoKanzEp0 2cWqgX7L2biU8/2xt5LudZ4g4pawCZVpv6T7q1JfaN9Q1xFxP2Z55fiPuo7tvXdd v6m3vrLt+Tk12bGzDn/rr8+puxl4vLsqrnPKmPg51xUZo+tiXKuf2XZ44DLd8t7N weL21tONnY2jKy+MSzi1/1o8sWrQPPPTd1tteW/tTct6fyO2NNWUJ6wT6mPWx9fz 31ml53QTe75a+2HbumVuvZCcC33V0/fFpM07wkRYUh9a0LxzK6mrOuqYChWT6u4M oGkJS2vmNkWdmdWcP5le4ulLbr+Ws+IysX37OyfSt4y70St8vLov9dE/k3Y1zNy4 SyrY/fWzvRMLP8mNrjh1eFvtznXt/wA= =5zDz -----END PGP MESSAGE----- 
Hashes for fingerprint list:
SHA-256: 7A6B9841 355B1127 E5639A9D 7040D81C F395D382 884376C2 31829C63 6FCF1B80
SHA-512: 04A49A60 A1645479 ED0B3CE9 AE32E156 E9768CC2 0D4EF393 814162BE BFA6FAF5 6C520769 C654467F 6B61EBD4 4A5A5C93 9DF81B7D AA468A50 2DD7FFF3 F637A49C
Verifying the fingerprint list:
Save fingerprint list, from the first plus to the last plus, to a text file called fingerprints.txt
Next save my key to a file called dcc4e.asc and my signature to a file called fingerprints.txt.asc
In terminal or command line run:
gpg --import dcc4e.asc gpg --verify fingerprints.txt.asc 
You should see:
Good signature from "dcc4e " 
GPG examples for verifying Bitcoin clients:
Verifying Bitcoin-Qt:
First download, import and check Gavin's key:
Download his key at bitcoin.org/gavinandresen.asc
In terminal or command line run:
gpg --import gavinandresen.asc gpg --fingerprint 
Check that the fingerprint for Gavin's key matches 01CD F462 7A3B 88AA E4A5 71C8 7588 242F BE38 D3A8.
Then download the wallet software and signature.
Verify the signature:
gpg --verify SHA256SUMS.asc 
You should see:
gpg: Good signature from "Gavin Andresen (CODE SIGNING KEY) " 
The signature for Bitcoin-Qt signs the hash values. So we must compute the hash of the specific downloaded software manually. This example is using the linux version.
gpg --print-md SHA256 bitcoin-0.8.6-linux.tar.gz 
Check that the output matches the associated hash value in SHA256SUMS.asc
Verifying Electrum:
First download, import and check ThomasV's key:
This key can be found at a keyserver.
gpg --keyserver pool.sks-keyservers.net --recv-keys 7F9470E6 gpg --fingerprint 
Check the fingerprint.
Download Electrum and the signature.
Verify the signature:
gpg --verify Electrum-1.9.6.zip.asc 
You should see:
gpg: Good signature from "ThomasV " 
For this example you do not need to manually compute any hash values because the signature is signing the downloaded file directly instead of signing a list of hashes.
submitted by dcc4e to Bitcoin [link] [comments]

Every https site is hacked, every wallets is broken - implications of SSL exploit

Better summary of same news.
There is a huge bug that causes most programs that do encryption like https, or bitcoin-API, or secured IRC, or many communicators, possibly also emails - vulnerable (links below)
Attacker could easily steal your identity, your passwords, your private keys, read your data from such programs, on most (all?) operating systems.
Fix is released just now, at least for linuxes, e.g. for Debian.
What to do about it.
EDIT: 0. obviously first do upgrade your system, restart all affected programs - or if it's a desktop or if you can just restart entire computer to be sure; If you had any important programs build from sources with statically-linked or custom "local" version of libssl, then this needs to be recompiled (this is very rare, applies mostly to advanced users/developers).
  1. do not panick.
  2. If you run any https website - pool, exchange, download site with coin (e.g. bitcoin, dogecoin) software, forum, wiki, web wallet etc - you should consider past keys to be compromised. You should generate new SSL certificates. You should at some point get all users to reset passwords in secure way.
  3. If you USE any https website - pool, exchange, all of above, then you should make sure owners upgraded AND USE NEW CERTIFICATES. Otherwise it could be easy to hack such service with your data/money in it.
  4. If you use dogecoind (same for all coins) on your computer, then if you ever had non trusted program, local user or anything then you really must, and otherwise you should, consider the existing addresses as possibly burned.
To be really safe you should move the money carefully to new addresses, from new wallet (to not use the previously pre-generated pool of addresses etc).
You decide, if that is just few bucks worth of currency then maybe not, and if you have thousands euro worth then you will probably want to move this coins.
  1. communication channels like emails, IRC, IM (jabber and others) also were potentially exploited. Responsible operators of such servers should issue new certificates for their services, and ask you to reset passwords. For some time you should perhaps trust a less communication over this channels.
Luckily best methods already are prepared for "server got owned" scenarios: on jabber we have OTR encryption (didn't yet doublechecked if it is secure, but afair yes), and on irc #bitcoin-otr for example we had the bot requring GPG signed messages adding layer of protection.
LT;DR: demand upgraded certs in services you use, if you have (or plan to have) considerable amount of coins then you better move to new wallet (after upgrading system) and be more carefully about https, irc, chats etc.
Links:
Nice site describing the SSL bug in depth: http://heartbleed.com/
Bitcoin insightful technical discussion: http://www.reddit.com/Bitcoin/comments/22gquw/psa_vuln_in_libssl_allows_to_read_64kb_of/
Debian on some aspects of debugging this bug on linuxes: http://www.reddit.com/debian/comments/22gshl/critical_vulnerability_in_libssl_allows_to_read/
Mempo's (secure private linux) report: http://mempo.org/memposec/issue2.html
submitted by rafalfreeman to dogecoin [link] [comments]

How to securely upgrade Bitcoin Core (Linux) Encrypt messages using GPG on Linux Unix & Linux: GPG seems to alter imported keys - YouTube How to Import GPG Keys in the GUI Gnu Privacy Assistant ... Unix & Linux: Import EPEL GPG key in kickstart post ...

You should be able to import the key via the graphical GPG Keychain, or through the command line (gpg --import key.gpg). If you need to use a insecure channel to transfer the private key, such as email or other network based channels (where you don't have proper certificates ensuring that you are really communicating with the correct machine), you must use PGP (or some other method) to keep ... Linux; GPG Keys Cheatsheet. Posted By Rahul Bansal on 1 May 2014. Generate GPG Keys. Run: gpg --gen-key. You will be asked: Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection? Hit ENTER to select default. Next, you will be asked: RSA keys may be between 1024 and 4096 bits long. What keysize do you want ... Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up. Sign up to join this community. Anybody can ask a question Anybody can answer The best answers are voted up and rise to the top Home ; Questions ; Tags ; Users ; Unanswered ; Jobs; How to export a GPG private key and public key to a ... I'm trying to share a GnuPG key pair by importing it into each machine. This is how I'm doing it: gpg --allow-secret-key-import --import secret.gpg.key gpg --import public.gpg.key The keys have been exported with -a. After doing this, the public key is shown correctly when I do a gpg --list-keys, but the private key isn't (gpg --list-secret-keys). gpg --import private.key share improve this answer follow edited Aug 4 '16 at 15:32. user183096 answered Feb 15 '15 at 13:28. Celada Celada. 36.6k 5 5 gold badges 78 78 silver badges 92 92 bronze badges. 1. Any chance you'd also know why gpg2 -e -r [ID] says "There is no assurance this key belongs to the named user"? I wish I had included it in the original question, but I noticed it ...

[index] [15305] [2695] [755] [20492] [25253] [42699] [405] [20665] [12920] [15523]

How to securely upgrade Bitcoin Core (Linux)

Unix & Linux: Using GPG, encrypt a file with private key Helpful? Please support me on Patreon: https://www.patreon.com/roelvandepaar With thanks & praise to... How To Use GPG Private Public Keys To Encrypt And Decrypt Files On Ubuntu Linux GNU Privacy Guard (GnuPG or GPG) is a free software replacement for Symantec'... Unix & Linux: GPG seems to alter imported keys Helpful? Please support me on Patreon: https://www.patreon.com/roelvandepaar With thanks & praise to God, and ... Create a pair of gpg keys(public - private) and communicate via encrypted messages. securely backing up gpg private keys.. to the cloud‽ - Duration: 30:35. linux conf au 2017 - Hobart, Australia 893 views. 30:35. Are 12-word Seeds for Bitcoin Private Keys Secure? Programmer ...

#