Bitcoin Forum
June 26, 2022, 06:01:56 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / GCC recommendation: -fstack-protector on: July 09, 2011, 08:16:11 AM
I recommend to include the option -fstack-protector to the UNIX makefile. Many distributions (including Ubuntu) use it by default, but some others may not.

Why does it make sense?
On the one hand the Bitcoin client is supposed to be online and connected with many peers. On the other hand it handles data that must be kept secret at all costs.

Thus the client processes messages from unknown peers all the time. If there is a bug in processing, there could be buffer overflows. Those could be exploited to take over the client.

There are three common measurements at the moment against such attacks:

- NX bit: a CPU feature that prevents data from being interpreted as code
- address randomization: the Linux kernel gives each process different stack addresses every time
- GCC stack protector: buffers on stack are surrounded by test data which makes it hard to overflow a buffer without being detected

While the first two are configured by hardware and OS, the third one is configured at compile time.

Code:
-fstack-protector
           Emit extra code to check for buffer overflows, such as stack
           smashing attacks.  This is done by adding a guard variable to
           functions with vulnerable objects.  This includes functions that
           call alloca, and functions with buffers larger than 8 bytes.  The
           guards are initialized when a function is entered and then checked
           when the function exits.  If a guard check fails, an error message
           is printed and the program exits.

           NOTE: In Ubuntu 6.10 and later versions this option is enabled by
           default for C, C++, ObjC, ObjC++, if none of -fno-stack-protector,
           -nostdlib, nor -ffreestanding are found.



Any disadvantages?

Of course every measurement of this kind affects Performance. But this affects only functions that have buffers of more than 8 bytes.

And if you have built it on Ubuntu until now, you have had it activated anyway without knowing.
2  Bitcoin / Bitcoin Discussion / deepbit has 50.18 % now on: July 07, 2011, 11:43:48 AM
Don't panic, but watch carefully!








http://www.bitcoinwatch.com/
3  Bitcoin / Bitcoin Discussion / Secret keys could be memorizable on: July 01, 2011, 08:23:10 AM
CAUTION: Don't understand this as a tutorial. You should not use any of this ideas for important key generation! This may affect security in the very core, because the security of ECDSA is based on the assumption that each possible key is as likely as any other!

This thread is meant as an idea for a techie and crypto-geek discussion.



Why generate random ECDSA private keys and encrypt them with AES then using weaker passwords?



In principle it should be possible to use the password directly as private key. How?

You have the eliptic curve, and the generator element A. You chose a password p and calculate q = (pA). p is not easy to calculate from q (discrete logarithm on eliptic curves), that's the basis of the whole ECDSA system.



New weaknisses:
- you can brute force private keys (e.g. via dictionary attacks) now and test whether they imply the known public key

Possible advantages:
- brute forcing private keys may be harder than brute forcing AES (or other) file encryption



What do you think? I got this idea a few minutes ago, there may be flaws I just didn't see yet.
4  Bitcoin / Bitcoin Discussion / If an attacker gets more than 50 % of mining power on: July 01, 2011, 07:56:29 AM
What does that actually mean? Here have been a lot myths around, so I made some calculations.

What are possible attacks? When an attacker has more than 50 % of ressources, he may generate the longest block chain ignoring the other miners.

What does that mean?

If a miner has 50 % of computing power, he could reject transactions in half of the blocks generated. That means that for every good block there is an evil block. Which means that you have to wait for one block that does not include the transaction before your transaction gets included (all numbers mean the average!).

50 percent: transaction wait time doubled

You can calculate the numbers with the following formula for x %: c(x) = log_x (0.5)

Results:
50 % attacker power: wait 1 extra block before you get your transaction included
60 % attacker power: wait 1.36 extra blocks before transaction included
70 %: wait 1.94 extra blocks
80 %: wait 3.11 extra blocks
90 %: wait 6.58 extra blocks


Now we see, that even if you invest tremendous costs in getting a huge majority of computing power, you can't do a lot of harm.
5  Bitcoin / Bitcoin Discussion / What operating systems do you use for Bitcoin? on: June 23, 2011, 11:50:19 AM
You can chose more than one option.

I think this is interesting and related with the question of several security issues including Bitcoin wallet management.
6  Bitcoin / Bitcoin Discussion / The ABC of password security on: June 19, 2011, 09:02:54 AM
In this thread I want to discuss some pieces of wisdom about password security. This will not be complete, just the basics that I remember at the moment.

First we have to distinguish between online and offline passwords:

