The biggest security hole -> Default values

[jgraham]

The indecipherable cipher suffers from patterns,

Are you talking about OTP's here?  These days getting a good source of entropy is relatively easy.

the pathetic attempt done by Gilbert was to create an algorithm where the key matches in size the crypt text. Resulting in a stupidity, as if you can send such key securely, you rather send the plain text the same way and spare you from some worthless work.

Uh...no

Key distribution is a different problem from encryption for a very good reason.   You can choose the time for key distribution and make it secure.  This allows for a secure OTP transmission at any time forward.  You don't have to think very hard to come up with an example such as....wartime.

Given a long enough key and a short enough text to Vernam's method and you would get that effect already.

Shakes head...you actually have too much noise and not enough signal there.

PS - This topic isn't about cryptography anyway...

Good because you don't appear to understand what you are talking about...

my idea just provides a "hiding the wallet" not "encrypt it". -> This means that currently is like if everybody was using their wallets in the back pocket, making life easier to pickpockets. My method would simply make anyone put the wallet wherever he wishes... making pickpockets to have to look for it - still doesn't mean you get rid of pickpockets, just their job gets harder.
 

Only if that place isn't stored anywhere and the user is prompted each time the application is run.  Even then it's not very much harder.  A machine that can scan tens of thousands of files per-second would let me narrow down the search tree easily.

So as said before this isn't significantly more secure than the original system.

[BCEmporium]

No, the "Indecipherable cypher" is the "father" of OTP:

Caesar's cypher -> Indecipherable cypher -> OTP

Differences:

Caesar's Key: B
Text: APPLE
Result: BQQMF
(this was used by the Romans, strong enough for what they were facing)

"Indecipherable Cypher" Key: BEAN
Text: APPLE
Result: BTPZF

Early OTP Key -> has to match the size of the text to chyper, so BEANS
Text: APPLE
Result: BTPZX

Yes, but if the key gets compromised - and you didn't figured it out - then you'll be giving away info.
But that's for another field, a field for which encryption is a tool -> information.
Information is also valid in a time frame, imagine a German message intercepted in 1939 that just now got decrypted, it says «Tomorrow we will invade Poland»; what's the use to know it now?!

There's a significant increase in security by moving the file, despite if "some software can scan your computer", as that very same software probably can do whatever it takes no matter what security you imply.
I don't know if you were looking at the code or can reverse engineer software of the latest virus for Bitcoin, this method alone would put them all out of commission... yes in the future a better skilled coder(...); but also in the future machines calculating Petahashes per second(...).

BTW, back in the days while in the army I designed an OTP based chat system, you need a floppy key (no USB at such time) which have files like 1.key, 2.key(...). Each of those files have a very long passphrase inside and uses sync encrypt/decrypt, at random intervals the part which started the chat send a signal to switch the key to another <number>.key... pretty much simple, but effective... unless someone used diskcopy that is...

[kokjo]

There's a significant increase in security by moving the file, despite if "some software can scan your computer", as that very same software probably can do whatever it takes no matter what security you imply.
I don't know if you were looking at the code or can reverse engineer software of the latest virus for Bitcoin, this method alone would put them all out of commission... yes in the future a better skilled coder(...); but also in the future machines calculating Petahashes per second(...).

Phash/s will not do it! still takes longer time then the age of the universe to crack.
a major breakthough in math, will do it. but then we will have other things to worry about(nuclear missiles flying around).

if i was a script kiddie i would code a 5 line trojan, that could scan your computer, for 1btc, and gain 500btc.

[BCEmporium]

if i was a script kiddie i would code a 5 line trojan, that could scan your computer, for 1btc, and gain 500btc.

