Random access to an encrypted file
in [Java Programming]
|
Prev: Wholesale new MLB jerseys,low price high quality,paypal payment
Next: Quartz with Spring: more jobs with different input argument
From: Arne Vajhøj on 27 Apr 2010 19:52 On 27-04-2010 04:15, Roedy Green wrote: > 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. I would expect every algorithm to have a very well defined function for the size after encryption depending on the size before encryption. 100% predictable. Arne
From: Mike Schilling on 27 Apr 2010 23:53 Arne Vajh�j wrote: > On 27-04-2010 04:15, Roedy Green wrote: >> 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. > > I would expect every algorithm to have a very well defined > function for the size after encryption depending on the > size before encryption. 100% predictable. I wouldn't. E.g an algortihm whose first step is to convert an array of chars to an array of bytes encoded in UTF-8.
From: Arved Sandstrom on 28 Apr 2010 05:25 Arne Vajhøj wrote: > 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 > No, security should not rely on every employee being with the company, but the general point is still a good one. Consultants such as myself spend most of their time on client sites and so much of our disgruntlement (or gruntlement) stems from client behaviour, not from the actions of our own companies. If we've been with one client long enough we actually start feeling like we're with that client, and the feeling is mutual...provided that it's a good client. So Lew's arguments apply. AHS
From: The Frog on 28 Apr 2010 08:34 I find it amazing that everyone is throwing around encryption suggestions like pills for the common cold here. I have come to respect the contributors to thsi group greatly as the bredth and depth of knowledge in the Java environment is truly overwhelming. I am not able to say the same about the understanding of security and cryptography. Let me see if I can explain why: Firstly security and cryptography are two separate things. Security may use cryptography as a tool to get the job done but never the other way around. That means that cryptography by itself is not security. In short security is not a product, and algorithm, or a 'system', but in fact a method to achieve a goal. This method is rooted in risk analysis and the application of tools, designs and methods to mitigate those risks. The small encrypted partition that is mentioned in a previous post may provide some risk mitigation against a physical theft but may also not provide any risk mitigation against other forms of attack - such as IP based attacks. A simple example to be sure, but it makes the point quite clearly: Cryptography is not a cure all. If the OP is indeed wanting to mitigate riks for legal compliance or insurance complaince then the best thing they can do is to review their needs and situation with an experienced professional who understands how to correctly manage these risks. This is most probably not a trivial task, and from my experience in software development, inclusing inside the security industry, it often times requires a complete restructuring of the operational mechanisms of the program / application / network / system / trust model / cryptography in question. Unfortunately it is not realistic to slap on a security band- aid to cover up a risk and expect a secure outcome. I hope I dont upset anyone with this, however I felt it necessary to share the broader picture with the OP given the lack of context they have provided. Cheers The Frog
From: Spud on 28 Apr 2010 22:15
On 4/26/2010 2:21 PM, Martin Gregorie wrote: > On Mon, 26 Apr 2010 10:41:36 -0500, Spud wrote: > >> 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). >> > Why not simply store the files in an encrypted disk partition? > > The OS does all the grunt-work, including prompting for the password at > boot time, and the application(s) don't need to change. The encryption is > transparent to them because it takes place at a lower level. > > Sorry it's taken me a few days to respond. This is for an app that gets distributed to customers, and we can't require our customers to configure anything at the OS level. (Most of them wouldn't do it). Also, the same data files are going to get copied to different places. At a minimum they'll get copied to additional servers for scalability, but they also may get copied to backups or different data centers. Bottom line is, the files themselves have to encrypted so even if a bad guy gets access to the disk or the backups, the files can't be used without the secret key. |