Online passwords are passwords that you use to log in. This does not have to be as secure because the site sets the rules how often you can try. For example, a site could refuse your login for a while after 5 wrongly entered passwords.
This means that an attacker cannot try out as many passwords as he wishes in a time as short as he wishes.

Offline passwords are passwords that you use for example to encrypt a file. This password has to be way stronger, because an attacker with the file cannot be forced to do less than a certain number of tries per second.
For example if the attacker can take your encrypted file and put it on as many computer as he wishes to try out as many passwords per second as he wishes. The only way against that is to have a password so strong that an attacker could not get enough computing power to break it.

Note that an online password of a website can become an offline password, e.g. when the website is hacked and the password hashes that the operator stored are leaked.
We will talk about offline passwords now because that is the most important issue for bitcoin users.


Randomness of characters: Depending on which set of characters you use, your password gets more randomness. For example if you use lower latin letters only, you have 26 characters. If you chose a password of length 8, you have 26^8 different possible passwords. To represent 26^8 possible passwords by a binary code, you need log_2(26^8) =  8 * log_2(26) = 8 * 4.7 = 38 bits. That's not much at all.

Code:
character set number bits per character
[a-z] 26 4.7
[a-z0-9] 36 5.2
[a-zA-Z0-9] 62 6.0
all ascii 94 6.6

You can see that the size of the character set matters a lot. But what matters even more is the length of the password. The number of possible passwords depends exponentially on the password length. For example for a whole-ascii password each additional character multiplies the number of possibilities by 94. This results in a growth of randomness by 6.6 bits for each character added.


Independence of characters: In the discussion above I assumed all the time that every character has the same probability. That is of course not always true. Attackers know that, and use it. That's why you should not use a dictionary word - in dictionary words the different characters are not independend.
For example, in English words you know that after a "Q" almost always follows a "U". Because of this, the string "QU" has a much higher probability than the strings "QS", "QG" or "QL".


Conclusion: The way to a secure password is to choose from a large set of characters, and choose the characters randomly with the same probability of each characters. The longer the password, the better. If you use AES256 for example, up to 39 characters each additional character adds real randomness to the whole thing. After that, you don't get more for AES, but there exist other encryption algorithms with even longer key lengths (e.g. blowfish up to 448 bits = 68 chars of password).

What I did: When I started bitcoin, I choose a new 12-character whole-ascii password (79.2 bits of randomness). It was a pain to remember in the first hours, but after typing it a few times I got used to it. I use this password now for my encrypted seperate bitcoin user account (on Ubuntu) and for wallet backups.




If you considered that helpful, you might give me a tip: 1HuteXifXc3x8Nq9x8hHGUnFGDU7KFggXD
7  Bitcoin / Development & Technical Discussion / Use .tar.xz instead of .tar.gz on: June 18, 2011, 10:27:58 AM
It will push archive size of 0.3.23 (for linux) from 11 M to 6.5 M. This results in 41 % smaller size (and thus traffic).

 It still decompress faster, only compressing takes a little longer.
8  Bitcoin / Bitcoin Discussion / I think it's necessary: Encryption for dummies on: June 18, 2011, 10:19:26 AM
People are asking all the time for encryption of their wallets and using TrueCrypt etc. And they think that it protects against certain attacks like Trojans, which it doesn't. This discussion shall result in a summary that explains noobs what encryption can do and what it can't.

What is encryption?
Encryption is a tool to protect data. With an encryption scheme you can encrypt a file with a key. The desired result is that nobody is able to read that file without the key.

Misconceptions that make encryption worthless
If you want to protect data via encryption, you have to make sure that this data does not exist anywhere outside the encrypted file. This is the hardest task of all and the error most people don't seem to see.

