Very secure forum / group communication system, looking for feedback

Hello I am working on a project and wonder what you think about it. I am new to cryptology but this seems to me to be a very good system to encrypt forums and other sorts of group communication. Please respond even if just to tell me you don't want to read it. Thanks.



The Problem: Secure online communications between members of a given group, where the following needs are met

A. The communications of the group are protected against those not in the group

B. The communications between individuals or sub groups in the main group are secure from all others in the group.

C. There exists substantial anonymity for all members of the group, and for the server where sorting of communications takes place.

D. Anonymous authentication is required for every action. Anonymous authentication meaning member X in the group can be confirmed to be the same member X at a later point as he was at a previous point, with out the verifier having to actually know anything about member X.

E. Plausible deniability offered for all members of the group.


The Solution: An open source software suite that includes the following components:

A control panel: For use by administrators or central figures to create a set of config files which can be plugged into the next two parts. The config files would need to be transferred to members of the group securely, preferably with OTR messaging or something similar. Also for doing administrative things from.

A host program: To be installed on the server which acts as a central hub for encrypted communications between members of the group. Basically prepares the host to work with clients, pointed towards it by the client config file.

A client program: An open source group independent publicly released program that can have config files plugged into it to make it more specific to any given group. The client includes a GUI designed to be similar to an Internet forum, allowing for threads (public to the entire group) and PMs (between individuals, or sub groups).

An installation program: This installs the client program. It will in general ask for a USB drive (although one technically wont be needed for the sake of simplicity we will assume one is used). It will create an encrypted shell file filling up the entire USB drive except for a small area for a decryption program. It will also be made to be similar to u3 where it is plug and play. The encrypted shell file should also have a secondary passphrase that leads to a fake area with user provided fake things they can pretend they wanted to keep secret if they are ever ordered by thugs to turn over their passphrase. It is best to make it so there is an option for this added security rather than it being required as if it is required it will be apparent that it is being used.








The life cycle of the program from Admins perspective:

