My Blog

Human chosen passwords have poor entropy, and are easy to attack Only for the same length. You can make bigger passphrases.

Keeping the private keys only on a computer without Internet connection (WiFi, modem, Ethernet hardware removed by hand) and without USB interfaces (USB is not a secure interface, there are known exploits) is better if you are worried about firmware malware inside the USB devices (flash drives) and inside the UEFI and the Intel processors. You can transfer the signed transactions using the monitor/keyboard, floppy discs or DVD/CD (not USB!). Using USB devices is dangerous because their firmware may contain malware. If you use USB printer it would be dangerous to reuse it on other computers, because of the risk that the printer is infected with malware (with access to the god mode processor malware). You should assume that the firmware of your devices contains malware: CPU Printer USB drives Hard drive (if any) UEFI Keyboard (key logger) Other (?) And verify that your monitor does not have a screen transmitter (like demonstrated in the Mr. Robot).

Your secrets are in the file secret.txt . Install the scrypt utility: $ sudo apt-get install scrypt Encrypt the file with custom scrypt parameters (about 1G of RAM, 200 seconds; in reality it takes less than 200 seconds on my system, see this Github bug report ): $ scrypt enc -M 1073741824 -t 200 secret.txt encrypted.scrypt Now, you got your encrypted data in the file encrypted.scrypt . You can upload it to your favorite cloud storage provider (Google Drive, DropBox, email it to your Gmail, Proton Mail and Yahoo Mail addresses, etc.). If you want it on paper type into the command line: $ base64 encrypted.scrypt > encrypted.scrypt.base64.txt You can open the encrypted.scrypt.base64.txt file with your favorite editor (LibreOffice Writer) and set a proper font before printing it (this is critical - when printing your keys make sure you use a proper font (that don't have similar characters - like "I" and "l", zero and big O)) . To decrypt the...

Just use Electrum (from electrum.org) on a safe computer (no Windows). Or if you prefer the longer explanation. My opinion is you should understand how computer security works before to do anything. Some important things: Your keys and passwords might get written in the swap file/partition on your hard drive. Don't use swap or encrypt it. Your printer may have memory (hard drive). Your printed documents are saved on your hard drive and then deleted not securely (if you don't use non-HDD system, like Live Linux system from a CD/DVD) Your USB devices may have malware installed in their inner computer (not in the visible from the outside filesystem, it's not visible by the external anti-virus software). Make backup on paper (seed) before you load your wallet with coins. Don't lose the paper backup.

I think that there should be no e-mail associated with accounts. Email accounts are another point of failure and attack vector. Also phone numbers should not be associated with accounts, this is a huge security flaw . The best way to secure an account is with long passphrase, non-phone-number 2FA (with Google Authenticator or hardware device using public key cryptography) and/or PGP key. Passphrase recovery should not be possible or really hard and uncomfortable (you need to fly to the office in person with your passport and 3 witnesses + 1 year waiting period).

SMS text messages sent to your phone are not a valid form of 2FA since the hackers will just call your phone company claiming to be you and your phone was damaged. They get a replacement SIM, access everything linked to your phone.

No need of smashing, burning or even formatting if you are using some "Live" operating system like Ubuntu or Tails run from DVD (on computer with disconnected hard drive, SSD, flash drive).

Here is example with more secure options: $ sudo apt-get install scrypt $ scrypt enc -M 1073741824 -t 200 secret.txt encrypted.scrypt If you have several GB of free memory you can increase the memory usage several times. My tests confirm that the "-t" parameter is not working correctly - it takes less than 200 seconds to derive the key from your password. Archiving private keys - TLDR version Learn more about key stretching . Keepass2 have the option to specify how slow should be the KDF. Click on "1 second" and then add one zero at the end of the number (10 seconds). This will slow down the opening of the database. However, it will also slow down the saving. After I tried to open the database made by Keepass2 with KeepassX I noticed that KeepassX is opening the database much faster than Keepass2 (it takes part of the second compared to 10 seconds with KeePass2). This means that you get false sense of security when your KDF hardness is set to 10 seco...

0. Make multiple encrypted copies. On DVDs (they are better than CDs and Blu-Ray discs; DVD+R are better than DVD-R), paper, cloud services like DropBox, OneDrive, Google Drive, e-mail it to yourself and to your friends, use P2P storage services like MaidSafe, Storj and Sia , etc. 1. Use proper font when printing PGP encrypted keys on paper. 2. Flash memory (SSD, USB flash drives, hardware wallets) is less reliable when not powered regularly (i.e. every week). 3. Use error correction methods like Parchive and ZFS. 4. Print on paper or store on digital media only encrypted data. 5. Your encryption software should use CPU/RAM-intensive KDF (i.e. scrypt with secure options - do not use defaults! ). First, encrypt with scrypt and then encrypt it again with PGP (using different password!) in ASCII armor mode before print it (other methods like QR codes may not be reliable as multiple copies of the PGP ASCII armor). Do not use the same password for the PGP because it's easy to brute...

Do you believe that your hard drive does not contain malware? I mean not what you maybe think. Malware can be installed on the hard drive's microcomputer. All hard drives contain another computer inside them - with his own processor, RAM, flash memory, etc. This computer have access to the main computer's RAM. Also your BIOS/UEFI may contain malware. Also your CPU contains entire computer (like hard drives). Search for "intel amt rootkit" for more info. Rootkit in your laptop: Hidden code in your chipset and how to discover what exactly it does [PDF] All anti-virus programs can not access and verify the memory of these separate computers, hidden inside your computer. Key phrases you may want to type into Google: hard drive firmware rootkit NSA hard drive firmware Intel AMT rootkit Intel ME rootkit BIOS UEFI malware BIOS UEFI rootkit Here is somewhat safe alternative, but this does not solve the problem with the CPU and the hard ...

When you see something like this when you try to login to your server you probably want to be sure there is no Man in the middle attach. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is SHA256:7KMZvJiI5AeC5As2GSZES5baxTZ+HbOyqjNPVy1NIe4. Please contact your system administrator. Add correct host key in /home/user/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/user/.ssh/known_hosts:20 remove with: ssh-keygen -f "/home/user/.ssh/known_hosts" -R [example.org]:2548 RSA host key for [example.org]:2548 has changed and you have requested strict checking. Host key verification fai...

Download PDF A flaw in the Linux kernel lets hackers inject malware into downloads and webpages, smash Tor connections, launch denial-of-service attacks, and more. This sounds pretty serious. It sounds like if either side of a connection is affected by this bug, and an attacker knows both sides' IPs, then they can quickly confirm that a connection exists and insert whatever data they want into the middle of the connection. They can't read data sent between the two parties, though. Where this is most worrying to me is system updates. On Linux, it's unfortunately fairly common for updates to be automatically delivered over HTTP and then not checked in a secure way. For example, Gentoo by default downloads packages insecurely, and on yum-based systems, even though the stock configuration is often secure, it's common to add insecure repos (for example, the official nginx repo is by default insecure). If your system downloads updates insecurely, then an attacker can ma...