How do you guys spect GPG to be malware-proof?
If your system is compromised , it doesn't matter what tools you use on top of it.
I never said that GPG protects against malware. It allows you to store backups on insecure machines, but it does not allow you to decrypt anywhere but on a secure machine, of course. |
|
|
|
@Stevie: Your paper paragraph 3.6 is a serious bug, but in a very different way than discribed:
The is no danger of double spending as long as payees wait for confirmations in the block chain.
But there is a vulnerability. Think of the following:
1. A wants to pay B some BTC.
2. A draws that transaction X (signet with his key).
3. The transaction gets not included in the block chain.
What now? A can now ignore that or draw another transaction Y. Maybe transaction Y got into the block chain.
What attack is possible now? Right: B can steal coins from A by sending the already drawn transaction X into the block chain generation.
Thanks bcearl. I hope you will excuse me, I try to stick to the bugs I think I found. But if you found a different one, please have the current devs look into it! What I am not sure about now: Do you agree that transactions are not safe if not included in the block chain? (And 'buried' under enough blocks?) I would state it like this: When you make a transaction, and it does not get in the block chain, you can't withdraw it either. I don't consider it a huge problem, but I can't see that there is any solution possible to that problem. |
|
|
|
Extremely important. Should also have some howtos for newbies. A good understanding of security tools and their limitations is essential when online anyways, bitcoin or not. Now with people in charge of their own BTC (basically running their own personal banks), these issues are more pressing than ever.
Secure air-gapped computers, crypto, backups, OS issues, etc should all be discussed.
I think howtos should be placed in the wiki, but we can link and discuss howtos and generate new howtos from discussing security problems and solutions. |
|
|
|
+1
This is critical and not getting enough attention. There are some really hard problems to solve, most of which aren't even technical. Hopefully we'd be able to get some good sticky, best-practice threads up after a while.
Even more dangerous than missing good advice is all the bad advice you find spread over all discussion threads. |
|
|
|
|
I wasn't aware of that, I have had no Windows for years now.
7zip seems to use AES256, that may be ok. But you have to choose a strong password, the 5 characters, that somebody suggested, are way too small. I am talking about 12 or more charakters, which are from different types and are not corresponding with dictionary words or keyboard patterns.
|
|
|
|
whats wrong with 7zip and use a password with a .7z archive?
Nothing. As long as you use AES-256 and encrypt the file listing too. It's not enough to use AES256, you have to use it without flaws. I have tried to crack one of my passwords on a 7-zip container just for fun. I had a 3 keys/second generation performance for a 5000 MIPS CPU. Even a 5 chars password would take 20 years to crack my that CPU. Since you could use GPUs, you could lower that to maybe 2 months? Just to break a wallet. I suppose it should have more than 50 BTC to be worth it... Use a sufficiently long password and you should be ok for now. It's an easy method of saving your wallet as it doesn't require you to store keys and whatnot. What exactly did you test? Why should an attacker try to decrypt the 7zip-file to get the password? There are certainly better ways! |
|
|
|
whats wrong with 7zip and use a password with a .7z archive?
I wouldn't trust a tool originally designed for compressing data to safely encrypt data. GPG exists for protecting data. Also, PGP has been around for a long time. It is well-understood and has been reviewed for flaws. It is also far more flexible than things like encrypted zip/7zip files. Encryption is hard to properly implement. GPG has earned quite a bit of trust in the community for a reason. it would be nice if you said why 7zip is no good, pgp was designed to send data securely, so using it for personal secure storage seems redundant to me. the only use i see pgp for is sending a file to someone else to prevent interception both ways, in this case 7zip would be no good unless the password was given in person, but pgp is good because its like sending an unlocked padlock for the other person to...wait you all probably know this story. GPG does also provide encryption of files with symmetric algorithms and passwords. You don't have to use public key crypto for that application. Then why use GPG if you end up only needing a password. Because it is known to use well known algorithms properly, and it is way simpler (by this I mean how it works, not only how to use it) than TrueCrypt.* Read the OP, please. |
|
|
|
whats wrong with 7zip and use a password with a .7z archive?
I wouldn't trust a tool originally designed for compressing data to safely encrypt data. GPG exists for protecting data. Also, PGP has been around for a long time. It is well-understood and has been reviewed for flaws. It is also far more flexible than things like encrypted zip/7zip files. Encryption is hard to properly implement. GPG has earned quite a bit of trust in the community for a reason. it would be nice if you said why 7zip is no good, pgp was designed to send data securely, so using it for personal secure storage seems redundant to me. the only use i see pgp for is sending a file to someone else to prevent interception both ways, in this case 7zip would be no good unless the password was given in person, but pgp is good because its like sending an unlocked padlock for the other person to...wait you all probably know this story. GPG does also provide encryption of files with symmetric algorithms and passwords. You don't have to use public key crypto for that application. |
|
|
|
whats wrong with 7zip and use a password with a .7z archive?
Nothing. As long as you use AES-256 and encrypt the file listing too. It's not enough to use AES256, you have to use it without flaws. |
|
|
|
So you're saying Bitcoin is more real than government issued money?
Depends. Maybe not more real than green paper bills. But more real than FED loans to banks. |
|
|
|
whats wrong with 7zip and use a password with a .7z archive?
Depends on how it does the encryption. Maybe they also have a good AES256 implementation. Maybe it's crap. |
|
|
|
Even though LL tries to get their asses out of the line of fire by saying L$ is just make believe monopoly money, people still trade it back and forth with official government money; what could make that any less real than Bitcoin?
Your L$ is just a number on a computer of LindenLab's. They could just change it like they want. Your BTC balance is established by the block chain that nobody can just change. |
|
|
|
|
Your pruning suggestion will not work, because the number of accounts will also grow.
And you don't have to change the block chain format for achieving that anyway.
|
|
|
|
lol... 47968 times 50 BTC? The completely unspent coins are massive compared to the amount traded!
Remember that volume shows frequently traded coins multiple times. I wonder why so many coins aren't used at all -- and what must happen to get them moving.
It doesn't really matter, even if people lose their wallets. Ultimately, the value of a bitcoin is the amount people are willing to pay for them and the amount people are willing to sell them at any given time. But the more bitcoins there are on sale, the less people will pay for them. |
|
|
|
Money in your bank account is also virtual. It only exists as a number in a database. Just like linden dollars and WoW gold :p
Yes, but opposed to that, bitcoins are not. They are digital - like digital music - but not virtual. |
|
|
|
I agree, geeks understand virtual is just another type of real, but the general public thinks it's make believe
"Virtual" is acutally a word with a fixed meaning. For example virtual is what you see when you look in the mirror. Digital instead just means that it based on discrete numbers, which is very true of bitcoin. |
|
|
|
|
@Stevie: Your paper paragraph 3.6 is a serious bug, but in a very different way than discribed:
The is no danger of double spending as long as payees wait for confirmations in the block chain.
But there is a vulnerability. Think of the following:
1. A wants to pay B some BTC.
2. A draws that transaction X (signet with his key).
3. The transaction gets not included in the block chain.
What now? A can now ignore that or draw another transaction Y. Maybe transaction Y got into the block chain.
What attack is possible now? Right: B can steal coins from A by sending the already drawn transaction X into the block chain generation.
|
|
|
|
Another important detail for the task of protecting wallets: An attacker can set you wallet to a previous state without even decrypting your TrueCrypt disk: TrueCrypt uses encryption to preserve the confidentiality of data it encrypts. TrueCrypt neither preserves nor verifies the integrity or authenticity of data it encrypts or decrypts. Hence, if you allow an adversary to modify data encrypted by TrueCrypt, he can set the value of any 16-byte block of the data to a random value or to a previous value, which he was able to obtain in the past. Note that the adversary cannot choose the value that you will obtain when TrueCrypt decrypts the modified block — the value will be random — unless the attacker restores an older version of the encrypted block, which he was able to obtain in the past. It is your responsibility to verify the integrity and authenticity of data encrypted or decrypted by TrueCrypt (for example, by using appropriate third-party software). http://www.truecrypt.org/docs/authenticity-and-integrity |
|
|
|
|
Show Posts
