Okay, what form and key size of encryption is in use? What implementation is it?
Does it do PFS?
is it salted?
Where/for how long/how are messages stored?
Who has access to the encrypted form of the messages?
What block mode is being used here?
How are you handling the iv initialisation? Per message? per person? per conversation? What are you using to determine the IV value?
The encryption use is PKCS #5 (5.3 PBE with MD5 and DES). The algorithms are outdated but in the subsequent release we can update it to SHA-2 and AES-256.
We cannot do PFS because we have the feature that a person can login to different devices and can still see the same messages and continue the chat ( given that he knows the chat password)
This alone should have blocked your launch. Crypto done right is innately pluggable, by virtue of being composable primitives.
Between this and your "but we totes destroy ciphertext after T seconds" (which is just flat out untennable, and unprovable) I'm pretty spectacularly weary.
I'm also pretty curious to know how you're deriving keys from the users passwords. How is the exchange of key material handled?
Note that that is for containers (i.e. guests). For the host side, only ubuntu is officially supported; many people are using arch quite well, and a few have got it running under fedora and suse that I know of (I'm going to assume gentoo have it as well, knowing them). both require custom kernels however.
With the correct versioning, you can sort the guarantees out - there is some discussion on the docker forum at the moment on signing / hashing or otherwise verifying the images.
For slotted services, I suggest looking at nix and nixos, a package manager (and a distribution) which pinches some ideas from containers.
As for the main point of your comment:
Yes, native package management is lighter-weight than containers (which is lighter than vms, which is lighter than seperate physical machines). Perhaps unsurprisingly, that weight brings additional features. The main one that containers (upwards) adds is segregation. apt (lovely as it is) can only ensure packages don't conflict on the files that they install - you are on your own for ensuring there are no runtime conflicts. Yes, with proper user creation + management you can restrict their ability to tread on each other's toes (hope there are no setuid programs in there), but that is all more effort than the 'their filesystems are seperate' that the heavier options give you.
There is also the question of tidying up / migrating. Let's say I install number of packages for some thing I'm deploying on a box. After a while I realise the load is too high and decide to migrate one/some of the apps to another machine. apt, etc can tell me what files a package has installed. It can't tell me what files a package has created while running. I'll have to go around and figure out the data (config, user config, log, etc) file locations and probably miss a couple and end up just duplicating the original machine. Or I copy the container file and the half a dozen images that make it up.
It's true that docker (and to a lesser extent vagrant et al) are perhaps suffering from over-use as the are 'the new hotness', but that's because we have a new tool and haven't yet fully figured out how to use it - it's somewhat inevitable behaviour. And yes, for some applications package management is fine and containers is unneeded overhead. But for others it isn't.
I will add one more difference between Docker vs. traditional package managers: Docker is a tool developers enjoy using. I have yet to meet a developer who enjoys building his application as an rpm or deb. The shorter the development/deployment cycle, the worse it gets.
Actually the provisions of the OSA cover you even if you haven't signed it. Signing it is generally just a reminder thing, hence the fact that if you have to sign it once, you will probably end up signing it several times (when you join, when you leave, when you change roles, etc).
The OSA primarily covers how you handle secret information that you legitimately have access to. He was talking about stuff outside the scope of the OSA - i.e. when you acquire material that you shouldn't have to start with.
Good point, but still, one still needs to just laugh at this guy. The idea tha any idea (data, knowledge) can be mis-used for terrorism is non-falsifiable hypothesis. It makes a mockery of the adverserial justice system.
Many pieces of data can be used for such purposes. Its precisely the innocence of the victims and the innocuous and everyday nature of the means, that is the purposes of this new bloody sport.
THE TERRORISTS WENT TO FRIGGIN FLIGHT SCHOOL.
We taught them how to fly a guided missile into a FRIGGIN SKYSCRAPER.
But it's not outside the scope of the OSA, necessarily - Section 5 covers the recipients of secret material leaked by a civil servant.
The current leaks are only outside of the scope of OSA because Snowden isn't a civil servant of the UK. It appears Blair wants to prevent the publication of all information considered highly embarrassing - er, I mean, 'damaging to national security' - regardless of where it came.
A nice approach, I will look at implementing it on my setup at home; Probably worth noting that if you are taking these steps then running it all out of an encrypted filesystem is probably a sensible addition. Although if you are looking at doing this you probably have an encrypted filesystem already.
Exactly. So why bother at all right? Root password? "root" will do. Encrypted partitions on the server? Useless. SSH keys? Silly overengineered junk.
Following the same logic, why bother setting strong passwords on Gmail? Or even bother at all with 2FA, I mean, after all, somebody can just read your unencrypted email in transit anyway, right?
This comment is not helpful at all. The original article did not mention with a single word the NSA or anything like it[1], but he is worried about things being stolen or hacked.
> So what does this get me? If somebody steals my laptop or phone, they can't access my email from my IMAP clients local store because it's all encrypted and my private PGP key is password protected. If somebody guesses my IMAP password, or uses an exploit to gain access to my account, they can't read my email because what they retrieve is encrypted.
And for both scenarios, the proposed tools are very much helpful.
[1]: Partially because the article says "Published @Thu, 13th Jan 2011"
>Exactly. So why bother at all right? Root password? "root" will do. Encrypted partitions on the server? Useless. SSH keys? Silly overengineered junk.
>Following the same logic, why bother setting strong passwords on Gmail? Or even bother at all with 2FA, I mean, after all, somebody can just read your unencrypted email in transit anyway, right?
That's not even remotely what I'm claiming. Stop being a dick. Yes, you should always have good passwords on your accounts and use 2FA. But if you want to send something secret across the Internet you might want to choose another method than (unencrypted) email.
>This comment is not helpful at all. The original article did not mention with a single word the NSA or anything like it, but he is worried about things being stolen or hacked.
If someone really wants to read your mail they'll compromise the host your mail is on and read it before you get a chance to encrypt it. In that case this "solution" does nothing. It keeps a casual person out but does nothing to stop a more advanced attacker.
She.
I remain surprised by how often this mistake is made, given her name is on every page and the whole thing a few years back where someone accused her of being a fiction made up by IBM.
Also, I wonder what the other contributors she had given post privileges to think of this (I thought she had stepped down/away from some of the cases groklaw was covering).