1. An administrative figure hoping to start a secure group downloads the package. They run the Control Panel program. They are at this point required to insert a USB key (again, this isn't set in stone but we assume it is used). The USB has an encrypted shell file (Aes-serpent-twofish) with a hidden area opened by a second passphrase. The hidden area is filled with pretend files the admin can pretend they were wanting to hide.

2. The remainder of the USB consists of decryption software and u3 type stuff that allows for auto launching.

2. After the USB is prepared (one-two passphrases, admin will need to remember both of them if he chooses for plausible deniability, one if not) a key pair (User-authorized) is generated. I think this public key should us the algorithm HIME(R) and whirlpool as the RNG.


(Please understand I really only have a fundamental grasp of public key encryption so this might not be an appropriate algorithm. I think it is a more secure alternative than RSA though and will work fine for signatures).


3. The public HIME(R) key is saved to the host.config file that will be generated.

4. The private HIME(R) key is stored on the admins USB. It doesn't need further encryption in my opinion as the entire USB is already encrypted with aes-serpent-twofish. If there are advantages to further encryption, I think it should use a keyfile replacing the passphrase, to minimize the amount of passphrases the admin needs to memorize.

5. A 4,096 bit keyfile (group-decrypt) is generated with Whirlpool PRNG and saved to the client.conf file that will be generated individually.

6. The admin sets up the server and gets it running as a Tor hidden service. This should all be very easy to do from the interface of our program, similar to how easy it is to set up a hidden service using Tork.

7. The onion pointer to the hidden service needs to be included in each client.conf file

___

8. Now that everything is essentially set up, the admin needs to invite users. He will do this by generating them a client.conf file from the control panel program. In addition to the (group-decrypt) keyfile and the onion pointer, this file is also signed by the (user-authorized) key pair the program generated earlier. Since each config file is essentially the same, we will need a short random string to be generated and included in each one prior to being signed I believe.




Now we transition to the point of view of a member:


1. You want to join a group so you download the independent open source software. You run the installer program and your USB gets set up as has been explained before.

2. You also have the following things generated (NOTE: admins also need all of these, they should also be generated when creating a new group template with the control panel)

A. Encryption/signature key pair for member to member or sub group messages (specific-privacy-key). The following standard should be used for this key pair: HIME(R) / ACE-KEM (sign/encrypt).

B. Signature key pair for constant authentication (still-me) : HIME(R)

For what B is used I think there is no reason to further encrypt the key. For A however I think a passphrase should be required (no keyfiles allowed), the private key should be encrypted with serpent-256 and require a password to decrypt.

3. After the generating is done and the client.config file inputted into the client program:

A. You connect to the central server from the client. When you first connect, it establishes that you are using appropriate client compatible versions whatever....

B. You are verified that the Admin wanted you to be a part of this group. This is done by your client.config file uploading itself to the host (as always over the tor network, I will stop saying this so much but understand all traffic is over tor). Once the client config is on the host, the authenticity of the signature it is signed with is checked against the public key that the Admin has in the host.config file. If the signature authenticates that is a pretty good sign that you were given the client.config file by the Admin of the group.

C. The public key of (still-me) and (specific-privacy-key) are uploaded to the central hidden service. Both should be signed with (still-me).

D. You are now set as a member of the group. You may need to enter a name in this area so the server has something to identify you by consistently in your postings, similar to a screen name on a forum. Any names should need to be signed with (Still-me).

E. Note that after your (still-me) public key is on the server, every single command you sent to the client needs to be signed with the private key. Since this key made use of a keyfile it will be automated, you wont need to type in a passphrase every single time. This is for user authentication after login. I talk about login more below.

F. When you first establish a connection with the host a randomly generated string will be sent from the host to the client. The client will sign the post with (still-me) key and send it back to the server automatically. This is the act of login, after a user has logged in and can see the main listings, each move they make is authenticated automatically with the (still-me) key.




G. When a user posts a message for the public membership to see, that message is encrypted symmetrically with Serpent-256 using (group-decrypt) as a keyfile.

H. When other members log on to check messages they receive the Serpent-256 encoded messages and they are automatically decrypted client side using the (group-decrypt) keyfile which all members share (as it is part of the client.config file they got signed from the admin)

I. When a member sends a private message to another individual or a group of individuals, first the client connects to the host and finds all the public (specific-privacy-key) keys for everyone the message is intended to go to. The keys should be saved client side as well. When people upload a new key if they for whatever reason change it, it needs to be signed not only with (still-me) but with their old (specific-privacy-key) key (requiring a passphrase and a keyfile to switch keys).


Ok whew getting a bit tired of talking about this but I think that is the general concept pretty well. There are a few other things I want to address though:

1.To protect against keyloggers users should have the option to type their USB passphrases in on a digital keypad with all the letters numbers etc. They should also rotate each time a new one is clicked, so positioning the mouse with out taking a screen cap will be useless.

2. The first thing a user should see when they plug their USB in to any computer is the aforementioned keypad (autostarted similar to U3). They type in their passphrase to decrypt the encrypted volume on the USB holding the more interesting things. One passphrase leads to regular client and all the information so far stored, the other to the bogus area made earlier.

3. Absolutely everything takes place over Tor. Tor is really slow, but since we are only sending chunks of encrypted text, it really shouldn't be noticeable lag even. Tor uses layered encryption from enter node to .onion server when communicating with a .onion server. This removes the need for SSL and also disguises the fact that so much pre-encrypted **** is flying around between this server and clients.

4. Absolute care should be taken to make the entire process as smooth and seamless for the end user as possible. They should need to do nothing that doesn't involve clicking between a few simply worded button commands, and typing in the passphrases when needed. This absolutely must be an easy to use system as it is hard to understand. As far as the user is concerned this should be no more difficult than using hushmail (although significantly more secure ;-) )

 

To put it simple:

Client and server side programming that makes use of encryption and authentication on a lot of different levels, mainly full database encryption with a symmetric key (encrypted data stored and organized server side after being uploaded over the tor network) and encrypted PM system using asymmetric keys, plus all the other stuff I said above this is just the general concept in a nut shell.

Seems pretty secure / anonymous to me, the only way for someone to get into the main area would be to compromise a member or get invited themselves, and all the pms would be totally private end to end between two people. Also the actual server and the members would be pretty difficult to trace down thanks to Tor.

This could work good for like message boards of people in communist china or something? Or are there flaws.

 

Two such systems already exist. They are privately designed and maintained, not for the general public. Are you planning on developing an open system?

 

I am not a programmer myself and probably would have a hard time to do this correctly, but I am working closely with people who are developing it, it was mostly my idea I was unaware systems like this existed already but am not too surprised it is nothing ground breaking just a bunch of different systems applied to a whole. What are the two systems you mention I would like to learn more about them, what is the primary reason for them?

But yes eventually this will be released as an open source project it is being developed in C right now but I was wanting to look for feed back before we went to far with it in case there was anything I might have missed.

 

The first is a forum called Distributed City which runs on tokens and hashes, all internal messaging is PGP encrypted, transparently. This is a decade old implementation.

There is a next-generation system being developed as a project of an undisclosed group that will be deployed this year. It will far surpass the Distributed City forum and integrate a new type of "mixmaster" system that has not yet been publicized.

 

That (distributed city) is simply GPG encryption implemented in the actual PHP, if I am not mistaken (and I could be hehe). Not very secure really, as hushmail has proven (although not with php there). Sure messages sent are encrypted, but since it is done server side if the server is ever in the possession of the adversary they could sniff messages in the split second that they are unencrypted on the server. It worked to get passphrases for hushmail users, a slightly different implementation would get plain text messages. Messages would only be safe and have meaningful encryption if they were sent before the server is compromised, and in that case why even bother to encrypt at all.

The reason for a client and server side component to the system is so that the encryption and decryption can take place clientside, both for PMs and for symmetric encryption of single posts. The actual server would be nothing other than a frame work for distributing tagged blocks of encrypted code, even if the server was run by the adversary they couldn't compromise the system at all unless they were invited into it or compromised a member who had been, where as distributed city it seems the adversary could easily compromise all the security if they got control of the server (this all assumes that they are just using the php/gpg libraries to do the encryption, I can't really tell there is very little info on it but it seems to me no client side component and really a system like this will never be entirely secure unless it is distributed).

I am interested in your project but understand that more details can't be released. Mixmaster huh, isn't that like mixminion? I thought that was for E-mails. Will the new mix master system have anonymity advantages over a clientside program using tor to connect to a predetermined .onion server?

 

The new project is superior to mixmaster. We should take this offline. Give me your messenger info over private message.

 

Here is a more detailed blueprint, let me know if any holes are found.

 

I'll be very interested to see how this turns out; it sounds like an excellent means of private communication.

One thing that I think would be cool (depending on how 007 you want to be with this system)... is to have a 'duress' passphrase which triggers the automatic expiration/revocation of your key (access) to the system.

My reasoning there is, rather than just leading people to a bogus area of a USB or coming up 'denied' if they tried to guess over & over, you could feed your assailant a predetermined "seppuku" passphrase, if you will.

Regarding the server, who technically controls it in this scenario?.. if an administrator, do they play God (all-seeing/all-knowing) or is the system designed to prevent misuse/be autonomous/fail securely.

My apologies if you've covered that stuff in your posts - they're a lengthy read and I don't understand a lot of the mechanisms

 

Double post

 

For the keys to be expired or the hidden data to be wiped, it would need to be mounted, and if it is mounted then the contents can for one be compromised and for two be proven to exist. It is realistic that not telling people about the secondary password doing a wipe could be seen a prosecuted as destroying evidence (as always assume I am talking about a government that oppresses the people, for example China). Also if it is thugs with a Gun to your head, they might not be happy once they find out what you did.

I think for this reason it is best to try and hide the information, rather than confirm it exists by trying to erase it.


