Seeking servers sponsorship for project

[RTGHM]

Hello:

I am seeking a sponsor for my project, SecureMSGR - SecureMSGR is a 100% private, encrypted communication system. You can send messages to others on the website, for free, and your message is encrypted the moment you send it. It stay's encrypted forever. Every 5 days we flush the database completely (message portion of database) so everything (all old messages, etc) disappear. 

Server(s) request:

SERVER FOR DATABASE:

SSD DRIVE (120 GB requested, but can work with smaller)

8 GB RAM

/29 with SWIP if available

SERVER FOR FRONTEND (USA/CANADA):

100 GB Hard Drive

2-4 GB RAM

1 IP

SERVER FOR FRONTEND (EUROPE):

100 GB Hard Drive

2-4 GB RAM

/29 with SWIP if available

Location preferred:

USA/CANADA: Any datacenter with fast connections from US-CA / CA-US - this server(s) will handle all amercian/canadian traffic (yes, even OVH for the datacenter)

EUROPE: Any datacenter with fast connections to central europe - this server(s) will handle all europe-based traffic

WHAT DO YOU GET OUT OF THIS?

We have left placements, so you can publish advertisements up there, etc. In addition, in order to earn money to keep this free forever, we plan on placing ads for money. After about 3 months time we should be able to pay for the full costs of servers.

Preview of application (screenshots):

 

[TruvisT]

Feature idea:

The ability to create custom encryption/decryption keys for messages.

 

[RTGHM]

Feature idea:

The ability to create custom encryption/decryption keys for messages.

Thanks for the idea, it's actually being considered - we're just having the issue of most people will pick in-secure keys, therefore we generate highly-secure keys. We want to stick to a high-level of security.

Noted the feature idea .

 

[trewq]

I'm just curious what the point of this project actually is?

 

[RTGHM]

I'm just curious what the point of this project actually is?

To provide a secure, encrypted, private communication platform. I have a few people assisting in application development, we're bringing this to Android and iOS devices in addition to the already built web application.

 

[trewq]

To provide a secure, encrypted, private communication platform. I have a few people assisting in application development, we're bringing this to Android and iOS devices in addition to the already built web application.

But why? Sorry, I'm having trouble understanding the usefulness of this.

 

[Jive]

This would be kind of cool if you could generate say a gpg key, share it with a friend and encrypt/decrypt messages on the devices themselves rather than server side. Your backend application would just perform storage & transport of messages, and never have reference to the keys.

 

[comXyz]

I don't think you need too strong server like that for database.

 

[splitice]

Nor do you really need a RDBMS for messages. A simpler database system could easily run this on a 256-512mb vps.

 

[raindog308]

I think the ideal instant messaging system would:

- be entirely encrypted with a unique session key per conversation.  it shouldn't matter if I pick '1234' as my application password - that's just to prevent someone from sneaking up to my laptop and using my IM client.  The IM app should pick a secure session key at random and negotiate it.  The usual public-key/negotiate a symmetrical key system would work well here, but even the private/public keypair should be unique per session.  Anything else puts forward security at risk.  CPU is cheap these days.

- have an easy mechanism to initiate conversations without need for a central database/server.  I'm not sure how best to accomplish this.  Ideally I'd be able to say "I'm raindog308 and I want to chat with hotcindy" not have to know hotcindy's IP address, port, etc., otherwise this needs to be communicated out-of-band which is a hassle. Unfortunately, IPs change, people move from coffeeshop to work to home, etc.

- If a central server is needed, it should just negotiate IPs/ports.  raindog308 at IP 172.12.13.14 port 65223, you can talk to hotcindy at IP 172.14.15.16 port 19768.  Even this makes me uncomfortable - the potential for metadata/traffic analysis is very high whenever there is a central point of reference.  

- ideally, communication would travel over a TOR/mixmaster/etc. system to prevent traffic analysis.

I believe Freenet's various apps can accomplish the above, though I've never used them.

Is there something out there that does all of the above?

 

[drmike]

 You can send messages to others on the website

So this is on-site, same website communications thing... 

Means all data stays in one place.

Means all connections are made to one place.

Highly centralized single point of failure, ala web 1.0.

Screenshots are doing you a disservice.  Looks like some backend admin panel thing, not some mega open, social tied-in sort of thing like it sort of has to be these days.

Specs are overkill in light of retention and seemingly transporting short little messages and 5 day retention.

Depending on crypto, that is perhaps the real overhead.

 

[Mid]

I'm just curious what the point of this project actually is?

probably to help groups like ISIS ? 

maybe someone from iraq/syria (or one going there) is waiting to sponsor...

 

