File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Security and the fly likes Keyczar Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Engineering » Security
Bookmark "Keyczar" Watch "Keyczar" New topic
Author

Keyczar

Aryan Khan
Ranch Hand

Joined: Sep 12, 2004
Posts: 290

Has any one used the Keyczar.

Looks pretty cool. I always favored such security tools to hide the complicated JCA and JCE APIs.

Also it will use the safe algorithms, key sizes which many might not have a clue of even if they know the JCE & JCA APIs.

More features are being added to future releases.
Aryan


OCP/MCP/SCJP/SCWCD/IBM XML/SCMAD/SCEA-1
Set Cruz
Greenhorn

Joined: Jan 31, 2008
Posts: 26
I haven't used it. I have no plans to try it out.

Let me share my opinion as to why. I understand that the raw API's are not convenient, but I'm not sure that adding a level of abstraction is best. The documentation keyczar link promises to select algorithm recipes that are "safe " for the developer. Without further looking into keyczar, I would warn that such "safety" is a dynamic quantity, subject to research trends and discoveries. For instance, SHA1 fell out of favor after collisions had been discovered by researchers. At best, a developer would have to depend on the keyczar release cycle to bring their code to the next level of safety in such an event. At worst, a vulnerability discovered today will simply go unnoticed in an abstracted API.


SCJP, Oracle PL/SQL Developer
greg stark
Ranch Hand

Joined: Aug 10, 2006
Posts: 220
Perhaps, but all your objections also hold for using lower-level APIs; I think even more so.


Nice to meet you.
Aryan Khan
Ranch Hand

Joined: Sep 12, 2004
Posts: 290

Set, Good point there.

But there is always trade off. I think such weaknesses in algorithms does not render them "NOT TO USE" from the moment. DES is such an example. Still being used in banking industry.

Finding SHA-1 collisions require sufficient computing power and time etc, so looking at the mass application requirements, the cover time etc, to me it worths having a such a level of abstraction.

After all how many ppl out there can find SHA-1 collisions as compared to how many can write good Cryptographic applications.
Aryan
Bear Giles
Greenhorn

Joined: Mar 16, 2006
Posts: 25
The hard thing in crypto isn't the libraries, it's knowing how to use it in the real world. Libraries are dangerous because they give newbies a false sense of security that they've used the crypto properly.

(Glares at 99% of the 'encrypted database' solutions...)

(Glares at 90% of the 'here's how you store a server key' solutions...)

That said, libraries can be useful on some of the grunt work. E.g., I have a small unpublished library that provides a Spring factory class for each of the appropriate java.security and javax.security classes (themselves injected with the algorithm name and optionally provider) push a few utility classes. But that only took a day to write, hardly worth the hassles of finding and maintaining a third-party library.


SCJP 5 & 1.4, SCWCD 1.4, SCBCD 1.3; Security+
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Keyczar