How about making this into an easy to install pre-configured linux/bsd distro?
Users would be able to download the ISO and run it on just about any machine.
From my near zero knowledge of linux and from what I recall with speaking about it to colleagues over the years a variant of NETBSD is the most hardened out of the box no?
Topic: [ANN] USSC Crypto-P2P-Server | Decentralized P2P Exchange & Application - page 2. (Read 4866 times)
May 26, 2013, 11:22:59 AM
May 26, 2013, 11:13:30 AM
Oh my Lord I almost had a heart attack. Either the president is in town or they were seriously trying to find me.
Ok. I talked to a security guard. He told me some rich lady with 20 bodyguards just went through. Maybe. But I saw them going from PC to PC looking at the screens. I got the hell outta there.
Ok I am back now.
Ok. I talked to a security guard. He told me some rich lady with 20 bodyguards just went through. Maybe. But I saw them going from PC to PC looking at the screens. I got the hell outta there.
Ok I am back now.
May 26, 2013, 10:44:15 AM
So... is this a real life soap opera?
May 26, 2013, 10:39:40 AM
I got black suits all around me all of a sudden. be back...
May 26, 2013, 10:20:08 AM
I GOT IT!
Ok. Where do I start?
Last night I was thinking and meditation about how to secure the whole system to answer Michael question in the previous posts.
I really could not come up with a good way to secure the system. So I did what I did the night I came up with the BTA solution.
I prayed.
Afterward the answers came. Three answers actually.
The first answer was:
But a legitimate node could disrupt transactions. What differentiates a rogue node from a "real" node?
I'm just saying I'd like to see you write something specific about the security of the exchange system you are proposing.
-Michael
Then I understood what he was actually asking. So I am going to rephrase the question:
What is the worst case scenario? I will tell you what it is.
A trusted sysadmin who has gone rogue.
Let's say that Gavin or Coblee's best friend and most trusted sysadmin in the whole p2p exchange network who's name is Charles decides:
How do you stop a sysadmin who has gone rogue and has physical access to a server?
The truth is you cant.
and that when the second answer came to me:
Remove the wallet.dat files? If I remove the wallet.dat files from the server then how do conduct cryptocurrency transactions?
So, I though about it. Then I hit me. Like a ton of bricks.
It was genius. Plus, I could not believe that I had the answer all along. The answer was something I was already doing for my personal security.
Then I realized the answer was to use something that I call a "disposable wallet"
(I AM WRITING THIS AS YOU READ IT... CLICK REFRESH TO UPDATE THE SCREEN)
Ok. Where do I start?
Last night I was thinking and meditation about how to secure the whole system to answer Michael question in the previous posts.
I really could not come up with a good way to secure the system. So I did what I did the night I came up with the BTA solution.
I prayed.
Afterward the answers came. Three answers actually.
The first answer was:
You use certificates and keys to secure the server nodes. A rogue node could not transact with any of the P2P server nodes.
But a legitimate node could disrupt transactions. What differentiates a rogue node from a "real" node?
I'm just saying I'd like to see you write something specific about the security of the exchange system you are proposing.
-Michael
Then I understood what he was actually asking. So I am going to rephrase the question:
Quote
What do you do to mitigate the worst case scenario?
What is the worst case scenario? I will tell you what it is.
A trusted sysadmin who has gone rogue.
Let's say that Gavin or Coblee's best friend and most trusted sysadmin in the whole p2p exchange network who's name is Charles decides:
Quote
Hey, I am tired of making peanuts for salary. I got a quarter million dollars in BTC in the wallet banks of my server. I think I will just empty them and then go to Cancun.
How do you stop a sysadmin who has gone rogue and has physical access to a server?
The truth is you cant.
and that when the second answer came to me:
Quote
Remove the wallet.dat files.
Remove the wallet.dat files? If I remove the wallet.dat files from the server then how do conduct cryptocurrency transactions?
So, I though about it. Then I hit me. Like a ton of bricks.
It was genius. Plus, I could not believe that I had the answer all along. The answer was something I was already doing for my personal security.
Then I realized the answer was to use something that I call a "disposable wallet"
(I AM WRITING THIS AS YOU READ IT... CLICK REFRESH TO UPDATE THE SCREEN)
May 25, 2013, 06:46:52 PM
Give me some time. I am going to think about this for a bit. Check back tomorrow.
May 25, 2013, 06:07:43 PM
Here is another feature I like about SDSI:
http://tools.ietf.org/html/rfc2693
What do you think? Is SPKI/SDSI something that can fit in this p2p design?
Give me some feedback.
http://tools.ietf.org/html/rfc2693
Quote
4. Delegation
One of the powers of an authorization certificate is the ability to
delegate authorizations from one person to another without bothering
the owner of the resource(s) involved. One might issue a simple
permission (e.g., to read some file) or issue the permission to
delegate that permission further.
Two issues arose as we considered delegation: the desire to limit
depth of delegation and the question of separating delegators from
those who can exercise the delegated permission.
One of the powers of an authorization certificate is the ability to
delegate authorizations from one person to another without bothering
the owner of the resource(s) involved. One might issue a simple
permission (e.g., to read some file) or issue the permission to
delegate that permission further.
Two issues arose as we considered delegation: the desire to limit
depth of delegation and the question of separating delegators from
those who can exercise the delegated permission.
What do you think? Is SPKI/SDSI something that can fit in this p2p design?
Give me some feedback.
May 25, 2013, 05:58:13 PM
Another feature I like about SDSI:
http://tools.ietf.org/html/rfc2693
http://tools.ietf.org/html/rfc2693
Quote
2.8 Fully Qualified SDSI Names
SDSI local names are of great value to their definer. Each local
name maps to one or more public keys and therefore to the
corresponding keyholder(s). Through SDSI's name chaining, these
local names become useful potentially to the whole world. [See
section 2.6.2 for an example of SDSI name chaining.]
To a computer system making use of these names, the name string is
not enough. One must identify the name space in which that byte
string is defined. That name space can be identified globally by a
public key.
It is SDSI 1.0 convention, preserved in SPKI, that if a (local) SDSI
name occurs within a certificate, then the public key of the issuer
is the identifier of the name space in which that name is defined.
Ellison, et al. Experimental [Page 11]
RFC 2693 SPKI Certificate Theory September 1999
However, if a SDSI name is ever to occur outside of a certificate,
the name space within which it is defined must be identified. This
gives rise to the Fully Qualified SDSI Name. That name is a public
key followed by one or more names relative to that key. If there are
two or more names, then the string of names is a SDSI name chain.
For example,
(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim therese)
is a fully qualified SDSI name, using the SHA-1 hash of a public key
as the global identifier defining the name space and anchoring this
name string.
SDSI local names are of great value to their definer. Each local
name maps to one or more public keys and therefore to the
corresponding keyholder(s). Through SDSI's name chaining, these
local names become useful potentially to the whole world. [See
section 2.6.2 for an example of SDSI name chaining.]
To a computer system making use of these names, the name string is
not enough. One must identify the name space in which that byte
string is defined. That name space can be identified globally by a
public key.
It is SDSI 1.0 convention, preserved in SPKI, that if a (local) SDSI
name occurs within a certificate, then the public key of the issuer
is the identifier of the name space in which that name is defined.
Ellison, et al. Experimental [Page 11]
RFC 2693 SPKI Certificate Theory September 1999
However, if a SDSI name is ever to occur outside of a certificate,
the name space within which it is defined must be identified. This
gives rise to the Fully Qualified SDSI Name. That name is a public
key followed by one or more names relative to that key. If there are
two or more names, then the string of names is a SDSI name chain.
For example,
(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim therese)
is a fully qualified SDSI name, using the SHA-1 hash of a public key
as the global identifier defining the name space and anchoring this
name string.
May 25, 2013, 05:33:43 PM
A solution I am looking at is a type of automated hierarchical key generation. I want to remove the human element as much as possible. I will give the "mayor" of the city power over they top level nodes. But everything else from there would be automated by the nodes according to hierarchy. I will explain later.
May 25, 2013, 05:11:04 PM
What do you think about something like this? SPKI/SDSI:
http://csrc.nist.gov/groups/ST/key_mgmt/documents/Sept2012_Presentations/LAMBERT_CKMW2012.pdf
I am looking at this because it doesn't use a CA plus there are some other customizations I can make.
From Wikipedia:
http://en.wikipedia.org/wiki/SPKI
http://tools.ietf.org/html/rfc2692
http://tools.ietf.org/html/rfc2693
http://csrc.nist.gov/groups/ST/key_mgmt/documents/Sept2012_Presentations/LAMBERT_CKMW2012.pdf
I am looking at this because it doesn't use a CA plus there are some other customizations I can make.
From Wikipedia:
Quote
SPKI/SDSI does not define a role for a commercial Certificate Authority (CA). In fact, one premise behind SPKI is that a commercial CA serves no useful purpose.[1] As a result of that, SPKI/SDSI is deployed primarily in closed solutions and in demonstration projects of academic interest. Another side-effect of this design element is that it is difficult to monetize SPKI/SDSI by itself. It can be a component of some other product, but there is no business case for developing SPKI/SDSI tools and services except as part of some other product.
http://en.wikipedia.org/wiki/SPKI
http://tools.ietf.org/html/rfc2692
http://tools.ietf.org/html/rfc2693
May 25, 2013, 04:52:22 PM
This looks awesome wish you the best, can't help any as i can't code anything.
That's fine. Whatever you can do would be appreciated. We all need to work together to help come up with a solution.
May 25, 2013, 04:48:10 PM
This looks awesome wish you the best, can't help any as i can't code anything.
May 25, 2013, 04:43:07 PM
You use certificates and keys to secure the server nodes. A rogue node could not transact with any of the P2P server nodes.
But a legitimate node could disrupt transactions. What differentiates a rogue node from a "real" node?
I'm just saying I'd like to see you write something specific about the security of the exchange system you are proposing.
-Michael
Let me come up with a good security implementation for this. I will put my brain to work to see if I can come up with an original security scheme.
I have been looking at some sort of original SPKI/SDSI (Simple Public Key Infrastructure / Simple Distributed Security Infrastructure) type implementation, along with some other schemes I am looking into as well.
SPKI/SDSI Link: http://csrc.nist.gov/groups/ST/key_mgmt/documents/Sept2012_Presentations/LAMBERT_CKMW2012.pdf
Give me some time...
May 25, 2013, 03:04:29 PM
Hey, I am looking for a community collaboration here.
I will be honest. I have an extensive background in enterprise applications, Storage Area Networks, enterprise networking, enterprise etc...
I could build this whole system right now without writing a single line of compiled code.
Just using Linux, Apache, MySQL, pHp, (LAMP), WAMP, bitcoin, bittorrent, and a host of Linux tools (ssh, cron, bash, etc..).
It wouldn't be pretty; but it would work.
Would it be secure? not very.
But I guarantee you that it would work.
Yes I was a firewall admin (checkpoint, cisco, netscreen, fortinet, etc...) so I know that security is a non-issue. There are ways to secure the transactions.
Going forward I will try to include some suggestions on security in my updates.
I am looking for you guys to pipe in with suggestions and other stuff too. I don't want to do this all by myself.
I will be honest. I have an extensive background in enterprise applications, Storage Area Networks, enterprise networking, enterprise etc...
I could build this whole system right now without writing a single line of compiled code.
Just using Linux, Apache, MySQL, pHp, (LAMP), WAMP, bitcoin, bittorrent, and a host of Linux tools (ssh, cron, bash, etc..).
It wouldn't be pretty; but it would work.
Would it be secure? not very.
But I guarantee you that it would work.
Yes I was a firewall admin (checkpoint, cisco, netscreen, fortinet, etc...) so I know that security is a non-issue. There are ways to secure the transactions.
Going forward I will try to include some suggestions on security in my updates.
I am looking for you guys to pipe in with suggestions and other stuff too. I don't want to do this all by myself.
May 25, 2013, 01:34:54 PM
You use certificates and keys to secure the server nodes. A rogue node could not transact with any of the P2P server nodes.
But a legitimate node could disrupt transactions. What differentiates a rogue node from a "real" node?
I'm just saying I'd like to see you write something specific about the security of the exchange system you are proposing.
-Michael
May 24, 2013, 03:26:23 PM
Quote
16. home-virtual-server-001 (on physical p2p-server-001) then submits the confirmation-reply to it own send-queue while broadcasting pickup notification to p2p network.
17. Whatever Tier-I BTA-virtual-server that is available on the network will pickup the confirmation-reply and route it back to BTA-virtual-server-002 (this could be BTA-virtual-server-003 or some other BTA-virtual-server. What is important is that all transactions require the interaction of more than one BTA-virtual-server in order to complete)
17. Whatever Tier-I BTA-virtual-server that is available on the network will pickup the confirmation-reply and route it back to BTA-virtual-server-002 (this could be BTA-virtual-server-003 or some other BTA-virtual-server. What is important is that all transactions require the interaction of more than one BTA-virtual-server in order to complete)
18. BTA-virtual-server-002 retrieves the confirmation-reply from the receive queue and forwards it back to the BTA Tier-I exchange service on the same physical server.
19. The BTA Tier-I exchange service (on physical p2p-server-002)...
20.
(I WILL FINISH TOMORROW... CHECK BACK. THANKS TO EVERYONE FOR THE SUPPORT.)
May 24, 2013, 03:01:52 PM
Quote
(Continuing...)
7. BTA Tier-I exchange service (on physical p2p-server-002) sees Bob's request to send Alice 10 coins to her personal wallet address. BTA Tier-I exchange service drafts confirmation request (from Bob to send Alice 10 coins to her personal wallet address).
8. The BTA Tier-I exchange service sends the confirmation request to the p2p application stack.
9. BTA-virtual-server-002 receives the request for confirmation (Bob's) from the application stack. But security rules prohibit any BTA-virtual-server from directly executing request from the same physical server. So BTA-virtual-server-002 sends confirmation request to queue and broadcasts to the p2p network for utility pickup.
10. BTA-virtual-server-003 (on physical p2p-server-003) receives utility pickup request from it's listener service and adds BTA-virtual-server-002 to it's own pickup route list.
11. BTA-virtual-server-003 routes through the p2p network and picks up the utility request from BTA-virtual-server-002. Because this is a utility request there is no need to add the request to the Tier-I exchange database.
12. BTA-virtual-server-003 then starts to process the utility request and add home-virtual-server-001 (Bob's home server) to its own drop-off route list.
13. BTA-virtual-server-003 then routes through the p2p network and adds the confirmation request to home-virtual-server-001 receive queue
14. home-virtual-server-001 retrieves the confirmation request from its own receive queue and forwards to Bob's client.
15. Bob receives on screen the confirmation request to send Alice 10 coins. Bob then confirms the request.
16. home-server-001 then
(CHECK BACK LATER TODAY FOR THE REST... SEE YA!)
7. BTA Tier-I exchange service (on physical p2p-server-002) sees Bob's request to send Alice 10 coins to her personal wallet address. BTA Tier-I exchange service drafts confirmation request (from Bob to send Alice 10 coins to her personal wallet address).
8. The BTA Tier-I exchange service sends the confirmation request to the p2p application stack.
9. BTA-virtual-server-002 receives the request for confirmation (Bob's) from the application stack. But security rules prohibit any BTA-virtual-server from directly executing request from the same physical server. So BTA-virtual-server-002 sends confirmation request to queue and broadcasts to the p2p network for utility pickup.
10. BTA-virtual-server-003 (on physical p2p-server-003) receives utility pickup request from it's listener service and adds BTA-virtual-server-002 to it's own pickup route list.
11. BTA-virtual-server-003 routes through the p2p network and picks up the utility request from BTA-virtual-server-002. Because this is a utility request there is no need to add the request to the Tier-I exchange database.
12. BTA-virtual-server-003 then starts to process the utility request and add home-virtual-server-001 (Bob's home server) to its own drop-off route list.
13. BTA-virtual-server-003 then routes through the p2p network and adds the confirmation request to home-virtual-server-001 receive queue
14. home-virtual-server-001 retrieves the confirmation request from its own receive queue and forwards to Bob's client.
15. Bob receives on screen the confirmation request to send Alice 10 coins. Bob then confirms the request.
16. home-server-001 then
(CHECK BACK LATER TODAY FOR THE REST... SEE YA!)
16. home-virtual-server-001 (on physical p2p-server-001) then submits the confirmation-reply to it own send-queue while broadcasting pickup notification to p2p network.
17. Whatever Tier-I BTA-virtual-server that is available on the network will pickup the confirmation-reply and route it back to BTA-virtual-server-002 (this could be BTA-virtual-server-003 or some other BTA-virtual-server. What is important is that all transactions require the interaction of more than one BTA-virtual-server in order to complete)
(REFRESH THIS PAGE... I WILL UPDATE IN A FEW MINUTES)
May 24, 2013, 03:00:47 PM
All the best with your project.
May 24, 2013, 02:47:37 PM
Its obvious that you did not read all of the post.
Go back and read about the multi-teir BTA
Its a decentralized exchange.
What that means is that even if you were somehow able to hack one of the tier-I BTA-virtual-servers you would only affect a very very small percent of all the users on the exchange. Its decentralized!
This design is designed to be resistant to seizure and DDoS attacks. Theft is mitigated through the use of multi-server interactions. (You might find out if you let me finish my example).
What would you propose for a decentralized exchange? Ripple?
I worked at four banks and at a Internet Data Center. Most of the platforms I supported had systems that were not "compiled into binary". What planet do you live on?
Go back and read about the multi-teir BTA
Its a decentralized exchange.
What that means is that even if you were somehow able to hack one of the tier-I BTA-virtual-servers you would only affect a very very small percent of all the users on the exchange. Its decentralized!
This design is designed to be resistant to seizure and DDoS attacks. Theft is mitigated through the use of multi-server interactions. (You might find out if you let me finish my example).
What would you propose for a decentralized exchange? Ripple?
I worked at four banks and at a Internet Data Center. Most of the platforms I supported had systems that were not "compiled into binary". What planet do you live on?
May 24, 2013, 02:37:02 PM
The system should be coded to run on an LAMP server using PHP and MySQL only. Perl can be used to facilitate server side scripts and systems commands as well.
n00b! Neither scalable nor secure... just n00b friendly...
Its a p2p network. What do you mean scalable?
This is an overall design for you to code however you want. If it is not secure it will be your own fault.
I assure you I am not a newbie. Stop being a troll and come up with a better solution... if you can.
I recommended MySql to demonstrate the ease in which this system could be made. You can use any database that you would like. That's up to you. The choice is yours.
What OS would you recommend? Windows?
It is obvious that you either didn't read all of my posts, or your a newbie with no experience whatsoever.
I wasn't referring to the OS. My comment was for "using PHP and MySQL only" . Anyone that has any experience, wouldn't touch something as important as an exchange with php and mysql.
Both PHP and mysql are bloated "one size fits all solutions" with loads of bugs and vulnerabilities. The only reason to use them is to get something deployed quick without much concern of performance or security. And then you expect other people to be able to run them in a secure manner?
Anything thats not compiled into a binary is not a good fit for something that needs to be secure.
Jump to: