Bitcoin Forum
December 07, 2016, 10:45:29 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: The biggest security hole -> Default values  (Read 3540 times)
jgraham
Full Member
***
Offline Offline

Activity: 140


<Pretentious and poorly thought out latin phrase>


View Profile
July 06, 2011, 07:01:26 PM
 #21

The indecipherable cipher suffers from patterns,

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

Quote
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.

Quote
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.

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

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

Quote
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.
 Roll Eyes

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.

I'm rather good with Linux.  If you're having problems with your mining rig I'll help you out remotely for 0.05.  You can also propose a flat-rate for some particular task.  PM me for details.
1481150729
Hero Member
*
Offline Offline

Posts: 1481150729

View Profile Personal Message (Offline)

Ignore
1481150729
Reply with quote  #2

1481150729
Report to moderator
1481150729
Hero Member
*
Offline Offline

Posts: 1481150729

View Profile Personal Message (Offline)

Ignore
1481150729
Reply with quote  #2

1481150729
Report to moderator
1481150729
Hero Member
*
Offline Offline

Posts: 1481150729

View Profile Personal Message (Offline)

Ignore
1481150729
Reply with quote  #2

1481150729
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
July 06, 2011, 07:16:43 PM
 #22

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
Legendary
*
Offline Offline

Activity: 1050

You are WRONG!


View Profile
July 06, 2011, 07:33:33 PM
 #23

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.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
July 06, 2011, 07:38:12 PM
 #24

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  Grin Grin Grin
5 line trojan (with 20 Mb batch of attached DLL's?)  Grin
Alex Beckenham
Full Member
***
Offline Offline

Activity: 154


View Profile
July 06, 2011, 07:39:57 PM
 #25

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
Full Member
***
Offline Offline

Activity: 126


View Profile
July 06, 2011, 07:45:49 PM
 #26

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
Full Member
***
Offline Offline

Activity: 126


View Profile
July 06, 2011, 07:46:56 PM
 #27

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
Legendary
*
Offline Offline

Activity: 938



View Profile
July 06, 2011, 07:50:32 PM
 #28


Quote
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!  Grin Grin Grin
"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

 Grin Grin Sending patterns.. I'm still laughing!!!  Grin Grin
kokjo
Legendary
*
Offline Offline

Activity: 1050

You are WRONG!


View Profile
July 06, 2011, 08:00:00 PM
 #29

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  Grin Grin Grin
5 line trojan (with 20 Mb batch of attached DLL's?)  Grin
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?

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
kokjo
Legendary
*
Offline Offline

Activity: 1050

You are WRONG!


View Profile
July 06, 2011, 08:03:14 PM
 #30


Quote
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!  Grin Grin Grin
"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

 Grin Grin Sending patterns.. I'm still laughing!!!  Grin Grin
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.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
jgraham
Full Member
***
Offline Offline

Activity: 140


<Pretentious and poorly thought out latin phrase>


View Profile
July 06, 2011, 08:25:39 PM
 #31

<<long unnecessary, irrelevant and unasked exposition>>  Grin

Quote
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.

I'm rather good with Linux.  If you're having problems with your mining rig I'll help you out remotely for 0.05.  You can also propose a flat-rate for some particular task.  PM me for details.
BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
July 06, 2011, 08:28:05 PM
 #32

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.  Grin
Despite all the virus for Bitcoin I came across lately were for Windows... probably your should think about a trojan.bat  Grin

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.  Grin
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
Sr. Member
****
Offline Offline

Activity: 294


View Profile
July 06, 2011, 08:29:41 PM
 #33

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.

Like my post(s)? 12TSXLa5Tu6ag4PNYCwKKSiZsaSCpAjzpu Smiley
Quote from: hawks5999
I just can't wait for fall/winter. My furnace never generated money for me before. I'll keep mining until my furnace is more profitable.
BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
July 06, 2011, 08:35:10 PM
 #34

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
Legendary
*
Offline Offline

Activity: 938



View Profile
July 06, 2011, 08:38:29 PM
 #35

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
Full Member
***
Offline Offline

Activity: 140


<Pretentious and poorly thought out latin phrase>


View Profile
July 06, 2011, 08:55:40 PM
 #36

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).  Roll Eyes

Quote
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.

I'm rather good with Linux.  If you're having problems with your mining rig I'll help you out remotely for 0.05.  You can also propose a flat-rate for some particular task.  PM me for details.
BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
July 06, 2011, 08:58:57 PM
 #37

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...   Roll Eyes

BTW, in an average used system the OS built-in "find" takes ages to actually "find" something...
jgraham
Full Member
***
Offline Offline

Activity: 140


<Pretentious and poorly thought out latin phrase>


View Profile
July 06, 2011, 09:01:45 PM
 #38

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.

Quote
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."


Quote
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.

Quote
Now trolling about locks is just ridiculous!

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


I'm rather good with Linux.  If you're having problems with your mining rig I'll help you out remotely for 0.05.  You can also propose a flat-rate for some particular task.  PM me for details.
jgraham
Full Member
***
Offline Offline

Activity: 140


<Pretentious and poorly thought out latin phrase>


View Profile
July 06, 2011, 09:08:33 PM
 #39

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.

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

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

Quote
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

I'm rather good with Linux.  If you're having problems with your mining rig I'll help you out remotely for 0.05.  You can also propose a flat-rate for some particular task.  PM me for details.
jgraham
Full Member
***
Offline Offline

Activity: 140


<Pretentious and poorly thought out latin phrase>


View Profile
July 06, 2011, 09:37:01 PM
 #40

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...


I'm rather good with Linux.  If you're having problems with your mining rig I'll help you out remotely for 0.05.  You can also propose a flat-rate for some particular task.  PM me for details.
Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!