Damn. 2000 bits of binary... Every single bit added to a binary key does exponential increases to the resulting protection.
This is a common mistake that non-cryptographers make. The above is true only for symmetric algorihtms. For asymmetric ones, like RSA, this is false. A 2001-bit RSA key is not twice harder to crack than a 2000-bit key. This is why for example the NIST recommendations list different key lengths depending on the type of crypto (sym vs. asym). For introductory-level material I suggest Cryptographic key length.
As it was pointed out by another poster, no 1024-bit RSA is not
sufficiently strong. Recent papers have demonstrated that factoring a 1024-bit
key is now within practical reach. See for example this PhD dissertation
from a student whose advisor was Shamir (the S in RSA FYI),
which estimates that cracking a 1024-bit key would cost a
few million US dollars.
Sure, at this point only a small number of organizations have a few million
dollars to spare on cracking RSA, but this is beyond the point. The flaw is
sufficiently serious that security standards are now recommending 2048-bit RSA
keys minimum.
What I am talking about are relatively recent developments, it is not
very well-known that 2048-bit is the minimum recommended length. This
is why 1024-bit keys are still wildly used everywhere. My bank
(www.wellsfargo.com) uses a 1024-bit key...
These stringent development procedures are precisely what make the Linux kernel that robust. It's not the code, it's the coding procedures. Your patches should be documented, easy to review, QA, and apply. I wouldn't accept patches from a sloppy developer who wouldn't be bothered following the appropriate procedures.
Getting Camstasia Studio to record your BackTrack & Vista sessions: free (you got the free trial version)
Downloading a James Bond music to put it in your flash demo: free (you have got crazy peer-to-peer skillz)
Showing the world the amazing things you can do with physical access to a box and that it takes you 60 long secs to painfully rename cmd.exe to utilman.exe:...priceless
Oops the rest of my message was assuming you can't physically meet her. So by order of preference: email+encrypt it, or give her the password over the phone, or mail it in an envelope a few days apart from sending the laptop.
Basically the hardened OS config will defend against what I think are the most likely threats: inexistent or bad IT security policies at her site/company.
The most secure solution is the following one: put the data on a laptop using full-disk encryption and a hardened secure OS install. Send the laptop to the contractor via UPS/Fedex. Give him the password in-person. Explicitely forbid the contractor to move the data out of the laptop. Of course, let her install the tools she need to process the data on the laptop itself. When done, she mails you the laptop back.
A similar story is described in the book The Art of Intrusion by Kevin
Mitnick. Mitnick interviewed someone who claimed to be part of a group of 4
friends who bought a slot machine, reverse engineered the firmware, the game
application, the pseudo random number generator, etc. They found a flaw in the
PRNG, were able to determine its internal state by watching the cards dealt so
far, and were able to develop an algorithm able to predict the outcome of the
game.
Then they built a small portable device to run their algorithm on-site, in
casinos using the exact same slot machine model. It is rumored they won a lot
of money this way and took enough precautions to never being caught (I guess
they spread their attack over a large number of casinos/cities and multiple
years).
Of course the story is anonymized so can't be verified. And it is in
Mitnick's interest to have exciting stories in his book. But IMHO the
attack looks totally plausible. Game developers usually have no security background, especially regarding how to design a secure PRNG.
Actually Ubuntu released 3 advisories for this vuln, because the vulnerable code is included in 3 packages. Their permanent links are: OpenSSL, OpenSSH and OpenVPN.
I have no source, this is what I was taught in school 10 years ago. Your numbers are probably more recent and more right than mine. According to http://www.census.gov/ipc/www/idb/worldpopinfo.html the world population was 6,600,372,992 in 2007 and 6,677,563,921 in 2008, which results in +2.44 persons per second. Which actually means the world population has regained its level from before Cyclone Nargis in only 11.4 hours.
But if you're a developer on a project where all the
developers are in a common location sharing common infrastructure, often
literally within speaking distance of each other, then a decentralized VCS like
Git is stupid. It's harder to maintain and, in that situation, yields none of
the offsetting benefits.
FUD. I think you may have had a bad experience with Git, which is
known to be somewhat difficult to learn, but in general the easy
things you do with a CVCS can just as easily be done with a DVCS
(commits, diffs, tags...). And the things that are complex/impossible
to do with a CVCS become easy/possible with a DVCS (low-cost
branching, working out of the office with no network/VPN, central
repo not a single point of failure, etc). You
can benefit from these advantages even in small dev teams. Case in
point: I use a DVCS (Mercurial) for some private projects
even when the single repo is on my laptop and when I am the only developer
mostly because it couldn't be simpler:
No it shouldn't. In the world, there are on average 5 births and 3 deaths per second, so the population is increasing by +2/sec. Worst case, Cyclone Nargis is estimated to have killed 100,000 people. So after the disaster, the world population regained its previous level in merely 14 hours (100000/2/3600). Don't get me wrong it is a terrible disaster, but when speaking about the worldwide population it is merely a blip on the radar.
How do you force your cvs/svn users to commit ? You can't, you expect them
to be responsible and do it. This isn't much different from a DVCS.
What if a user wants his work to be backed up but doesn't want
to commit because his changes are not ready to be published ?
A centralized VCS forces them to commit with the side-effect of
making their unfinished work immediately visible in the central repo,
while a DVCS lets them commit to a private repo that you can back
up independently.
Your backup requirements can be solved 2 different ways:
1. With any VCS (centralized or distributed), put the users'
working directories on
private NFS/Samba shares. This way everybody's work, committed
or not, is on the file server which can be backed up.
2. Use a DVCS. The users' private repos and working directories
can remain on fast local storage on their workstations. A file server
contains the main repo as well as private spaces that can be used by
the users to periodically push to private repos, so they can be backed
up without interfering with the main repo.
Besides, in this debate, you are completely ignoring the other
major advantages of DVCS over centralized ones: scalability, no
single point of failure, possibility to work offline and have
full access to all of the features of your VCS, usually faster than
centralized VCS, low-cost branching/merging, etc.
What worries me is that it encourages behaviour which leaves valuable changes sitting on a disk which may not be backed up.
Huh ? If you don't push to the main repo, nobody sees your commits. Don't you
think this is sufficient to remember DVCS users they need to push regularly ?
You do realize that a distributed VCS can perfectly be used like a centralized
VCS, don't you ? Declare any repository as the "central" one and decide that
everybody should push/pull to/from it. That's their power: discributed VCS
don't force you into a specific workflow, you choose how you want to use
them.
You don't see far enough. There is more than licenses and support fees. Schwartz explained in other posts that giving away software increases the opportunity for Sun to sell more of other stuff: give your customer an open source database and they will buy more SAN storage, servers, networking equipment, etc !
"Company forced to give up revenue stream due to open-source fanatics [...]"
Actually Sun CEO Jonathan Schwartz has explained numerous times in his blog that opensourcing your products increases your revenue stream in the long term. I invite you to read in particular this 2-day old post where he answers the FAQ "Why don't you just stop giving your software away?" and gives precisely the example of MySQL.
You can't grow a ZFS pool except by adding similarly-redundant vdevs.
This is not exactly true. No matter what your pool config is, you can
always grow it by adding any sort of top-level vdev to it. For
example if you have a N-drive raidz, you can add to it a 1-drive "mirror"
(no redundancy, not recommended), or a 2-drive mirror, or a 3-drive
raidz, or a 4-drive raidz2, etc.
I think what you tried to say is that it is not possible to convert
a N-drive raidz/raidz2 array into a (N+1)-drive array. The reason
Sun hasn't implemented this feature yet is because (1) ZFS provides more
features than your average RAID layer, so they face implementation problems
no one else has ever had to solve when dynamically reconfiguring the layout
of a RAID array, and (2) ZFS targets mostly machines with lots of drives
where storage expansion is often done by adding a bunch of disks at
a time (which is possible, see above) rather than occasionally adding
single drives.
Slashdot Mirror
This is a common mistake that non-cryptographers make. The above is true only for symmetric algorihtms. For asymmetric ones, like RSA, this is false. A 2001-bit RSA key is not twice harder to crack than a 2000-bit key. This is why for example the NIST recommendations list different key lengths depending on the type of crypto (sym vs. asym). For introductory-level material I suggest Cryptographic key length.
As it was pointed out by another poster, no 1024-bit RSA is not sufficiently strong. Recent papers have demonstrated that factoring a 1024-bit key is now within practical reach. See for example this PhD dissertation from a student whose advisor was Shamir (the S in RSA FYI), which estimates that cracking a 1024-bit key would cost a few million US dollars.
Sure, at this point only a small number of organizations have a few million dollars to spare on cracking RSA, but this is beyond the point. The flaw is sufficiently serious that security standards are now recommending 2048-bit RSA keys minimum.
What I am talking about are relatively recent developments, it is not very well-known that 2048-bit is the minimum recommended length. This is why 1024-bit keys are still wildly used everywhere. My bank (www.wellsfargo.com) uses a 1024-bit key...
These stringent development procedures are precisely what make the Linux kernel that robust. It's not the code, it's the coding procedures. Your patches should be documented, easy to review, QA, and apply. I wouldn't accept patches from a sloppy developer who wouldn't be bothered following the appropriate procedures.
42 ?
Yep... Who was, like me, counting the days (since Google announced App Engine in April) until Microsoft would announce something similar ?
I am surprised it took them 2+ months this time.
Keep buying... keep buying....
Why BitTorrent causes network bandwidth to be used. And network packets to be sent & received. Really sometimes I wonder.
The system uses four NVIDIA GeForce 9800 GX2 graphics cards, costs less than 4,000 EUR to build
What's more crazy: calling something this inexpensive a supercomputer, or 4 video cards costing a freaking 4,000 EUR.
So what you're saying is, your parent's modded your Wii?
I'd like Jessica Alba to play on my modded Wii.
Give him the password in-person
Oops the rest of my message was assuming you can't physically meet her. So by order of preference: email+encrypt it, or give her the password over the phone, or mail it in an envelope a few days apart from sending the laptop.
Basically the hardened OS config will defend against what I think are the most likely threats: inexistent or bad IT security policies at her site/company.
The most secure solution is the following one: put the data on a laptop using full-disk encryption and a hardened secure OS install. Send the laptop to the contractor via UPS/Fedex. Give him the password in-person. Explicitely forbid the contractor to move the data out of the laptop. Of course, let her install the tools she need to process the data on the laptop itself. When done, she mails you the laptop back.
A similar story is described in the book The Art of Intrusion by Kevin Mitnick. Mitnick interviewed someone who claimed to be part of a group of 4 friends who bought a slot machine, reverse engineered the firmware, the game application, the pseudo random number generator, etc. They found a flaw in the PRNG, were able to determine its internal state by watching the cards dealt so far, and were able to develop an algorithm able to predict the outcome of the game.
Then they built a small portable device to run their algorithm on-site, in casinos using the exact same slot machine model. It is rumored they won a lot of money this way and took enough precautions to never being caught (I guess they spread their attack over a large number of casinos/cities and multiple years).
Of course the story is anonymized so can't be verified. And it is in Mitnick's interest to have exciting stories in his book. But IMHO the attack looks totally plausible. Game developers usually have no security background, especially regarding how to design a secure PRNG.
Actually Ubuntu released 3 advisories for this vuln, because the vulnerable code is included in 3 packages. Their permanent links are: OpenSSL, OpenSSH and OpenVPN.
I have no source, this is what I was taught in school 10 years ago. Your numbers are probably more recent and more right than mine. According to http://www.census.gov/ipc/www/idb/worldpopinfo.html the world population was 6,600,372,992 in 2007 and 6,677,563,921 in 2008, which results in +2.44 persons per second. Which actually means the world population has regained its level from before Cyclone Nargis in only 11.4 hours.
FUD. I think you may have had a bad experience with Git, which is known to be somewhat difficult to learn, but in general the easy things you do with a CVCS can just as easily be done with a DVCS (commits, diffs, tags...). And the things that are complex/impossible to do with a CVCS become easy/possible with a DVCS (low-cost branching, working out of the office with no network/VPN, central repo not a single point of failure, etc). You can benefit from these advantages even in small dev teams. Case in point: I use a DVCS (Mercurial) for some private projects even when the single repo is on my laptop and when I am the only developer mostly because it couldn't be simpler:
No it shouldn't. In the world, there are on average 5 births and 3 deaths per second, so the population is increasing by +2/sec. Worst case, Cyclone Nargis is estimated to have killed 100,000 people. So after the disaster, the world population regained its previous level in merely 14 hours (100000/2/3600). Don't get me wrong it is a terrible disaster, but when speaking about the worldwide population it is merely a blip on the radar.
How do you force your cvs/svn users to commit ? You can't, you expect them to be responsible and do it. This isn't much different from a DVCS.
What if a user wants his work to be backed up but doesn't want to commit because his changes are not ready to be published ? A centralized VCS forces them to commit with the side-effect of making their unfinished work immediately visible in the central repo, while a DVCS lets them commit to a private repo that you can back up independently.
Your backup requirements can be solved 2 different ways:
Besides, in this debate, you are completely ignoring the other major advantages of DVCS over centralized ones: scalability, no single point of failure, possibility to work offline and have full access to all of the features of your VCS, usually faster than centralized VCS, low-cost branching/merging, etc.
Huh ? If you don't push to the main repo, nobody sees your commits. Don't you think this is sufficient to remember DVCS users they need to push regularly ?
You do realize that a distributed VCS can perfectly be used like a centralized VCS, don't you ? Declare any repository as the "central" one and decide that everybody should push/pull to/from it. That's their power: discributed VCS don't force you into a specific workflow, you choose how you want to use them.
You don't see far enough. There is more than licenses and support fees. Schwartz explained in other posts that giving away software increases the opportunity for Sun to sell more of other stuff: give your customer an open source database and they will buy more SAN storage, servers, networking equipment, etc !
Actually Sun CEO Jonathan Schwartz has explained numerous times in his blog that opensourcing your products increases your revenue stream in the long term. I invite you to read in particular this 2-day old post where he answers the FAQ "Why don't you just stop giving your software away?" and gives precisely the example of MySQL.
This is not exactly true. No matter what your pool config is, you can always grow it by adding any sort of top-level vdev to it. For example if you have a N-drive raidz, you can add to it a 1-drive "mirror" (no redundancy, not recommended), or a 2-drive mirror, or a 3-drive raidz, or a 4-drive raidz2, etc.
I think what you tried to say is that it is not possible to convert a N-drive raidz/raidz2 array into a (N+1)-drive array. The reason Sun hasn't implemented this feature yet is because (1) ZFS provides more features than your average RAID layer, so they face implementation problems no one else has ever had to solve when dynamically reconfiguring the layout of a RAID array, and (2) ZFS targets mostly machines with lots of drives where storage expansion is often done by adding a bunch of disks at a time (which is possible, see above) rather than occasionally adding single drives.