Cases associated with bitcoin where this is the case:
  • If you encrypt an existing wallet, your old version may still be on disk. The only way to avoid that is wiping out the whole disk, or creating a new wallet inside the cryptographic container that never hits a disk unencrypted in its lifetime.
  • Even if you avoided the first case: As long as your encrypted device or file is mounted, the data is not protected by encryption. The only protection is now policy enforcement (e.g. operating system prohibiting other users to access your files). There is no way around that, you have to decrypt the wallet to work with it. The only solution is a seperate wallet that is decrypted less often. There are many ways to enforce policies like installing a isolated machine or creating a seperate user account that does not run untrusted software. You can do it as secure as you want by investing the effort of using it. (Note: VM guests don't work at all, because VMs were never meant to protect guests against hosts, only the other direction makes sense.)
  • Always assume: Malware can do anything you can do. The only thing that protects you is your decryption secret, but only as long as you don't decrypt the file. If you can use the wallet, why should a trojan not be able? In fact it always is. That's the problem the policy enforcement aims at: It makes sure that a trojan in your working space cannot access a wallet that is in an isolated space. There can still be flaws that could open a door for attackers around those policies, that's why there are those different methods proposed.

Conclusion
If you really want security, you have to accept the following principle:
Always assume that it does not protect you unless you can really argue with certainty and in detail why it does prevent certain attacks.
9  Bitcoin / Bitcoin Discussion / Bad security advice again: shred on: June 17, 2011, 10:01:23 PM
After the bullshit advice that security noobs give here all the time about VMs and TrueCrypt, this time I will discuss shred.


Problem:
Destroying wallet.dat files with shred does not work.

Why?
That's not shred's fault. shred is just from another millenium. Modern operating systems use modern file systems, that don't store files at a fixed place any more. That has a lot of reasons that reach from performance improvement to better error correction after system crashes.
When you use shred on these filesystems (anything more modern than FAT and ext2), shred will write random data to the file - but that does not actually hit the disk at the spot where the file used to be. The original data of the file may survive that. For more details see the man page quotes below.

What does work?
shred is still useful - for example if you wipe out entire drives before creating new filesystems. If you don't want to wipe out your whole disk every time, you have to choose between a prehistoric file system or cryptography (which is not trivial).



Read the f****ing manual!
Quote
CAUTION: Note that shred relies on a very  important  assumption:  that
       the  file system overwrites data in place.  This is the traditional way
       to do things, but many modern file system designs do not  satisfy  this
       assumption.
  The following are examples of file systems on which shred
       is not effective, or is not guaranteed to be effective in all file sys‐
       tem modes:

       * log-structured or journaled file systems, such as those supplied with
       AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)

       * file systems that write redundant data and  carry  on  even  if  some
       writes fail, such as RAID-based file systems

       *  file  systems  that  make snapshots, such as Network Appliance's NFS
       server

       * file systems that cache in temporary locations, such as NFS version 3
       clients

       * compressed file systems

       In  the  case  of  ext3 file systems, the above disclaimer applies (and
       shred is thus of limited  effectiveness)  only  in  data=journal  mode,
       which  journals  file  data  in addition to just metadata.  In both the
       data=ordered (default) and data=writeback modes, shred works as  usual.
       Ext3  journaling  modes  can  be  changed  by adding the data=something
       option to the mount  options  for  a  particular  file  system  in  the
       /etc/fstab file, as documented in the mount man page (man mount).

       In  addition, file system backups and remote mirrors may contain copies
       of the file that cannot be removed, and that will allow a shredded file
       to be recovered later.

GNU shred manual from Ubuntu 11.04
10  Other / CPU/GPU Bitcoin mining hardware / Has anyone already tried FPGAs instead of GPUs? on: June 16, 2011, 08:14:56 PM
I think you could get a huge advantage in hashrate per energy, but maybe you don't get a high hashrate for a reasonable hardware and work investment.
11  Other / Meta / Suggestion: Security subforum on: June 13, 2011, 12:28:23 PM
I would suggest to open a new subforum for the topic of security, because so many topics are mixed in this section.

It is meant not to be about how the client software works, but about how to manage your keys and wallets securely.



I would also suggest to move the following threads to the new section:

http://forum.bitcoin.org/index.php?topic=15068.0 (management example)
http://forum.bitcoin.org/index.php?topic=15052.0 (virutal machine discussion)
http://forum.bitcoin.org/index.php?topic=16246.0 (truecrypt discussion)
http://forum.bitcoin.org/index.php?topic=16266.0 (GPG discussion
12  Bitcoin / Bitcoin Discussion / Security again: Before using TrueCrypt - read the freakin manual on: June 13, 2011, 10:11:53 AM
Quote from the TrueCrypt documentation:

Quote
IMPORTANT: If you want to use TrueCrypt, you must follow the security requirements and security precautions listed in this chapter.

The sections in this chapter specify security requirements for using TrueCrypt and give information about things that adversely affect or limit the ability of TrueCrypt to secure data and to provide plausible deniability. Disclaimer: This chapter is not guaranteed to contain a list of all security issues and attacks that might adversely affect or limit the ability of TrueCrypt to secure data and to provide plausible deniability.
http://www.truecrypt.org/docs/?s=security-requirements-and-precautions

and especially from the malware section:

Quote
It is important to note that TrueCrypt is encryption software, not anti-malware software. It is your responsibility to prevent malware from running on the computer. If you do not, TrueCrypt may become unable to secure data on the computer.


