Why would a jar with some semen in it be any more likely to contain DNA than all the other remains? In fact, if sperm were somehow miraculously well preserved in and of itself, you could probably recover some from the appropriate organs in the mummified remains (unless they had the testicle jar, but I never heard of that one). Anyway, non-gamete DNA for cloning would hypothetically be more interesting anyway than fertilizing a modern egg with half DNA from 4 millenia go. If you're going to make something like that, why only care about half the old DNA when you could have the whole thing? Even without cloning analysis can be done on the DNA versus today for a bulk of the scientific interest anyway, well, comparison for some of what we know today, archival for studies later when more is understood.
DNA may very well already have been extracted and studied, I have no idea, but sperm/semen is much more boring than a full set of chromosomes in a single package.
Wuss, my passwords are almost always inclusive of non-alpha/non-numerical values and are at least 10 characters long. My strategy is ofter to randomly hit buttons without looking, making generous use of the shift key on the number keys... Example: cS#e(k5L@^ (note: not an actual password, but generated in the same way I generate passwords) Maybe I'm >50% autistic then since I can remember these...
On some occasions I wuss out and if appropriate to the password parsing/entry technology, make a mostly coherent sentence 64 characters long or so, which I believe is still an order of magnitude more secure than a mere 10 characters of even complete garbage, but it is much quicker to type 10 garbage characters than a whole sentence...
The traditional method dm-crypt and cryptoloop used was basically what you say, a hash of the password was used to encrypt the entire disk. Of course, no one ever devised a way to change the password in place, and even if they did, it would require all data on the disk to be re-encrypted. The key used to actually encrypt the data would likely be cryptographically weaker to crack, in theory. If you ever ever write down the password (I don't but some do) and then lose the paper, you can never be sure about the security of your data again short of re-encrypting the whole thing. I think this is probably the single thing people not researching it thoroughly misunderstand, if the technology you see is definitely encryption of a large data set, and you can essentially instantly change the password protecting it, the key used to encrypt the actual data is certainly not the password itself, as it requires a huge amount of effort to change the key on large amounts of encryted data.
In the LUKS scheme the key material used for the very large data set will probably be more cryptographically sound. With a large data set, cryptographically weak keys could more likely be crackable than strong keys, in a large number of the type of attacks historically seen in cryptography. A small data set (data comprised only of the actual key) is generally more resistant to data analysis attacks, so a somewhat weaker password hash based key may be less exposed in that context. If you ever think a malicious user has had opportunity to get your password (the most likely thing in general for an attacker to get), you can change the password and the old key slot be shredded such that the knowledge obtained becomes useless. Sure, the 'master password' being compromised would mean the disk is irrevocably compromised, but that would be the case in the classical strategy anyway, since changing the password isn't feasible. Now if you want to actually re-encrypt data in the way a password change would require in the previous example, you can always reformat with a different key (or re-encrypt in place if implementation allowed), and have the same degree of 'changing the master password' as you put it.
Keep in mind the 'master password' (or rather the actual key) in this context is probably a random 256 bit value. To achieve a comparable level of randomness, a password consisting of typable characters would have to be about 40 characters long consisting of completely random keypresses. If a person is ever in a position to actually get that master key value, you've already lost the data because before they can get to that key they have to: -Get root privilges while the volume is mounted to get dmsetup table output, but if it's mounted they could just grab the data anyway. -Get low-level physical access to your hardware to begin to crack the LUKS header of the partition or the content itself. If they are in a position to do so, they could/would image your entire volume and return your drive. In which case no matter what you do to the copy you got back (re-encrypt, change password, whatever), they can continue whatever crypto-analysis they want on their image of the data as it was when they first took it. You may be able to protect newly written data, but whatever risk of breaking the encryption on existing data is permanently there once imaging is possible. -Get low-level access to your system and somewhere along the chain insert something to dump the key material to them once available. Again, once this is in play, it's already over no matter what you do, if they can dump that table, they can dump the data directly. In this case, let's assume one of those keyboard bugs slashdot had an article a while back was discovered by you in your system. Knowing that your passphrase is potentially compromised, with the key not based directly on the password, but just encrypted by the password, you can re-encrypt the key once the bug is removed and shred the old slot, and their keylog data becomes useless for the purposes of defeating your filesystem encryption. If the master key is essentially whatever you typed, you are significantly more hosed.
On the remote parenting argument, I've no doubt that the kids aren't so dumb they would only comprehend the message if delivered in person. I'm saying that during human psychological development, there could be non-obvious psychological implications of such interaction based on the kids maturity level. I generally don't think a lot of the psycho-babble we hear necessarily has stock, but a gut feeling tells me impersonal interaction with one's children could fall into the realm of stuff the psycho-babble people would rightfully be concerned with. In the context of an individual isolated incident, a parent choosing an impersonal interaction with a child with the child fully aware the parent could just walk across the hall might have the potential to be more harmful to the child's psyche than the parent choosing not to interact at that specific moment at all. In the later case the child is at least not made explicitly aware of the parent's choice of non-interaction (unless a pattern of non-interaction they can't help but to notice emerges), but in the former case it's very obvious the parent thought of interacting with the child and did not feel it worth the effort to actually personally interact with them. It's also a somewhat intangible invasion of their space. If they turn up their stereo and a phantom hand turns it down without explanation, it could evoke displeasure more so than if a parent asks them to turn it down, even if the parent ultimately physically comes into their room to turn it down in person. A person physically coming in and taking action gives them something more tangible to lock on to and even if pissed off by it, on a deeper level it may be a more comfortable confrontation than the phantom approach.
As to the alarm clock knowing my presence being 'weird', I didn't mean in the sense that I don't understand how it could work, but rather it feels to big-brotherish to me. This is a hard argument to logically win, since the unit can be self contained and in no way hooked up to the internet for someone to possibly exploit it remotely (though most likely it would be, in which case this could be a logically defensible point), it just doesn't feel right. Kinda like having sex in front of your pets, they probably wouldn't give a rat's ass about what's going on if they did understand, and maybe the pet doesn't understand, but it still can feel weird to the people being observed to the point of locking pets out of the room for the duration, to avoid that awkwardness.
In general there are steps I think could be improvements, but much like in the 'houses of tomorrow' from the 60s, a lot of futuristic visions ultimately create more complexity than simple approaches that in the aggregate aren't really that inconvenient. Sometimes the geekiness in us will yearn for the 'cool' solution, when ultimately we'd get sick and tired of the complexities introduce that end up more aggrevating than the inconvenience it was invented to address.
Based on the readme, it looks like encfs (which uses fuse and openssl). It might obscure more detail (i.e. with encfs you know how many files and directories there are, and their timestamps). How does it differ from encfs (http://encfs.sourceforge.net/)?
encfs is of course per user, and a somewhat nifty thing there is the pam_encfs module which can optionally used to get the authentication token to unlock its key. The implementation (since it's obviously has to be since it's a fuse thing) is more userspace than ecryptfs, but functionally speaking, what's the difference?
I understand well the benefits compared with dm-crypt strategy based on the circumstances and requirements. With block level strategies, you have to decide the total size of the block device for protected vs. non-protected data. If you don't understand your needs well, it's difficult to apply a finer-grained approach to security, particularly if you are required to codify it into a company standard for people who you definitely won't understand perfectly the needs of. Because of this, the only generally feasible approach is to encrypt everything save for/boot (which I do). This has benefit for protecting against physical threats and people trying to reboot your system using a live cd or other such attacks. However, the key is always available to the kernel and all the data is visible, so a remote or local attack that acheives root privileges means all the data is exposed since a very coarse grained attack was used. On the bright side, it is also appropriate as a codified standard because users can't generally be trusted to correctly perform risk assessments on every save or understand all the temporary places they may save to, and it's the only way to protect swap patitions. I use dm-crypt with LUKS partitions for / and swap on my laptop, with a small/boot for the kernel and luks-enabled initrd.
encfs and similar strategies feasibly allow finer grained policies to go into place without making the tough size decisions as is needed with block strategies. This provides all the protection from theft and such like dm-crypt does. And if the policies are fine grained and the directories are only mounted as needed, a remote attacker achieving root access will only be able to get to file systems currently mounted, which may be a smaller set than the whole. The difficulty here is that when defining a finer-grained policy, you have to know which directories could ever hold sensitive data, If you are to protect swap you can't use a swap partition, but a swapfile in a directory protected by such a scheme, and in the end on a single user system (almost all laptops), effectively no matter what all the encrypted filesystems will be mounted anyway most all the time, so it's really not ultimately much of a functional difference. I make encfs available on a couple of multi-user systems, and generally have pam_encfs there to make their home directories encrypted./tmp is always exposed and swap is still dm-crypt protected on that system.
The hard disk password isn't encryption, it's just a handshake with the controller chip on the hard drive. I don't know what method they used, but generally speaking the data on the platters is unprotected and theoretically swapping the little controller board bit of the drive would bypass it.
Whatever hardware assisted encryption there is to be had in Thinkpads would be that stuff provided for 'trusted' computing. I have no insight on what it could actually do *for* the user as opposed to against it, but also based on my experience I don't think I need to offload the work as it isn't that intensive for a single user system anyway.
-Key recovery mechanism: In my case (and most sane companies), the IT dept with respect to this will let you proceed at your own risk with respect to laptop protected data. With any desktop/laptop install, there is a ever present risk of catastrophic disk failure, so IT policies have to dictate how to cope with sudden loss of all data on a desktop or laptop anyway, if it's because the luser forgot their password or because a drive head started skipping across the platter surface, generally it's all the same. In my case we are provided network storage space, where they manage redundancy, backups, and the associated recovery and maintenance. If the data is so damned important, stick it out there. I also laid out a strategy for this in another post if IT insists on key recovery. LUKS has multiple key slots and by extension can support multiple passwords. Use a key slot for the IT password unknown to the user, and one other for the user password unknown to IT. User can screw it up if they desire, but users can always screw it up if they want to, the goal is to keep a reasonable expectation of recovery, but can never win in the face of user who does not want the data recovered (unless said user is just too stupid to figure it out).
-Corporate standards. The standards of the company just have to be intelligent. In my case, standards when first published required that all company data be protected, and they recommend ed gpg or windows folder encryption to start with, for linux and windows respectively. Auditors have examined my setup, and I showed them the indicators of the method I used and pointed out reference material for their review. At the end the auditors, (who were almost entirely windows people), concurred it went above and beyond the corporate standards and after my audit, future users who had a similar setup had a simple, straightforward audit.
All the fingerprint and user authentication in the world is a poor defense against someone ripping out the drive, which is easy if the laptop is stolen. That's why it is generally a larger issue on laptops than desktops. Desktops tied to your desk at work have whatever physical security the company has invested in protecting it, leaving it open only to the possiblity of remote attackers (well, within reason, the physical security can be bypassed, but assume a perfect company for discussion). The whole threat of a laptop is physical security breaches, otherwise the discussion wouldn't be laptop-centered. As to not putting confidential stuff on laptops, it is a good idea, but that is a policy rooted in trusting the user to always be vigilant about the confidentiality of the data set they are working, trusting their judgment, and expecting them not to take convenient short cuts at 5pm on a Friday so they can get it done on the weekend without staying late or looking bad on Monday. I use full disk encryption so I don't have to even think about it. I'm fairly sure I have nothing on my laptop remotely of interest to anyone, but I never have to think too hard about it.
Encrypted swap and encrypted / the way to go in linux. In Windows there exists third party software that encrypts more widely Basically at the earliest screen before the XP logo is even displayed, someone has to blind type the password for it to boot. Guy at work uses it, I know no more details than that.
I'm going to use LUKS as my example, since the classic cryptoloop and older dm-crypt stuff can't do this.
The solution is for IT to have a person perform the install (already was going to be hard not to do so with the current state of installers). The IT person makes a master copy of the key using the company's chosen password, and uses a different key slot for the employee-known password. When password changes occur, IT people have to go and change the IT-friendly key slot to the new password, but leave the employee's alone. Then IT can recover data from laptops at user requests. This doesn't guarantee data recovery from a system if the user who can change the password on their own key slot doesn't want them to, but if the user wants to play nice to keep IT able to assist them it can work. If the user botches the IT key slot and needs recovery, tough. Data on a laptop in that circumstance should be relatively transient if remotely important, with the real copies on file servers where IT can manage backup and recovery as they see fit.
At work the mandate for Windows laptops is to use the built in encrypted folders mechanism, which is a lot like encfs. If they loose their user password for the account the data is gone, and this is just a fact of life they have to live with. One person went further and put some third-party whole disk encryption on their Windows laptop, a la dm-crypt, but I don't know if it is like classic dm-crypt setups where the key itself is simply a hash of the password, or if it is LUKS style, where the key is random (or at least psuedo-random) and itself is encrypted using the hash of passwords, allowing for trivial password changes and multiple valid passwords.
This post written from a laptop with a LUKS-root filesystem. I catted a 280 MB file into dev null, it took 17.8 seconds. I copied that file to a filesystem on the exact same drive, umounted the filesystem, remounted it, and tested that, it took 12.5 seconds Top showed the crypt activity as taking about 50% of my cpu in the first case, my Pentium M at the time of measurement clocked only up to 800 MHz to accommodate the load. This test was repeated a few times with a small degree of variation.
Anyway, those metrics are actually more different than I would have expected. I was hoping to demonstrate that the difference isn't that much, but objectively it is disk io performance hit. In general use I don't notice it. I already had a crappy hard drive that was dog slow, and in the end adding encryption made it... still a crappy hard drive that is dog slow, and the extra slowness I didn't even bother perceiving until I tried to measure it. I used this laptop for a few weeks with no encryption, and on the next install did encryption from the get go on everything from/, and didn't notice a problem at all.
That's a foolish assumption. Assumptions like this can result in less secure systems than a wireless system. In a wireless system people are highly aware of the risk of injection risks and eavesdropping, so they are more likely to employ cryptographically sound methods of protection.
Your best bet would be to wire it, because that's sane and doesn't require EM bandwidth sucked up for a very static setup, and don't assume someone can't eavesdrop and/or inject commands. Assume a world where such a deployment were common place, and the unlock codes were like the power button code on a remote control. A burglar would have a device that attempts to induce a signal in a nearby wire cycling through the commonly used unlock codes near the lock, and might get luck. A more determined burglar could probably detect where the cable is, drill a hole, and get at the wire even if the shielding were enough to make it difficult. Drilling a hole is easier to do quickly and quietly than cutting the locks or around the locks, so it would represent a realisitc path to getting into a house unwanted.
As to the rest of the stuff mentioned, some has merit, some doesn't. For example if a unskippable sequence begins in a game that you have seen before comes up and you switch away to do something else while it plays out, it would be unfortunate if the game console decided you must want it to wait for you. Similarly if you are switching away real quick and your HTPC screen locks just because of it, it could be annoying. Maybe you could have a timeout that is more relevantly linked to the state of the video output rather than user activity. Also turning on when you switch to an input may be undesirable. A lot of remotes conserve space by having a single source change button, which works fine as it stands today, but if your systems turned on and you had to turn them off just because you happened to cycle through them would be annoying.
The stove timer similarly could be annoying, I don't want to set a timer for everything I put on the stove top to keep the warning from firing. Maybe you could make it sophisticated such that if a timer is set, assume the user wants any pre-emptive alarms suppressed for the duration, if motion is occurring in front of the stove, assume the person is aware of the situation and not fire an alarm. Maybe if no weight is on a particular section that's on for a period of time also alarm.
Alarm clock prospect I can't argue except it's weird that it knows where I am. The remote as well I think makes sense.
All the remotely dealing with the kids is bad parenting, and should not be encouraged.
I have a much lower tech solution to the bathroom with no toilet paper, I have spare toilet paper rolls in every bathroom in convenient places so I never need assisstance from my wife. Sometimes over complicating things is not the answer. Rube Goldberg-like solutions generally should give you pause and invite you to think of a simpler answer.
There exist *many* very complex complete control systems for HVAC. Hell, even my house has shared thermostats between heating and cooling and both cannot be active at a time (well, for a given zone).
Just because your HVAC system at your office was poorly implemented (don't even know how long ago it was set up), doesn't mean most modern deployments lack common control systems that are more intelligent, sensors for more zones, and vent control to direct hot or cold air as appropriate based on appropriately fine grained zones.
One thing I do think fails a sanity check for me is that places with large datacenters, AFAIK in the winter do fairly inefficent stuff. The heat will be on to the rest of the building as if this blazing hot datacenter didn't exist, and the datacenter AC units will be on full blast in the datacenter, ignoring the fact that the rest of the building has undesired cold air. I would think they could do some air exchange where air from the rest of the cold building's air returns can injected into the datacenter and the heat exhaust from the datacenter be fanned into the ductwork for the vents in the places that need warmth. With fans and dynamic duct routing (makes no sense in the summer), efficiency could be increased such that for the most part, only heat is needed to supplement the exhaust (if the BTUs of the datacenter can't warm the facility in and of itself), or cooling is needed (if the datacenter produces so much BTU that the entire place would get too hot).
Copper pennies aren't made anymore, because, you guessed it, the amount of copper required to make a penny is worth more than 1c, so if they made copper pennies you'd be theoretically better off melting them down and selling the raw material...
If they are talking about servers concurrently running more than one OS, then yes, fully expect that since servers frequently leverage virtualization to separate services or leverage services appropriate to disparate OSs without incurring hardware cost....
Dual booting servers is rare, but not unheard of. Servers in this case are farms that are repurposed frequently. However, at least the outfits I've seen, this is typically done using rapid image deployment, but having both images on drives and fitzing with the boot loader time is an important strategy when the servers must maintain persistant state across repurposing between a set of purposes, or when turn-around time is critical. Additionally, a software development company will more often than not offload the responsiblity of switching between test platforms to servers where they can be managed more by administrators and leave development workstations simple for the desktop.
That leaves some development workstations as the one population that IDC would particularly concern itself with (they don't care about the home market 'hobbyists'), and I still wouldn't doubt repurposed farm servers and development/test servers would outnumber those...
Q: Are ASICs really that much better than general-purpose circuits? Yes, that's why anyone would bother. Q: If so, does that mean that IBM was right all along with their AS/400, iSeries product which makes heavy use of ASICs? A: Yes and no. More relevant will Cell pave the way to good price/performance. The problem with the iSeries line is not so much performance, but price/performance For the same cost of an iSeries config you can cluster a bunch of xSeries and beat it through sheer brute force of CPUs. If the QS20 and followups yield better price/performance, it could be interesting.
At the time of my looking at it, sure amounts were at 1,000 bucks or higher, but that was the starting bid and no one has yet bid on it. Not saying it won't happen, but at the time of story posting it is misleading.
Probably somewhere between, but how many of those who pirated Photoshop would have bought it if they could not have possibly pirated it, instead of coming to grips with using a legitimately free alternative like gimp, even if it wasn't quite so easy to use or didn't have some subset of features that photoshop has? Sure, if they adjusted the price down, the ratio would go up in that scenario, but the commercial sales would probably not increase appreciably and overall their revenue would actually suffer.
Let's say they had a 5% hit ratio (probably in the ball park) of amateur Photoshop users with illegitimate copies who either currently or will end up with photo editing responsibilities in a professional capacity, and only know how to use photoshop to acheive their goals. The cost to Adobe for users pirating their software is actually pretty much nothing, no manufacturing or distribution costs and no support costs for those who pirated. Looking for commercially pirated or commercial entities using pirated copies certainly contains possibility for litigation revenue (portion of profits, etc etc), and commercial entities are willing to pay money for support and training, but there is nothing to gain really by pursuing home 'enthusiasts' except scaring people away from their product to alternatives they may end up choosing professionally, where it could really hurt..
MS faces the same circumstances, but approached it in a way through contracts with OEMs to all but force their product to be nearly universally available legitimately, so they haven't had to implicitly tolerate illegitimate copies to the same extent Adobe has (photoshop is hard to pitch as a requirement to OEM's, unlike an OS). So the Photoshop analogy, despite being a fair assessment of Adobe's circumstances, may not be relevant so much to Microsoft's position.
I can't stand the use of 'begs the question' this way, screw 'modern usage', it gets on my nerves...
Second off, what OS would not theoretically need anti virus software at some point if scaled to larger, less knowledgeable markets? Don't get me wrong, I use a Linux distribution and am a big fan, but I'm not seeing architecturally much improvement beyond protecting users from other users on a system better than default Windows installs, as well as protecting system binaries. That's a vast vast improvement, but there are always gaps. Let's say, for example, malware embeds itself into the gnome-session auto-startup. That piece of malware from that users perspective could be as destructive and performance degrading as any system level utility (i.e. zap ones documents, etc etc). With the increasing prevalence of linux desktop design catering to making life easier, I wouldn't be surprised of some D-BUS architecture issue comes up that gives malware a way beyond what things are meant for anyway. In short, it's easy to point and laugh at MS (which admittedly pre-Vista has done far less than other platforms to be secure), going forward we may find that the more fringe platforms in desktop usage can be made to suffer in a similar way to MS software does today. MS in Vista *may* have gotten the point (we'll see), and, albeit annoyingly, takes measures to protect user from himself and applications while maintaining some degree of user-friendliness.
One demonstrative point, Windows used to be rightfully blasted for having open services. They over time closed them in default installs. However, they also have a more stringent firewall configuration to intervene and block traffic to a service that may be listening, and with XP SP2 and Vista, this is there to give the OS fine-grained control over the security policies with moderately effective strategies. I have noticed Ubuntu taking the approach of zero firewall config or even a hint to point people to take measures. The logic being 'we don't have listening services anyway, so it's redundant'. For the sake of ease-of-use, they leave the low level filtering wide open and rely upon the fact that any services running are blessed by the user, the applications have sane policies, and the user is not stupid. An example of this strategy being dangerous: I ('dumb' user) see this neat utility in the apt repo called synergy. I install it and start it up and happily use it as a dumb user with two systems near each other. Meanwhile, since synergy is very lax and is designed explicitly to be protected by other measures, a malicious user connects and pretends to be your other computer. Without thinking you type a password (which often has no feedback anyway), and the malicious user grabbed all they needed, because no firewall policy was in effect to supplement application security that didn't even try.
Yeah, sure, ssh, telnet, whatever, from my argument they were equivalent, since I was discussing the servicability and use of the stuff, not doing it in a secure way.
The one thing that gives me pause is that conserver supports simple tcp connections (aka telnet) directly in a way that scales to very high numbers with little additional overhead, while I'm not sure there is an equivalent solution that can scale active ssh sessions in the same way, so from an efficiency standpoint with a lot of nodes (hundreds being monitored concurrently) ssh may be something to not be too absolute over. Of course, this requires that you architect the network correctly. In our setups, the only bridge between the terminal servers and other networks are systems that if any of them were compromised, that in and of itself would be an order of magnitude of a worse situation than getting console access to the managed systems...
Slashdot Mirror
Why would a jar with some semen in it be any more likely to contain DNA than all the other remains? In fact, if sperm were somehow miraculously well preserved in and of itself, you could probably recover some from the appropriate organs in the mummified remains (unless they had the testicle jar, but I never heard of that one). Anyway, non-gamete DNA for cloning would hypothetically be more interesting anyway than fertilizing a modern egg with half DNA from 4 millenia go. If you're going to make something like that, why only care about half the old DNA when you could have the whole thing? Even without cloning analysis can be done on the DNA versus today for a bulk of the scientific interest anyway, well, comparison for some of what we know today, archival for studies later when more is understood.
DNA may very well already have been extracted and studied, I have no idea, but sperm/semen is much more boring than a full set of chromosomes in a single package.
Wuss, my passwords are almost always inclusive of non-alpha/non-numerical values and are at least 10 characters long. My strategy is ofter to randomly hit buttons without looking, making generous use of the shift key on the number keys...
Example: cS#e(k5L@^
(note: not an actual password, but generated in the same way I generate passwords)
Maybe I'm >50% autistic then since I can remember these...
On some occasions I wuss out and if appropriate to the password parsing/entry technology, make a mostly coherent sentence 64 characters long or so, which I believe is still an order of magnitude more secure than a mere 10 characters of even complete garbage, but it is much quicker to type 10 garbage characters than a whole sentence...
The traditional method dm-crypt and cryptoloop used was basically what you say, a hash of the password was used to encrypt the entire disk. Of course, no one ever devised a way to change the password in place, and even if they did, it would require all data on the disk to be re-encrypted. The key used to actually encrypt the data would likely be cryptographically weaker to crack, in theory. If you ever ever write down the password (I don't but some do) and then lose the paper, you can never be sure about the security of your data again short of re-encrypting the whole thing. I think this is probably the single thing people not researching it thoroughly misunderstand, if the technology you see is definitely encryption of a large data set, and you can essentially instantly change the password protecting it, the key used to encrypt the actual data is certainly not the password itself, as it requires a huge amount of effort to change the key on large amounts of encryted data.
In the LUKS scheme the key material used for the very large data set will probably be more cryptographically sound. With a large data set, cryptographically weak keys could more likely be crackable than strong keys, in a large number of the type of attacks historically seen in cryptography. A small data set (data comprised only of the actual key) is generally more resistant to data analysis attacks, so a somewhat weaker password hash based key may be less exposed in that context. If you ever think a malicious user has had opportunity to get your password (the most likely thing in general for an attacker to get), you can change the password and the old key slot be shredded such that the knowledge obtained becomes useless. Sure, the 'master password' being compromised would mean the disk is irrevocably compromised, but that would be the case in the classical strategy anyway, since changing the password isn't feasible. Now if you want to actually re-encrypt data in the way a password change would require in the previous example, you can always reformat with a different key (or re-encrypt in place if implementation allowed), and have the same degree of 'changing the master password' as you put it.
Keep in mind the 'master password' (or rather the actual key) in this context is probably a random 256 bit value. To achieve a comparable level of randomness, a password consisting of typable characters would have to be about 40 characters long consisting of completely random keypresses. If a person is ever in a position to actually get that master key value, you've already lost the data because before they can get to that key they have to:
-Get root privilges while the volume is mounted to get dmsetup table output, but if it's mounted they could just grab the data anyway.
-Get low-level physical access to your hardware to begin to crack the LUKS header of the partition or the content itself. If they are in a position to do so, they could/would image your entire volume and return your drive. In which case no matter what you do to the copy you got back (re-encrypt, change password, whatever), they can continue whatever crypto-analysis they want on their image of the data as it was when they first took it. You may be able to protect newly written data, but whatever risk of breaking the encryption on existing data is permanently there once imaging is possible.
-Get low-level access to your system and somewhere along the chain insert something to dump the key material to them once available. Again, once this is in play, it's already over no matter what you do, if they can dump that table, they can dump the data directly. In this case, let's assume one of those keyboard bugs slashdot had an article a while back was discovered by you in your system. Knowing that your passphrase is potentially compromised, with the key not based directly on the password, but just encrypted by the password, you can re-encrypt the key once the bug is removed and shred the old slot, and their keylog data becomes useless for the purposes of defeating your filesystem encryption. If the master key is essentially whatever you typed, you are significantly more hosed.
On the remote parenting argument, I've no doubt that the kids aren't so dumb they would only comprehend the message if delivered in person. I'm saying that during human psychological development, there could be non-obvious psychological implications of such interaction based on the kids maturity level. I generally don't think a lot of the psycho-babble we hear necessarily has stock, but a gut feeling tells me impersonal interaction with one's children could fall into the realm of stuff the psycho-babble people would rightfully be concerned with. In the context of an individual isolated incident, a parent choosing an impersonal interaction with a child with the child fully aware the parent could just walk across the hall might have the potential to be more harmful to the child's psyche than the parent choosing not to interact at that specific moment at all. In the later case the child is at least not made explicitly aware of the parent's choice of non-interaction (unless a pattern of non-interaction they can't help but to notice emerges), but in the former case it's very obvious the parent thought of interacting with the child and did not feel it worth the effort to actually personally interact with them. It's also a somewhat intangible invasion of their space. If they turn up their stereo and a phantom hand turns it down without explanation, it could evoke displeasure more so than if a parent asks them to turn it down, even if the parent ultimately physically comes into their room to turn it down in person. A person physically coming in and taking action gives them something more tangible to lock on to and even if pissed off by it, on a deeper level it may be a more comfortable confrontation than the phantom approach.
As to the alarm clock knowing my presence being 'weird', I didn't mean in the sense that I don't understand how it could work, but rather it feels to big-brotherish to me. This is a hard argument to logically win, since the unit can be self contained and in no way hooked up to the internet for someone to possibly exploit it remotely (though most likely it would be, in which case this could be a logically defensible point), it just doesn't feel right. Kinda like having sex in front of your pets, they probably wouldn't give a rat's ass about what's going on if they did understand, and maybe the pet doesn't understand, but it still can feel weird to the people being observed to the point of locking pets out of the room for the duration, to avoid that awkwardness.
In general there are steps I think could be improvements, but much like in the 'houses of tomorrow' from the 60s, a lot of futuristic visions ultimately create more complexity than simple approaches that in the aggregate aren't really that inconvenient. Sometimes the geekiness in us will yearn for the 'cool' solution, when ultimately we'd get sick and tired of the complexities introduce that end up more aggrevating than the inconvenience it was invented to address.
Based on the readme, it looks like encfs (which uses fuse and openssl). It might obscure more detail (i.e. with encfs you know how many files and directories there are, and their timestamps). How does it differ from encfs (http://encfs.sourceforge.net/)?
/boot (which I do). This has benefit for protecting against physical threats and people trying to reboot your system using a live cd or other such attacks. However, the key is always available to the kernel and all the data is visible, so a remote or local attack that acheives root privileges means all the data is exposed since a very coarse grained attack was used. On the bright side, it is also appropriate as a codified standard because users can't generally be trusted to correctly perform risk assessments on every save or understand all the temporary places they may save to, and it's the only way to protect swap patitions. I use dm-crypt with LUKS partitions for / and swap on my laptop, with a small /boot for the kernel and luks-enabled initrd.
/tmp is always exposed and swap is still dm-crypt protected on that system.
encfs is of course per user, and a somewhat nifty thing there is the pam_encfs module which can optionally used to get the authentication token to unlock its key. The implementation (since it's obviously has to be since it's a fuse thing) is more userspace than ecryptfs, but functionally speaking, what's the difference?
I understand well the benefits compared with dm-crypt strategy based on the circumstances and requirements.
With block level strategies, you have to decide the total size of the block device for protected vs. non-protected data. If you don't understand your needs well, it's difficult to apply a finer-grained approach to security, particularly if you are required to codify it into a company standard for people who you definitely won't understand perfectly the needs of. Because of this, the only generally feasible approach is to encrypt everything save for
encfs and similar strategies feasibly allow finer grained policies to go into place without making the tough size decisions as is needed with block strategies. This provides all the protection from theft and such like dm-crypt does. And if the policies are fine grained and the directories are only mounted as needed, a remote attacker achieving root access will only be able to get to file systems currently mounted, which may be a smaller set than the whole. The difficulty here is that when defining a finer-grained policy, you have to know which directories could ever hold sensitive data, If you are to protect swap you can't use a swap partition, but a swapfile in a directory protected by such a scheme, and in the end on a single user system (almost all laptops), effectively no matter what all the encrypted filesystems will be mounted anyway most all the time, so it's really not ultimately much of a functional difference. I make encfs available on a couple of multi-user systems, and generally have pam_encfs there to make their home directories encrypted.
The hard disk password isn't encryption, it's just a handshake with the controller chip on the hard drive. I don't know what method they used, but generally speaking the data on the platters is unprotected and theoretically swapping the little controller board bit of the drive would bypass it.
Whatever hardware assisted encryption there is to be had in Thinkpads would be that stuff provided for 'trusted' computing. I have no insight on what it could actually do *for* the user as opposed to against it, but also based on my experience I don't think I need to offload the work as it isn't that intensive for a single user system anyway.
My link full disk encryption is a company laptop.
-Key recovery mechanism:
In my case (and most sane companies), the IT dept with respect to this will let you proceed at your own risk with respect to laptop protected data. With any desktop/laptop install, there is a ever present risk of catastrophic disk failure, so IT policies have to dictate how to cope with sudden loss of all data on a desktop or laptop anyway, if it's because the luser forgot their password or because a drive head started skipping across the platter surface, generally it's all the same. In my case we are provided network storage space, where they manage redundancy, backups, and the associated recovery and maintenance. If the data is so damned important, stick it out there.
I also laid out a strategy for this in another post if IT insists on key recovery. LUKS has multiple key slots and by extension can support multiple passwords. Use a key slot for the IT password unknown to the user, and one other for the user password unknown to IT. User can screw it up if they desire, but users can always screw it up if they want to, the goal is to keep a reasonable expectation of recovery, but can never win in the face of user who does not want the data recovered (unless said user is just too stupid to figure it out).
-Corporate standards.
The standards of the company just have to be intelligent. In my case, standards when first published required that all company data be protected, and they recommend ed gpg or windows folder encryption to start with, for linux and windows respectively. Auditors have examined my setup, and I showed them the indicators of the method I used and pointed out reference material for their review. At the end the auditors, (who were almost entirely windows people), concurred it went above and beyond the corporate standards and after my audit, future users who had a similar setup had a simple, straightforward audit.
I need my /boot unencrypted or else grub can't load my kernel, and of course the initrd with dmsetup and cryptsetup in it.
As for / and every other persistent storage, you're good encrypting it.
All the fingerprint and user authentication in the world is a poor defense against someone ripping out the drive, which is easy if the laptop is stolen. That's why it is generally a larger issue on laptops than desktops. Desktops tied to your desk at work have whatever physical security the company has invested in protecting it, leaving it open only to the possiblity of remote attackers (well, within reason, the physical security can be bypassed, but assume a perfect company for discussion). The whole threat of a laptop is physical security breaches, otherwise the discussion wouldn't be laptop-centered. As to not putting confidential stuff on laptops, it is a good idea, but that is a policy rooted in trusting the user to always be vigilant about the confidentiality of the data set they are working, trusting their judgment, and expecting them not to take convenient short cuts at 5pm on a Friday so they can get it done on the weekend without staying late or looking bad on Monday. I use full disk encryption so I don't have to even think about it. I'm fairly sure I have nothing on my laptop remotely of interest to anyone, but I never have to think too hard about it.
Encrypted swap and encrypted / the way to go in linux. In Windows there exists third party software that encrypts more widely Basically at the earliest screen before the XP logo is even displayed, someone has to blind type the password for it to boot. Guy at work uses it, I know no more details than that.
I'm going to use LUKS as my example, since the classic cryptoloop and older dm-crypt stuff can't do this.
The solution is for IT to have a person perform the install (already was going to be hard not to do so with the current state of installers). The IT person makes a master copy of the key using the company's chosen password, and uses a different key slot for the employee-known password. When password changes occur, IT people have to go and change the IT-friendly key slot to the new password, but leave the employee's alone. Then IT can recover data from laptops at user requests. This doesn't guarantee data recovery from a system if the user who can change the password on their own key slot doesn't want them to, but if the user wants to play nice to keep IT able to assist them it can work. If the user botches the IT key slot and needs recovery, tough. Data on a laptop in that circumstance should be relatively transient if remotely important, with the real copies on file servers where IT can manage backup and recovery as they see fit.
At work the mandate for Windows laptops is to use the built in encrypted folders mechanism, which is a lot like encfs. If they loose their user password for the account the data is gone, and this is just a fact of life they have to live with. One person went further and put some third-party whole disk encryption on their Windows laptop, a la dm-crypt, but I don't know if it is like classic dm-crypt setups where the key itself is simply a hash of the password, or if it is LUKS style, where the key is random (or at least psuedo-random) and itself is encrypted using the hash of passwords, allowing for trivial password changes and multiple valid passwords.
This post written from a laptop with a LUKS-root filesystem. I catted a 280 MB file into dev null, it took 17.8 seconds. I copied that file to a filesystem on the exact same drive, umounted the filesystem, remounted it, and tested that, it took 12.5 seconds Top showed the crypt activity as taking about 50% of my cpu in the first case, my Pentium M at the time of measurement clocked only up to 800 MHz to accommodate the load. This test was repeated a few times with a small degree of variation.
/, and didn't notice a problem at all.
Anyway, those metrics are actually more different than I would have expected. I was hoping to demonstrate that the difference isn't that much, but objectively it is disk io performance hit. In general use I don't notice it. I already had a crappy hard drive that was dog slow, and in the end adding encryption made it... still a crappy hard drive that is dog slow, and the extra slowness I didn't even bother perceiving until I tried to measure it. I used this laptop for a few weeks with no encryption, and on the next install did encryption from the get go on everything from
>Not wireless, so it can't be exploited.
That's a foolish assumption. Assumptions like this can result in less secure systems than a wireless system. In a wireless system people are highly aware of the risk of injection risks and eavesdropping, so they are more likely to employ cryptographically sound methods of protection.
Your best bet would be to wire it, because that's sane and doesn't require EM bandwidth sucked up for a very static setup, and don't assume someone can't eavesdrop and/or inject commands. Assume a world where such a deployment were common place, and the unlock codes were like the power button code on a remote control. A burglar would have a device that attempts to induce a signal in a nearby wire cycling through the commonly used unlock codes near the lock, and might get luck. A more determined burglar could probably detect where the cable is, drill a hole, and get at the wire even if the shielding were enough to make it difficult. Drilling a hole is easier to do quickly and quietly than cutting the locks or around the locks, so it would represent a realisitc path to getting into a house unwanted.
As to the rest of the stuff mentioned, some has merit, some doesn't. For example if a unskippable sequence begins in a game that you have seen before comes up and you switch away to do something else while it plays out, it would be unfortunate if the game console decided you must want it to wait for you. Similarly if you are switching away real quick and your HTPC screen locks just because of it, it could be annoying. Maybe you could have a timeout that is more relevantly linked to the state of the video output rather than user activity. Also turning on when you switch to an input may be undesirable. A lot of remotes conserve space by having a single source change button, which works fine as it stands today, but if your systems turned on and you had to turn them off just because you happened to cycle through them would be annoying.
The stove timer similarly could be annoying, I don't want to set a timer for everything I put on the stove top to keep the warning from firing. Maybe you could make it sophisticated such that if a timer is set, assume the user wants any pre-emptive alarms suppressed for the duration, if motion is occurring in front of the stove, assume the person is aware of the situation and not fire an alarm. Maybe if no weight is on a particular section that's on for a period of time also alarm.
Alarm clock prospect I can't argue except it's weird that it knows where I am. The remote as well I think makes sense.
All the remotely dealing with the kids is bad parenting, and should not be encouraged.
I have a much lower tech solution to the bathroom with no toilet paper, I have spare toilet paper rolls in every bathroom in convenient places so I never need assisstance from my wife. Sometimes over complicating things is not the answer. Rube Goldberg-like solutions generally should give you pause and invite you to think of a simpler answer.
There exist *many* very complex complete control systems for HVAC. Hell, even my house has shared thermostats between heating and cooling and both cannot be active at a time (well, for a given zone).
Just because your HVAC system at your office was poorly implemented (don't even know how long ago it was set up), doesn't mean most modern deployments lack common control systems that are more intelligent, sensors for more zones, and vent control to direct hot or cold air as appropriate based on appropriately fine grained zones.
One thing I do think fails a sanity check for me is that places with large datacenters, AFAIK in the winter do fairly inefficent stuff. The heat will be on to the rest of the building as if this blazing hot datacenter didn't exist, and the datacenter AC units will be on full blast in the datacenter, ignoring the fact that the rest of the building has undesired cold air. I would think they could do some air exchange where air from the rest of the cold building's air returns can injected into the datacenter and the heat exhaust from the datacenter be fanned into the ductwork for the vents in the places that need warmth. With fans and dynamic duct routing (makes no sense in the summer), efficiency could be increased such that for the most part, only heat is needed to supplement the exhaust (if the BTUs of the datacenter can't warm the facility in and of itself), or cooling is needed (if the datacenter produces so much BTU that the entire place would get too hot).
It's not a bug, it's a feature!
Copper pennies aren't made anymore, because, you guessed it, the amount of copper required to make a penny is worth more than 1c, so if they made copper pennies you'd be theoretically better off melting them down and selling the raw material...
If they are talking about servers concurrently running more than one OS, then yes, fully expect that since servers frequently leverage virtualization to separate services or leverage services appropriate to disparate OSs without incurring hardware cost....
Dual booting servers is rare, but not unheard of. Servers in this case are farms that are repurposed frequently. However, at least the outfits I've seen, this is typically done using rapid image deployment, but having both images on drives and fitzing with the boot loader time is an important strategy when the servers must maintain persistant state across repurposing between a set of purposes, or when turn-around time is critical. Additionally, a software development company will more often than not offload the responsiblity of switching between test platforms to servers where they can be managed more by administrators and leave development workstations simple for the desktop.
That leaves some development workstations as the one population that IDC would particularly concern itself with (they don't care about the home market 'hobbyists'), and I still wouldn't doubt repurposed farm servers and development/test servers would outnumber those...
Q: Are ASICs really that much better than general-purpose circuits?
Yes, that's why anyone would bother.
Q: If so, does that mean that IBM was right all along with their AS/400, iSeries product which makes heavy use of ASICs?
A: Yes and no. More relevant will Cell pave the way to good price/performance. The problem with the iSeries line is not so much performance, but price/performance For the same cost of an iSeries config you can cluster a bunch of xSeries and beat it through sheer brute force of CPUs. If the QS20 and followups yield better price/performance, it could be interesting.
At the time of my looking at it, sure amounts were at 1,000 bucks or higher, but that was the starting bid and no one has yet bid on it. Not saying it won't happen, but at the time of story posting it is misleading.
Probably somewhere between, but how many of those who pirated Photoshop would have bought it if they could not have possibly pirated it, instead of coming to grips with using a legitimately free alternative like gimp, even if it wasn't quite so easy to use or didn't have some subset of features that photoshop has? Sure, if they adjusted the price down, the ratio would go up in that scenario, but the commercial sales would probably not increase appreciably and overall their revenue would actually suffer.
Let's say they had a 5% hit ratio (probably in the ball park) of amateur Photoshop users with illegitimate copies who either currently or will end up with photo editing responsibilities in a professional capacity, and only know how to use photoshop to acheive their goals. The cost to Adobe for users pirating their software is actually pretty much nothing, no manufacturing or distribution costs and no support costs for those who pirated. Looking for commercially pirated or commercial entities using pirated copies certainly contains possibility for litigation revenue (portion of profits, etc etc), and commercial entities are willing to pay money for support and training, but there is nothing to gain really by pursuing home 'enthusiasts' except scaring people away from their product to alternatives they may end up choosing professionally, where it could really hurt..
MS faces the same circumstances, but approached it in a way through contracts with OEMs to all but force their product to be nearly universally available legitimately, so they haven't had to implicitly tolerate illegitimate copies to the same extent Adobe has (photoshop is hard to pitch as a requirement to OEM's, unlike an OS). So the Photoshop analogy, despite being a fair assessment of Adobe's circumstances, may not be relevant so much to Microsoft's position.
People going through any given Xenosaga game....
I can't stand the use of 'begs the question' this way, screw 'modern usage', it gets on my nerves...
Second off, what OS would not theoretically need anti virus software at some point if scaled to larger, less knowledgeable markets? Don't get me wrong, I use a Linux distribution and am a big fan, but I'm not seeing architecturally much improvement beyond protecting users from other users on a system better than default Windows installs, as well as protecting system binaries. That's a vast vast improvement, but there are always gaps. Let's say, for example, malware embeds itself into the gnome-session auto-startup. That piece of malware from that users perspective could be as destructive and performance degrading as any system level utility (i.e. zap ones documents, etc etc). With the increasing prevalence of linux desktop design catering to making life easier, I wouldn't be surprised of some D-BUS architecture issue comes up that gives malware a way beyond what things are meant for anyway. In short, it's easy to point and laugh at MS (which admittedly pre-Vista has done far less than other platforms to be secure), going forward we may find that the more fringe platforms in desktop usage can be made to suffer in a similar way to MS software does today. MS in Vista *may* have gotten the point (we'll see), and, albeit annoyingly, takes measures to protect user from himself and applications while maintaining some degree of user-friendliness.
One demonstrative point, Windows used to be rightfully blasted for having open services. They over time closed them in default installs. However, they also have a more stringent firewall configuration to intervene and block traffic to a service that may be listening, and with XP SP2 and Vista, this is there to give the OS fine-grained control over the security policies with moderately effective strategies. I have noticed Ubuntu taking the approach of zero firewall config or even a hint to point people to take measures. The logic being 'we don't have listening services anyway, so it's redundant'. For the sake of ease-of-use, they leave the low level filtering wide open and rely upon the fact that any services running are blessed by the user, the applications have sane policies, and the user is not stupid. An example of this strategy being dangerous: I ('dumb' user) see this neat utility in the apt repo called synergy. I install it and start it up and happily use it as a dumb user with two systems near each other. Meanwhile, since synergy is very lax and is designed explicitly to be protected by other measures, a malicious user connects and pretends to be your other computer. Without thinking you type a password (which often has no feedback anyway), and the malicious user grabbed all they needed, because no firewall policy was in effect to supplement application security that didn't even try.
If the alien happened to be Admiral ZEX...
Yeah, sure, ssh, telnet, whatever, from my argument they were equivalent, since I was discussing the servicability and use of the stuff, not doing it in a secure way.
The one thing that gives me pause is that conserver supports simple tcp connections (aka telnet) directly in a way that scales to very high numbers with little additional overhead, while I'm not sure there is an equivalent solution that can scale active ssh sessions in the same way, so from an efficiency standpoint with a lot of nodes (hundreds being monitored concurrently) ssh may be something to not be too absolute over. Of course, this requires that you architect the network correctly. In our setups, the only bridge between the terminal servers and other networks are systems that if any of them were compromised, that in and of itself would be an order of magnitude of a worse situation than getting console access to the managed systems...
"Yes, my one month old T60 too is on the list. Though I will wait out till the initial rush dies out."
For tradition, shouldn't you have said:
"Yes, my one month old T60 too is on the list. Though I will wait out till %@^@^%#@%@%@! NO CARRIER"