The server can be controlled by anyone. There would actually be slight security advantages if the server is maintained by someone who is NOT a member of the group. The most an adversary with the server who is NOT a member of the group can do is ruin the system, they couldn't do a man in the middle attack as far as I can see, as all information stored on the server (including public keys) is encrypted with a symmetric encryption algorithm and they don't have the keyfile for it unless they are a member of the group (so they can't see it, and if they spoof it the spoofing will be immediately detected). They can't even gain information on who is communicating with who thanks to the unique PM system. Even if a member of the group does control the server, it will maintain a large amount of its security, but be slightly more subject to man in the middle attacks if the admin himself is the adversary.

The point of this program is in part to secure a forum so well that even if the adversary has total control of the server it is hosted on, they can't penetrate the security only destroy the system. It does assume that the adversary doesn't START in control of the system though, but even if the adversary starts in control of the system and is a member of the group, there is still a decent amount of protection, it is hard to defend against that scenario though but I think this system still has at least a decent amount of security against that. The main concern if they start as the administrator and server owner of the group is that they could instantly man in the middle public keys between two people and pretend to be both of them to the other. But if a key pair is transmitted once with out being spoofed by a man in the middle, all future communications will be secure as new keys need to be signed with old keys and they wouldn't have the old key. Can anyone think of a way to fight a man in the middle attack against public keys, assuming the adversary is a member of the group and also owns the server? I will need to think of that one, the only thing I can think of is people should distribute and authenticate their initial keys outside the server structure as well as through it.

The admin has no special abilities that others do not have as far as a backdoor or anything.


...Hmmm been thinking about ways to avoid a man in the middle attack during initial key exchange and research has brought me to something called MQV, can anyone explain to me in laymans terms how this works and if it would be effective to help protect against a server administrator who is a member of the group?

 

Too many big posts in a row, looked ugly. See final blueprint below to see how we ended up doing the authentication system, and also how we defend against MIM attacks.

 

Okay sorry to post so much in this thread and everything being so long. This is the final blueprint I think though. Programming has started based off this and we could find no flaws in the final design. This system outlined here will most likely be the one we develop. If anyone can find flaws in it PLEASE let me know, and also if anyone can think of improvements or additional features, now is the time to say so because otherwise we will need to redo stuff as the programming is started. The final product will be released totally free and open source. We are relying on other open source projects to get it done and will respect all their license requirements. Also we decided to call it Hive Mind:

 

Some notes:

Client Installer

1. If the system has an onboard RNG, dual RNGs, or onboard AES hardware, like the C7-M processor, you should use them. This will significantly increase the speed of the processing of all the crypto, reducing the crypto overhead to near zero.

2. For the logon to the system, use random #s of asterisks for each character typed so that an attacker cannot know the password length if they happen to shoulder surf.

3. Deniability: Also add a fourth options SSH FileSystem for remotely stored profiles/containers. That way there is no onboard system to lose or destroy, it can be in the cloud on any network.

4. Don't limit the maximum length of the password, and allow more than the standard 93 characters. This will greatly enhance your entropy. Also allow the entry system to accept a paste from the clipboard, otherwise you limit it to printable characters.

5. To avoid these attacks you listed, employ Secret Sharing, requiring multiple people to log on to edit the system or set it up. That way one login won't compromise the system, and can be revoked if they are key based.

 

Server & Server Installer

1. Secret Sharing again.

2. Consider not making it a tor hidden service. These are discoverable by many methods. Instead consider making it run distributed in a secure environment with a dynamic address, like VMs. Hiding the machine will not be possible. Instead focus on making the machine fail-secure, and tamper proof so that it is self-destructed if compromised, and has backups elsewhere that can take it's place live.

 

Administrative Control Panel

1. Secret Sharing

2. Key authentication with revokation certificates.

3. .onion is unimportant. Instead consider using your own darknet or making it publicly accessible. You cannot rely on tor hidden services, and it will *drastically* slow down your services, and may even render them unusable.

 

If your clients or server run tor, they will be compromised. It's only a matter of time. To properly run tor with protection will require cordoning off of the tor process inside it's own virtual machine, and not allowing it to look at or speak to anything it doesn't need access to. It must be an internal system of least-privileges.

 

The Client

1. All hashes must be salted, otherwise you are open to rainbow table attacks.

2. All of the encryption you've used will require time division access. If you require so much hashes and crypto this will be very processor intensive on systems, and authentication may take many seconds per transaction. This means that an attacker can DOS your system by throwing lots of hashes at it and requiring it to perform lookups or recryption to match the hash.

3. An attacker can start to kill your system by registering lots of keys to overflow your buffers and tables and memory.

4. All inputs must be sanitized against breakouts, server and client side. Fuzzing will be required.

 

Protection against tracing

1. Let the user choose what network they want to use, if at all. People have different threat models, and putting it all in one network is centralizing your risk in a leaky basket. Consider letting clients advertise as gateway nodes between networks.

2. You cannot use PortableTor or Operator or similar. This will 100% compromise your system. I can take these softwares and turn them into remote rootkits to do network scanning and execute arbitrary code. We can even hijack your network and perform quiet traffic analysis of all your communications without you noticing. Tor processes must be run inside a virtual machine. Use TorVM or JanusVM if you must use Tor.

If you want a superior network design, you have the opportunity to make one here. You could use the system proposed by Magnus Brading at Defcon 16. This would be well-suited for you.

2. You cannot fight keylogging. Any such claim is voodoo. That includes onscreen keyboards too. If the system the user is using is compromised, it cannot be uncompromised. This is something you cannot defend against using the host operating system. An OS with a rootkit or keylogger can be hidden and defeat even virtual keyboards by capturing the emulated output instead of the input at a certain register. This is because you are relying on the OS to tell you if it has integrity, which it can't do as that is circular logic. What you can do is prevent against software keylogging only. To do that you will need your own bootable operating system that does not use the host system at all, except for it's hardware. Suitably, you can use the xB Machine, which can be booted off of on any system with intel architecture or similar, and is open source. Even then you are still subject to hardware based keyloggers.

 

Here is a still in development blueprint by the way. We decided to go with Java as the programming language, also the Feige-fiat-Shamir system has already been programmed I will throw up the source code soon. We are estimating that an Alpha Release could be out in three or so months and will probably do a public test.

http://www.sendspace.com/file/v59ptl

 

So this project is still being developed. Some of the people who looked at the blue print didn't understand some of it so I wrote up a more informative explanation in regards to the cryptographic techniques we are using. This would be an interesting read to anyone who wants to learn more about encryption and related technologies, although it is focused on this specific project I tried to give as much information as possible.

 

On the NSA and the AES.

Here are some things I know about the NSA, along with other comments that have been taken, almost verbatim, from previous threads of mine; this is meant as a counter-argument for your decision to not use the AES, and the reasoning behind it.

Consider that we have two groups of cryptographic communities, if you will: The NSA and the academic community. The NSA has access to their own internal cryptanalysis, as well as the academic community's published cryptanalysis. The academic community has access to their own published analysis, but not the NSA's internal analysis. That's advantage number one.

The NSA, being a cohesive organization, can easily target their resources; if they want everyone working on a particular problem, they can make that happen. Needless to say, this can be quite impractical for the academic community, with cryptographers spread all over, at various academic institutions, organizations, companies, et cetera. That's advantage number two.

While they certainly have an edge, I believe that we've closed the gap significantly over the last few decades, so I'm not incredibly worried about their cryptanalytical abilities. I'm more worried about their other information-harvesting capabilities. Cryptography is arguably the strongest layer of the proverbial security onion, so to speak, and its track record certainly reinforces that. That, and there are almost always easier ways to get at data. Given that, and the fact that the NSA is in the business of getting data, where my concerns lie should be no mystery. For the record, I don't believe that the NSA can mount a practical attack on the AES, nor do I think there is any conspiracy surrounding it. Despite my lack of confidence in the NSA to do many things right, they've contributed positively to the field of cryptography before. That, and, as you've mentioned, they've deemed it suitable for SECRET and TOP SECRET information (i.e., Suite B, CNSSP-15).

There's no doubt that Serpent was built like a tank, and was the frontrunner, when "security margin" was taken into account. However, there's an important thing to take into account, when looking at distinctly designed primitives under this model. Consider that Rijndael, Twofish, and Serpent all have different round functions; in other words, each block cipher's design team decided what they felt should happen during each round, respectively. Needless to say, "what they felt," being subjective, differed between the teams. While "security margin" is a useful, generic model for juxtaposing cryptographic primitives, it has its limitations. Let's look at an example that demonstrates this by putting "security margin" into perspective.

Assume we have two block ciphers, A and B. A is a Feistel, while B is an SPN. There's a truncated differential attack on A that covers 7 of its 10 rounds and a higher-order differential-linear attack on B that covers 20 of its 40 rounds. On the surface, we can say B is stronger than A, because it still has 20 rounds left untouched, whereas A is only 3 rounds shy of a full break. On the other hand, this starts to lose value, when you consider that we're talking about two block ciphers based on different structural designs, using two different round functions, and analyzed using two different attack models. It could very well be the case that extending the attack on B's remaining 20 rounds is easier than extending the attack on A's remaining 3 rounds. It all depends on what's going on inside the round function.

To show how much it matters as to what's going on inside the round function, consider that Rijndael achieves full diffusion after 2 rounds, followed by Serpent at 3 rounds, and Twofish at 4 rounds; this is an example of how Rijndael is more conservative in regards to diffusion. While there are valuable design philosophies tucked within Twofish and Serpent, there's a good reason to use the AES; as I mentioned in a previous thread, it's receiving more cryptanalytical attention than any other block cipher - Twofish and Serpent included. This reasoning should be compelling enough for anyone, and you'll find that it's supported throughout much of the cryptographic community. Unless environmental constraints prevent it, for whatever reason, I strongly advise developers and consumers, both, to use the AES, when at all possible -- whenever and wherever.

From a security perspective, there's no need to implement Serpent or Twofish, "just in case." It boils down to the fact that the AES receives more cryptanalytical attention than any other block cipher, which is how a cryptographic primitive "earns its bones," so to speak. If you want even more reassurance, Ross Anderson (co-designer of Serpent) and David Wagner (co-designer of Twofish) recommend using the AES over Serpent and Twofish. Read Ross's thoughts on this on page 94, in Chapter 5 of his book, Security Engineering: A Guide To Building Dependable Distributed Systems (To all the security engineers in here: Do yourselves a big favor and download the first edition of this book). Read David's thoughts on this in a sci.crypt post of his. I highly recommend reading anything that David Wagner writes; it's always thought-provoking.

 

Re: On the NSA and the AES.

Dual_EC_DRBG has me sketched out from anything NSA supports really. I do have two main questions for you though.

1. Do you believe that our project will be significantly more secure if we use AES instead of serpent? We use symmetric encryption to encrypt the client side program, to encrypt posts on the forum with a shared key (passive adversary will be defended from, so many people sharing a key will make it limited protection obviously), and more importantly to encrypt messages after an initial asymmetric key exchange (this key can be used to symmetrically exchange more keys symmetrically)



2. Do you think that ECDH used to encrypt McEliece cryptosystem cipher text is a good idea? ECDH is very nice by itself, but I like the fact that the McEliece cryptosystem is quantum resistant. Key exchanges are done sporadically so the huge cipher text of McEliece cryptosystem isn't too bad of a disadvantage, only one key needs to be exchanged asymmetrically then keys can be exchanged symmetrically using that key.

thanks for the advice. We will seriously consider using AES instead of serpent if you think AES will provide us with more security. If you think they will both provide roughly equal security however we will go with serpent as I don't trust NSA to promote stuff they can't get around. I wouldn't be surprised if serpent is suite A.

 

It all sounds very interesting. Good luck with the project.

I think Justin always makes this point about the AES well. It's kind of the same principle of why Triple-DES is still considered pretty secure. Look at what all has been thrown at it and it's held up, for the most part and with certain limitations, to be a solid algorithm. If one were to have used certain other algorithms from that generation, there would be no way to really know how secure it is because it wasn't the focus of attention and study.