Damn! You're a cute troll 
5 line trojan (with 20 Mb batch of attached DLL's?) 

[Alex Beckenham]

useless! trojans cloud scan the whole computer for the wallet.

Thread got off-track a bit, but it could have usefulness outside security... at the moment people who have more than one wallet have to rename them to wallet.dat in order to load them.

wallet.dat -> rename to wallet_temp.dat
wallet2.dat -> rename to wallet.dat

I'd love to be able to call it something else, and in addition being able to specify the location of the wallet separately from the block chain would be handy for placing the wallet on tiny places where you don't want write 300+ mb of data. (like a flash drive). It'd be cool to have the bulky block chain on the hard drive, but wallet on a flash drive.

[Jaime Frontero]

ummm... returning to the thread topic (i.e., Default Vaues), i don't understand something.

we can already control where the client looks for its configuration file (-conf=<file>), and where it looks for its data (-datadir=<dir>).

why can't we have an option like -wallet=<file> ?

it's hardly perfect, or even particularly elegant:  but it seems to me that the ability to run a wallet.dat file that was called foo.bar would eliminate about 90% of the scriptkiddie issues.

no?

[Jaime Frontero]

useless! trojans cloud scan the whole computer for the wallet.

Thread got off-track a bit, but it could have usefulness outside security... at the moment people who have more than one wallet have to rename them to wallet.dat in order to load them.

wallet.dat -> rename to wallet_temp.dat
wallet2.dat -> rename to wallet.dat

I'd love to be able to call it something else, and in addition being able to specify the location of the wallet separately from the block chain would be handy for placing the wallet on tiny places where you don't want write 300+ mb of data. (like a flash drive). It'd be cool to have the bulky block chain on the hard drive, but wallet on a flash drive.

heh.  great minds run...

[BCEmporium]

You give 1MB key for OTP comm with a sub, and rather you not send them any block longer than 1MB, send him War and Peace and you start to get a pattern.

sending him the pattern "War and Peace" in 1MB, does not create a pattern, in the encrypted data.
giving him a 10^100 byte key, and sending him 10^100 bytes "War and Peace", also does not.

it seems you simply dont understand it.

LOL! Missed this post!  
"Send him War and Peace" doesn't mean send him "pattern War and Peace", but broadcast War and Peace, Leo Tolstoy book:

http://en.wikipedia.org/wiki/War_and_Peace

  Sending patterns.. I'm still laughing!!!  

[kokjo]

if i was a script kiddie i would code a 5 line trojan, that could scan your computer, for 1btc, and gain 500btc.

Damn! You're a cute troll 
5 line trojan (with 20 Mb batch of attached DLL's?) 

just found my wallet:

Code:

[removed]@laptop:~$ ps -A | grep bitcoin
 1926 ?        00:40:44 bitcoin
[removed]@laptop:~$ file /proc/1926/fd/* | grep .dat
/proc/1926/fd/11:  symbolic link to `/home/[removed]/.bitcoin/addr.dat'
/proc/1926/fd/12:  symbolic link to `/home/[removed]/.bitcoin/blkindex.dat'
/proc/1926/fd/13:  symbolic link to `/home/[removed]/.bitcoin/database/log.0000000163'
/proc/1926/fd/14:  symbolic link to `/home/[removed]/.bitcoin/wallet.dat'

it could be easily be automated in a shell script, but i did not have time for now

of course you suggested client, would not have it open all the time, and it would not be a *.dat. but its really not that hard, see?

[kokjo]

You give 1MB key for OTP comm with a sub, and rather you not send them any block longer than 1MB, send him War and Peace and you start to get a pattern.

sending him the pattern "War and Peace" in 1MB, does not create a pattern, in the encrypted data.
giving him a 10^100 byte key, and sending him 10^100 bytes "War and Peace", also does not.

it seems you simply dont understand it.

LOL! Missed this post!  
"Send him War and Peace" doesn't mean send him "pattern War and Peace", but broadcast War and Peace, Leo Tolstoy book:

http://en.wikipedia.org/wiki/War_and_Peace

  Sending patterns.. I'm still laughing!!!  

why the hell would someone send a public available book, over a highly secure communication line?

but anyway sending something with a pattern with a OTP, will not make the pattern known.

[jgraham]

<<long unnecessary, irrelevant and unasked exposition>> 

There's a significant increase in security by moving the file, despite if "some software can scan your computer", as that very same software probably can do whatever it takes no matter what security you imply.

The class of attacks you are seemingly trying to thwart is an external application which steals the wallet.dat file off disk.  As opposed to something that compromises the bitcoin client itself which would likely be immune to these attempts.  Time is a factor in defense so if I can steal your wallet in a few hours rather than a few seconds that is not a significant increase in security.  Compared with encrypting the file with OpenSSL and a passphrase the "file stealing attack" no longer works.

So considering the class of attack and considering the countermeasure it doesn't add much.  Think of it as installing a door lock that can withstand three attempts to kick the door in instead of two.  True this makes the attack "harder" but not in a significant way.

[BCEmporium]

Shell scripting... OMG!!!! LOL! Well, we were talking about script kiddies weren't we? That might a bit weird trojan for distribution btw, you would need to put something like: do a chmod a+x mytrojan then ./mytrojan to run it.  
Despite all the virus for Bitcoin I came across lately were for Windows... probably your should think about a trojan.bat  

The "War and Peace" means "Send a damn long text out"... that's what War and Peace is; a damn big book.

Weaknesses of Encryption - Lesson 1 - PATTERNS

In the 3 named encryption methods, patterns will occur when the key is too small for the content given. Should occur on OTP for a simple reason, to encrypt War and Peace you need a key of the size of... War and Peace.  
Let's say the key is APPLE for the "undecipherable cypher", if the text is bigger than 5 letters the key turns to be:
APPLEAPPLEAPPLEAPPLE...
A decrypter would start to look at spaces patterns, then the most used letters on your language to start to get a pattern and get they key out.

[joepie91]

Also another rather important reminder.

If there were to be a browser vulnerability that facilitated the stealing of a file (without relying on something like Java), what would be an incredibly easy target? Exactly, a Bitcoin wallet in a default location.

The chance of a browser exploit that allows scanning the disk for a certain file is infinitely smaller than the chance of a browser exploit that allows stealing a file in a predefined location.

[BCEmporium]

If there were to be a browser vulnerability that facilitated the stealing of a file (without relying on something like Java), what would be an incredibly easy target? Exactly, a Bitcoin wallet in a default location.

Default locations are bad policies, is like a sitting duck vs a moving target (period).
And if you add an extra layer, like store the wallets in a pen you just connect when you need them, good luck for those guys with "file scanners" for look for something that isn't even in the computer.

[BCEmporium]

Compared with encrypting the file with OpenSSL and a passphrase the "file stealing attack" no longer works.

I'm giving up on you 2... useless! You speak out like wannabes! Yes, encrypt your wallet for safety and storage... but the bitcoin client will need to access it unencrypted. Unless, instead of all that nonconstructive trolling you would say something like: "Add an encryption layer in the bitcoin wallet to request a password to open the file." - still a weak password and say goodbye to it, but it would be another good security measure to take to account.
Now trolling about locks is just ridiculous!

[jgraham]

If there were to be a browser vulnerability that facilitated the stealing of a file (without relying on something like Java), what would be an incredibly easy target? Exactly, a Bitcoin wallet in a default location.

likewise a file I can use the OS search facility to find.

Default locations are bad policies, is like a sitting duck vs a moving target (period).

But when you've got something capable of tracking the target and shooting a thousand rounds per second.  You're probably not better off. (period). 

And if you add an extra layer, like store the wallets in a pen you just connect when you need them, good luck for those guys with "file scanners" for look for something that isn't even in the computer.

This is closer to a sane thought but all my scanner has to do is to either detect DBT_DEVICEARRIVAL or poll for new drives and scan them.   I'm willing to bet I can scan your drive faster than you can insert it and run bitcoin.

[BCEmporium]

You insist to talk (troll) about hypothetical attacks whereas this measure prevents existing and ongoing attacks.
Yes... and if your scan can read it telepathically can get the wallet even if you store in the brain...  

BTW, in an average used system the OS built-in "find" takes ages to actually "find" something...

[jgraham]

Compared with encrypting the file with OpenSSL and a passphrase the "file stealing attack" no longer works.

I'm giving up on you 2... useless! You speak out like wannabes!

Hey is this maud_dib again?  You are the poser here.  Just like maubby you can almost trace your knowledge of cryptography through your googling of each issue as it's mentioned.

Yes, encrypt your wallet for safety and storage... but the bitcoin client will need to access it unencrypted. Unless, instead of all that nonconstructive trolling you would say something like: "Add an encryption layer in the bitcoin wallet to request a password to open the file."

We are talking about modifying the client.  You might as well criticize your own idea by saying: "Move the wallet? but the bitcoin client will need to access it in the standard location."

still a weak password and say goodbye to it, but it would be another good security measure to take to account.

Which requires a different attack.  You are essentially saying that I'm right here.

Now trolling about locks is just ridiculous!

It's an analogy just like the dozens you've been making.

[jgraham]

You insist to talk (troll) about hypothetical attacks whereas this measure prevents existing and ongoing attacks.

No. I'm just saying that it would be trivial to modify an existing app to make your modification worthless.  If you don't understand the value in that, then you don't really understand security.  Easy enough to demonstrate though.   Make your change to the app, hand me the code for an existing filestealing exploit and your new source tree.  See if we can make it find your file.

Yes... and if your scan can read it telepathically can get the wallet even if you store in the brain...  

Strawman fallacy.  I'm talking about something that anyone who develops software can see is trivial to implement...unlike telepathy.

BTW, in an average used system the OS built-in "find" takes ages to actually "find" something...

time find / -name wallet.dat
real    0m8.198s

QED

[jgraham]

ummm... returning to the thread topic (i.e., Default Vaues), i don't understand something.

we can already control where the client looks for its configuration file (-conf=<file>), and where it looks for its data (-datadir=<dir>).

why can't we have an option like -wallet=<file> ?

it's hardly perfect, or even particularly elegant:  but it seems to me that the ability to run a wallet.dat file that was called foo.bar would eliminate about 90% of the scriptkiddie issues.

no?

Not for very long - for example under unix I could just query the process table and find out the command line arguments.  You could change the binary itself...

diff -Naur bitcoin/src/init.cpp bitcoin2/src/init.cpp
--- bitcoin/src/init.cpp        2011-07-06 16:26:16.920000001 -0400
+++ bitcoin2/src/init.cpp       2011-07-06 16:28:27.890000001 -0400
@@ -386,7 +386,7 @@
     printf("Loading wallet...\n");
     nStart = GetTimeMillis();
     bool fFirstRun;
-    pwalletMain = new CWallet("wallet.dat");
+    pwalletMain = new CWallet("boogie.dat");
     if (!pwalletMain->LoadWallet(fFirstRun))
         strErrors += _("Error loading wallet.dat      \n");
     printf(" wallet      %15"PRI64d"ms\n", GetTimeMillis() - nStart);

but then you can look at the files the app is using (kokjo did) or scan the binary...blah blah...