[Nick]

Every 5 days we flush the database completely (message portion of database) so everything (all old messages, etc) disappear. 

How this is written and how I understand it is that if I send a message and 30 seconds the database is flushed my message is gone?

 

[GIANT_CRAB]

I agree with @drmike on a few points. It needs to be decentralized, else, one FBI listening on the incoming connections and poof, all data collected. 

Other than that, what differentiates this from the other already available encrypted messengers that are far more developed and had received more funding? No offense, but I don't see how this can sustain in the long run without running out of money or having government agencies knocking up your doors. 

 

[RTGHM]

I think the ideal instant messaging system would:

- be entirely encrypted with a unique session key per conversation.  it shouldn't matter if I pick '1234' as my application password - that's just to prevent someone from sneaking up to my laptop and using my IM client.  The IM app should pick a secure session key at random and negotiate it.  The usual public-key/negotiate a symmetrical key system would work well here, but even the private/public keypair should be unique per session.  Anything else puts forward security at risk.  CPU is cheap these days.

- have an easy mechanism to initiate conversations without need for a central database/server.  I'm not sure how best to accomplish this.  Ideally I'd be able to say "I'm raindog308 and I want to chat with hotcindy" not have to know hotcindy's IP address, port, etc., otherwise this needs to be communicated out-of-band which is a hassle. Unfortunately, IPs change, people move from coffeeshop to work to home, etc.

- If a central server is needed, it should just negotiate IPs/ports.  raindog308 at IP 172.12.13.14 port 65223, you can talk to hotcindy at IP 172.14.15.16 port 19768.  Even this makes me uncomfortable - the potential for metadata/traffic analysis is very high whenever there is a central point of reference.  

- ideally, communication would travel over a TOR/mixmaster/etc. system to prevent traffic analysis.

I believe Freenet's various apps can accomplish the above, though I've never used them.

Is there something out there that does all of the above?

About the who chat thing there, it's actually in development right now. We just have to work out a few bugs.

 

[RTGHM]

So this is on-site, same website communications thing... 

Means all data stays in one place.

Means all connections are made to one place.

Highly centralized single point of failure, ala web 1.0.

Screenshots are doing you a disservice.  Looks like some backend admin panel thing, not some mega open, social tied-in sort of thing like it sort of has to be these days.

Specs are overkill in light of retention and seemingly transporting short little messages and 5 day retention.

Depending on crypto, that is perhaps the real overhead.

Well drmike, yes right now iit's sent to our server then encrypted, however, when we build our apps, for example the first app Android one which will come out, what will happen is when you go to send it, it encrypts it on your device locally, then it sends it, then our server encrypts it, when the person goes to read it, we decrypt it on our end, then decrypt it on the persons device.

 

[RTGHM]

I agree with @drmike on a few points. It needs to be decentralized, else, one FBI listening on the incoming connections and poof, all data collected. 

Other than that, what differentiates this from the other already available encrypted messengers that are far more developed and had received more funding? No offense, but I don't see how this can sustain in the long run without running out of money or having government agencies knocking up your doors. 

Government agencies won't be "knocking up" my doors, however on request Iwith a valid court order in the country that the data is hosted in) I will disclose the only thing that is of value, which is the username we store, and even at that, users have the option of clicking a button and it generates them a random secure username/password - so we hold no useful information to governments.

 

[stim]

What about chipping-in with Bitmessage? Seems promising, but they still need a security audit.

https://bitmessage.org/wiki/Main_Page

 

[RTGHM]

What about chipping-in with Bitmessage? Seems promising, but they still need a security audit.

https://bitmessage.org/wiki/Main_Page

Well, this is possible - but I'd prefer to wait for a security audit before I bring it in.

 

[drmike]

Government agencies won't be "knocking up" my doors, however on request Iwith a valid court order in the country that the data is hosted in) I will disclose the only thing that is of value, which is the username we store, and even at that, users have the option of clicking a button and it generates them a random secure username/password - so we hold no useful information to governments.

Problem with legal folks isn't what you per se have when they show up.

Such apps and attention are bound to get a perma tap installed and legal methods of preventing you from telling anyone such is and has been in place.

With that, there is data and things to get at when/where users return to use this a second of 9th time.   Even if the data is crypto'd it's still suspect.   Using NSA approved crypts?  Bound to be insecure or vulnerable.

In order for something like this to work and cover your a$$, data needs to be crypted on the origin and destination points.  So where it's created and where it is read.   The server in the middle is just the mailman / dropbox and is rather unnecessary.  I'd devise a way not be sitting in the middle vulnerable or able to be targeted.