A lot of people here are just telling the noobs: "I have TrueCrypy, everything is secure." That's just not true. And it is even worse: The very fact that TrueCrypt appears to be a click-here-click-there-I-am-secure-now tool gives people a feeling of security they don't have. Like any security tool, TrueCrypt is worthless unless you are aware what exactly it does.

For the task of protecting wallets I would go even further and say that TrueCrypt is not a appropriate solution. For this application it is almost as bloated as VMs.
If you want to encrypt wallet files for backups, use GPG.
If you want to protect the wallet file from being stolen from your disk, use encrypted folders of the kind that your operating system provides. But don't expect it to be protected against malware while in use. Everything you have access to, the malware you catch has access to, too. It will protect you against people who steal your computer, but it will not protect you against malware.

PS:
Just to prevent misunderstanding: In my opinion you can do whatever you like to. But stop making such strong claims misleading people who understand less then you do.

PPS:
Maybe we need a security subforum.
13  Other / Politics & Society / Isn't deflation theft, too? on: June 13, 2011, 08:36:34 AM
Just think of this simple example:

Maybe you start with 100 units of currency (e.g. bitcoins) and 100 units of goods (e.g. pizzas). Then you get one pizza for one bitcoin.

Now, these 100 bitcoins are owned by 10 users with the following distribution:

user 1: 20
user 2: 20
user 3: 20
user 4: 20
user 5: 5
user 6: 5
user 7: 5
user 8: 2
user 9: 2
user 10: 1

Now user number 10 makes a pizza. this means we have 100 bitcoins and 101 pizzas. This means, for one bitcoin you now get 1.01 pizzas.

What does this mean? This means, that every user gets extra pizza. And the users with more coins get more extra pizza, although it was only user 10 who made the pizza.

And even when he wants to sell the pizza: He will not get 1 bitcoin for it. He will get about 0.99, because that's the pizza price when there are 100 bitcoins and 101 pizzas on the market.
14  Bitcoin / Bitcoin Discussion / Bitcoin should be calles "digital currency" instead of "virtual currency" on: June 12, 2011, 02:50:55 PM
"Virtual" sounds like not real. Like virtual realities, or Linden Dollars and WoW dold.

"Digital" is a much better word, like digital audio and video, or digital signatures that are used for transactions.



I think that is an important difference that affects the public perception of bitcoin a lot.
15  Bitcoin / Bitcoin Discussion / How I manage and protect my wallets (Ubuntu Linux) on: June 11, 2011, 04:00:43 PM
I want to tell you, how I manage my wallets. The purpose of this thread is to exchange ideas, and to analyse how well the ideas of others work.

Setup:
My main computer is a laptop with a recent version Ubuntu Linux. In addition to my user account, I made a new account for bitcoin only with an encrypted home directory.
- The password is pretty strong (12 characters, including upper and lower letters, numbers and special characters).
- I don't run any programs with this special account except for bitcoin.
- The files of this special user are strongly protected by encryption, when he is not logged in.

Wallets:
My regular user account and my bitcoin user account have a wallet each. My bitcoin user account stores the majority of coins, my regular account has a small amount.
When I want to receive a large amount of bitcoins, I use an address of the better protected wallet.
When I want to send a lot of coins, I login with the bitcoin account and send some. Then I log out again.

Backups:
I make backups of the wallet by the following command:
Code:
tar -c ~/.bitcoin/wallet.dat | gpg -c > $BACKUP_FILENAME
The command asks for a password, and I enter a quite strong one, because I want to be save putting those backups anywhere.

I store those encrypted backups on USB disks and on university computers (which are backuped very systematically and well). It's easy because the wallet files are quite small.

Possible attacks:
- cracking the strong password or the AES encryption keys
- cracking the whole machine with root access and stealing the wallet, while the bitcoin user account is logged in
- stealing my computer while the bitcoin user account is logged in

Do you see any flaws? How do you do it? What can I do better?

Do you see any attacks that I haven't thought of?
16  Bitcoin / Bitcoin Discussion / Stop telling people that VMs could protect anything on: June 11, 2011, 03:14:58 PM
If you set up a guest VM on a host computer, the programs in the guest VM can not (easily) attack the host computer.

But in the other direction, it is not true. Programs on the host machine can just manipulate the guest VM, e.g. just modify the disk image file.

Thus, a guest machine for bitcoin does not make sense at all (at least when the intended goal is protection).




But a hint may help:
A wallet file does not have to be online to receive money. You can just create a wallet on a offline computer and use the addresses.
Only if you want to spend money from that wallet, it has to be taken to an online machine.
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!