Prev: Wholesale new MLB jerseys,low price high quality,paypal payment
Next: Quartz with Spring: more jobs with different input argument
From: Roedy Green on 27 Apr 2010 04:15 On Mon, 26 Apr 2010 10:41:36 -0500, Spud <fake(a)fkfkfkf.com> wrote, quoted or indirectly quoted someone who said : >We've been told that we need to implement on-disk encryption of our data >files. We currently write them using RandomAccessFile and read them >using FileChannel.read(ByteBuffer). > >Before I go off on my own, slog through java.security, and write a >wrapper around these routines to encrypt/decrypt, is there an easy way >to do it? Perhaps something built into the JDK that I'm missing? The easy way would be to find a database that does encryption. see http://mindprod.com/jgloss/sqlvendors.html for candidates. The awkward thing about roll your own is the growth factor that encryption penalises you is not usually accurately predictable. Check out JCE and benchmark some algorithms. There is quite a difference in speed. In particular check out the new AES. See http://mindprod.com/jgloss/jce.html -- Roedy Green Canadian Mind Products http://mindprod.com It�s amazing how much structure natural languages have when you consider who speaks them and how they evolved.
From: RedGrittyBrick on 27 Apr 2010 07:11 On 27/04/2010 01:58, Mike Schilling wrote: > Martin Gregorie wrote: >> [*] Under Linux you just format an encrypted partition and set the >> password when prompted by the formatter. Each time the partition is >> mounted you get prompted for its password. > > So if the server The OP didn't say if the computers in question were servers. > goes down and back up (say, becasue of a powert glitch), it > can't reboot fully until a human is there to type the password? But don't most servers live in locked rooms with UPS support and are therefore less vulnerable than personal PCs to theft or utility power glitches? If I had to use data encryption on a server I'd make the OS partition unencrypted and have the OS fetch the decryption key for the protected data partition from somewhere relatively safe - in the sense of being unlikely to be stolen or disposed of in conjunction with the disk. Whether that safer place was a human would depend on the risks/costs analysis etc. -- RGB
From: Martin Gregorie on 27 Apr 2010 16:30 On Mon, 26 Apr 2010 17:58:23 -0700, Mike Schilling wrote: > Martin Gregorie wrote: >> [*] Under Linux you just format an encrypted partition and set the >> password when prompted by the formatter. Each time the partition is >> mounted you get prompted for its password. > > So if the server goes down and back up (say, becasue of a powert > glitch), it can't reboot fully until a human is there to type the > password? Correct. As an experiment I added a small, encrypted partition to my Linux server. This is used to store sensitive stuff such as web pages containing account names, passwords, etc. which are made available via a user name/password mechanism by an in-house Apache web server. So far the need to input the encryption password if the server reboots is the only gotcha. The mains is pretty reliable in these parts and the server 'just runs', so as yet I haven't felt the need to add a UPS. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Lew on 27 Apr 2010 18:54 RedGrittyBrick wrote: > Whether that safer place was a human would depend on the risks/costs > analysis etc. In the midst of all the hoopla about viruses and hack-attacks and phishing and blah-blah-blah, the single greatest threat to anyone's resources, corporate or personal, remains insider malfeasance. Most misdeeds originate inside the firewall. Despite this well-established and long-standing fact, many companies continue to treat their employees, white- and blue-collar alike, as expendable cogs. Policies grow more restrictive and ludicrous, until movies like /Office Space/ seem like straight-up documentaries, completely overlooking that it's the people that make the organization function. When the organization continues to strive to antagonize and lose the loyalty of the people who have the inside knowledge, no system or encryption or automated process will rescue them. In a culture of loyalty, an evildoer will be spotted and ratted out much more quickly. These factors are difficult to quantify and uncomfortable to confront, so too many organizations leave them out of the risk and cost-benefit analyses. A software consultant called upon to improve computer security may well serve their client best by a suggestion to throw monthly parties. -- Lew
From: Arne Vajhøj on 27 Apr 2010 19:51
On 27-04-2010 18:54, Lew wrote: > RedGrittyBrick wrote: >> Whether that safer place was a human would depend on the risks/costs >> analysis etc. > > In the midst of all the hoopla about viruses and hack-attacks and > phishing and blah-blah-blah, the single greatest threat to anyone's > resources, corporate or personal, remains insider malfeasance. Most > misdeeds originate inside the firewall. > > Despite this well-established and long-standing fact, many companies > continue to treat their employees, white- and blue-collar alike, as > expendable cogs. Policies grow more restrictive and ludicrous, until > movies like /Office Space/ seem like straight-up documentaries, > completely overlooking that it's the people that make the organization > function. > > When the organization continues to strive to antagonize and lose the > loyalty of the people who have the inside knowledge, no system or > encryption or automated process will rescue them. > > In a culture of loyalty, an evildoer will be spotted and ratted out much > more quickly. > > These factors are difficult to quantify and uncomfortable to confront, > so too many organizations leave them out of the risk and cost-benefit > analyses. > > A software consultant called upon to improve computer security may well > serve their client best by a suggestion to throw monthly parties. Security should not rely on every employee being with the company. That will never be the case for a big company with many employees no matter how good it in general is. Arne |