"Some of the trusted" is not enough. If they want to look like Google they need Googles cert (their private key). Though very possible I do not, yet, think they have it.
NSA cannot do this in wide scale as the new CERT is far too easy to detect. They might do it for one particular "suspect", e.g. I would not notice it. But there are even Firefox extensions to detect these so if deployed wide scale it would have been noticed.
I do not believe all VPN and all SSL are broken. It would be pretty much impossible to break all VPN, after all they use vide variety of encryption systems.
What I believe is that many commercial, perhaps most if not all US made, VPN & SSL implementations are flawed.
Well, Lavabit closed down because request to them was "too much". Google did not and will not. So what is "too much"? I have an opinion on that and therefore I do not believe Google. On neither account ("has access" and "is working").
If Google were working on it, they would make a Javascript (i.e. client) encryption to their cloud (and email, etc). It would be quite easy to do.
ZFS is tested and has beed used in huge amount of different environments with very posive feedback for well over a decade. I do not know any catastrophic failures (though there must be). BTRFS requires latest version of Linux kernel and itself to work. I have no clue about testing (removing disks on the fly, etc.) and definitely it is not widely deployed, not yet proven to work (few anecdotes do not count). BTRFS seems to be only slightly more robust than it was five years ago - during this time I have lost two hard disks from my ZFS, quadrupled disk space easily, used NFS4 (and CIFS-ro), etc. All with zero data loss.
Oracle, at least previously, was the biggest contributor to BTRFS. I would't trust them to invest on two filesystems in the long run. I would't trust them to invest on OpenZFS either, but is more mature in the foreseeable future.
AFAIK the design of both is very solid (btrfs is better in this sense) and I hope btrfs is someday better than zfs IN REAL LIFE. But that will take at least five years (for me to believe it). If that would happen, I might migrate. But because ZFS does everything I need (raidz/2/3, nfs4, cifs, acl, lz4 compression, dedup, ease of use,...), I might not, after all what would *I* get (to offset the mgration pita)?
Actually, no. Technically speaking, there is no such thing as random data, only a random process.
Actually, there is random data. That is, data generated by a random process.
Unsurprisingly, there are quite a few different tests which can determine, or perhaps "preditct the chance" if some data is produced by a random process i.e. is random, or not. The easiest for a layman is to try to compress it. Random data of sufficient size won't compress with unbelievably huge probability.
They use AES themselves. Some of the smartest cryptoanalysts live in Israel, China, Russia, etc.
It would be extremely stupid to do encryption they know is breakable.
It is, has almost always been, and will be in foreseeable future so much easier to use covert channels. A VPN software to use almost, but not quite, random data in encryption keys. This way NSA needs huge workload (few hours of their massive processing power) to decrypt, without knowledge of the non-randomness it would be infeasible. Say AES-128 where ~60 bits of the key can be deduced from the rest (but do look like random, e.g. are generated by MD5).
I use ZFS (OpenIllumos) server with raidz2. All user data is in the server. With snapshots that is beautiful system for my needs (I also do offsite backups, but not that often). AND WOULD HAVE SOLVED THE PROBLEM.
I already have had a situation where two disks were failing, but that was entirely my fault. When first disk failed I thought "it can handle the second failure easily, no need to rush". It did without any data loss[1], but for obvious reasons I should have replaced the disk immediately. But then this gave me time to move from 500G disks to 2T disks (i.e. replace all disks) quadrupling storage. The transition was unbelievably simple: replace one disk (first the failing disks), run "zfs resilver", rinse and repeat.
I would never use HW RAID, for my needs it would be very bad idea. Now if motherboard dies, I just buy new one - any brand, no need to have identical raid controller.
[1] I know this for sure as everything is checksummed in ZFS
There is UI's like TortoiseGit for Git. But I'd recommend to evaluate other DVCS's too like Mercurial (& TortoiseHg). They may fit your needs better. Don't waste your time evaluating too much, the all are perfectly fine. But do pick a *distributed* VCS instead of simple VCS. They are Just Better(tm).
Putting a PDF into git in a way does not make sense, but then it does not hurt either. Sooner or later you'll notice it saves your day and therefore did make a lot of sense. It makes much more sense than putting it into e.g. Sharepoint, although your intuition may suggest otherwise. Really.
Although you are more qualified than me (I gave up following security actively over ten years ago), I beg to differ. No offence.
Seems like you have invented a very complicated version of jail. Typical Linux attitude, both "NIH" and "it is a superset (i.e. can do more), therefore it is better". In security both have been proven to be bad ideas quite a few times.
[quote] Code has bugs. That's life [/quote]
I do not want to talk that much about whether some code has bugs or not, rather about attitude. That sentence alone has bad attitude, but Linux's (Linus's) most cherished attitude is "change is everything", i.e. any reason whatsoever is good enough reason to make a backward incompatible change. In theory this has no effect in security, but in practice the effect is big: you really cannot test all or even most changes to all device drivers. This is why I do not believe you have improved. This is why I think companies like Vupen prosper - they get it too easy.
As said, I do not count CVE's (there are far too many to count), I count necessary reboots. Yes, even worse as a statistical tool, but as said, I stopped following security. Reboots occur at a slowly increasing rate, about ten per year. This year has had more. My computer now is more in "please reboot" state than in "ok" state. The security updates are pretty much the only reason to reboot - for me.
Linux (the kernel) is accumulating new security holes at least at the same speed as they are fixed. Proof: Ubuntu kernel security hole fix rate has been constant for years.
(actually I have not counted the actual number of holes, only the actual number of kernel security patches - these two should correlate though).
Slashdot Mirror
"Some of the trusted" is not enough. If they want to look like Google they need Googles cert (their private key). Though very possible I do not, yet, think they have it.
If increased CO2 decrease H2O (i.e. clouds) then the increase will not lead to global warming.
I am not claiming this is the case.
NSA cannot do this in wide scale as the new CERT is far too easy to detect. They might do it for one particular "suspect", e.g. I would not notice it. But there are even Firefox extensions to detect these so if deployed wide scale it would have been noticed.
I do not believe all VPN and all SSL are broken. It would be pretty much impossible to break all VPN, after all they use vide variety of encryption systems.
What I believe is that many commercial, perhaps most if not all US made, VPN & SSL implementations are flawed.
Well, Lavabit closed down because request to them was "too much". Google did not and will not.
So what is "too much"? I have an opinion on that and therefore I do not believe Google. On neither account ("has access" and "is working").
If Google were working on it, they would make a Javascript (i.e. client) encryption to their cloud (and email, etc). It would be quite easy to do.
Then who does all the un-fun stuff like testing and documenting. Exactly.
I have solved this another way around - I go to work early. And, of course, leave early. Obvioulsy leaving early might be difficult in some places.
ZFS is tested and has beed used in huge amount of different environments with very posive feedback for well over a decade. I do not know any catastrophic failures (though there must be).
BTRFS requires latest version of Linux kernel and itself to work. I have no clue about testing (removing disks on the fly, etc.) and definitely it is not widely deployed, not yet proven to work (few anecdotes do not count).
BTRFS seems to be only slightly more robust than it was five years ago - during this time I have lost two hard disks from my ZFS, quadrupled disk space easily, used NFS4 (and CIFS-ro), etc. All with zero data loss.
Oracle, at least previously, was the biggest contributor to BTRFS. I would't trust them to invest on two filesystems in the long run. I would't trust them to invest on OpenZFS either, but is more mature in the foreseeable future.
AFAIK the design of both is very solid (btrfs is better in this sense) and I hope btrfs is someday better than zfs IN REAL LIFE. But that will take at least five years (for me to believe it). If that would happen, I might migrate. But because ZFS does everything I need (raidz/2/3, nfs4, cifs, acl, lz4 compression, dedup, ease of use, ...), I might not, after all what would *I* get (to offset the mgration pita)?
... incorrect moderation, sorry
In that case we get to the philosophical question: is there anything "truly" random. No process describable by mathematics certainly is not.
Are you really claiming, that exactly same data can be mathematically speaking both random and non-random?
(Sorry for screwing the quote ... not the first time ... apparently my brain is a random process)
Actually, no. Technically speaking, there is no such thing as random data, only a random process.
Actually, there is random data. That is, data generated by a random process.
Unsurprisingly, there are quite a few different tests which can determine, or perhaps "preditct the chance" if some data is produced by a random process i.e. is random, or not. The easiest for a layman is to try to compress it. Random data of sufficient size won't compress with unbelievably huge probability.
They use AES themselves. Some of the smartest cryptoanalysts live in Israel, China, Russia, etc.
It would be extremely stupid to do encryption they know is breakable.
It is, has almost always been, and will be in foreseeable future so much easier to use covert channels. A VPN software to use almost, but not quite, random data in encryption keys. This way NSA needs huge workload (few hours of their massive processing power) to decrypt, without knowledge of the non-randomness it would be infeasible. Say AES-128 where ~60 bits of the key can be deduced from the rest (but do look like random, e.g. are generated by MD5).
These programmers can develop more software than 5 - 10 newly hired regular programmers because they know what needs to be done and how to do it.
If a programmer who knows the system cannot do better than ten newly hired, s/he is an idiot.
I use ZFS (OpenIllumos) server with raidz2. All user data is in the server. With snapshots that is beautiful system for my needs (I also do offsite backups, but not that often). AND WOULD HAVE SOLVED THE PROBLEM.
I already have had a situation where two disks were failing, but that was entirely my fault. When first disk failed I thought "it can handle the second failure easily, no need to rush". It did without any data loss[1], but for obvious reasons I should have replaced the disk immediately. But then this gave me time to move from 500G disks to 2T disks (i.e. replace all disks) quadrupling storage. The transition was unbelievably simple: replace one disk (first the failing disks), run "zfs resilver", rinse and repeat.
I would never use HW RAID, for my needs it would be very bad idea. Now if motherboard dies, I just buy new one - any brand, no need to have identical raid controller.
[1] I know this for sure as everything is checksummed in ZFS
There is UI's like TortoiseGit for Git. But I'd recommend to evaluate other DVCS's too like Mercurial (& TortoiseHg). They may fit your needs better. Don't waste your time evaluating too much, the all are perfectly fine. But do pick a *distributed* VCS instead of simple VCS. They are Just Better(tm).
Putting a PDF into git in a way does not make sense, but then it does not hurt either. Sooner or later you'll notice it saves your day and therefore did make a lot of sense. It makes much more sense than putting it into e.g. Sharepoint, although your intuition may suggest otherwise. Really.
I heavily recommend distributed version control system (git, mercurial, darcs, ...). You'll regret few years later if you don't.
Forget SELinux, use http://grsecurity.net/.
See e.g. https://lwn.net/Articles/538221/
Could SELinux which was developed by the NSA be vulnerable to this sort of attack?
Yes, it could.
Could the NSA have a backdoor into Linux itself?
Yes, they have, as does Chinese, Vupen, etc. Whether to call them "backdoors" or "just a random security holes" is left as a philosophical discussion.
but could Linux itself be vulnerable to the attacks the NSA can launch on other platforms?
Yes.
Yes, those were the happiest days of my life.
Oh yes they do, a lot. They already closed the airspace from a diplomatic flight suspected carrying Snowden.
http://www.zerohedge.com/news/2013-07-02/airplane-bolivian-president-denied-passage-over-french-portuguese-airspace-due-snowd
One thing: I do not and have never claimed that some-other-OS is better (you won't get me in a OS flame war).
I claim Linux could do hugely better.
Although you are more qualified than me (I gave up following security actively over ten years ago), I beg to differ. No offence.
Seems like you have invented a very complicated version of jail. Typical Linux attitude, both "NIH" and "it is a superset (i.e. can do more), therefore it is better". In security both have been proven to be bad ideas quite a few times.
[quote] Code has bugs. That's life [/quote]
I do not want to talk that much about whether some code has bugs or not, rather about attitude. That sentence alone has bad attitude, but Linux's (Linus's) most cherished attitude is "change is everything", i.e. any reason whatsoever is good enough reason to make a backward incompatible change. In theory this has no effect in security, but in practice the effect is big: you really cannot test all or even most changes to all device drivers. This is why I do not believe you have improved. This is why I think companies like Vupen prosper - they get it too easy.
As said, I do not count CVE's (there are far too many to count), I count necessary reboots. Yes, even worse as a statistical tool, but as said, I stopped following security. Reboots occur at a slowly increasing rate, about ten per year. This year has had more. My computer now is more in "please reboot" state than in "ok" state. The security updates are pretty much the only reason to reboot - for me.
Linux (the kernel) is accumulating new security holes at least at the same speed as they are fixed.
Proof: Ubuntu kernel security hole fix rate has been constant for years.
(actually I have not counted the actual number of holes, only the actual number of kernel security patches - these two should correlate though).