Log in

No account? Create an account

Previous Entry | Next Entry

security -- hip deep in *something*

so............ damn. Spent the last two or so hours hip deep in java security stuff, basically. I'm all OVER both java.security and javax.crypto. what I can't find is a encoding that does public/private key. It took me a long time to figure that out, so far as I can tell.

Cipher implementations available include:
'DESede' 'DES' 'TripleDES' 'PBEWithMD5AndDES' 'PBEWithMD5AndTripleDES' 'Blowfish'

Keypair implementations available include:
'DiffieHellman' 'RSA' 'DSA' '' 'OID.1.2.840.10040.4.1' 'DH' '1.2.840.10040.4.1'

I *have* found an example that uses a DH keypair exchange to then generate a shared DES secret key which can then be used to both encrypt and decrypt.

is this overkill?? the main concern is I use a lot of "defaults" in all of this, and it's mostly stuff I don't understand the internal mechanisms of. And ostensibly HALF of this would be done in the java I "just learned" and half would be done in c/c++ that I have yet to learn but am fairly confident can handle anything java has. however, I have no guarantees that the defaults of the c/c++ libraries would agree with the java defaults. I wasn't too worried with just a "simple"??? private/public generation, send public, encode message with public, send encoded message, decode with private... all I want is to validate one password and I don't give a DAMN if the rest of the conversation is broadcast on times square!



seriously, I'm about to just send the sucker in plain text and to hell with the alamo!

maybe I should sleep on that thought. Or work on some part that doesn't require anything fancy. or... yeah. I can work on it and hope the security fills itself in at some later date. productive good.

(Ideally, RSA would show up among the Ciphers and just make life happy and dandy... maybe it's in the newer crypto stuff released with jdk14?? guh. hmm.)


( 3 comments — Leave a comment )
Oct. 10th, 2002 03:59 am (UTC)
well, I found "bouncycastle" which I have to admit is amazing. it's a security provider that plugs in to everything just as neat as you please. the downside is it's 980k.

though I suppose that doesn't matter so much. the upstream doesn't have to have it in java... just need to be able to compile the necessary libraries in c for the *users*... maybe I *should* go with it. maybe. guh.

now that I think about it, the client does need some sort of validation, too. i was thinking the http session business would work fine, but I'm not sure if ye olde random servlet being accessed through a port it is listening to as opposed to through the standard methods servlets get called on can grab access to session information. Probably can somehow, since it's in the same VM and all. hope so?

(to try and confuse a little less: trying to validate two folks who want to chat with eachother. through a server. at least one of them needs a username and password. the other one COULD need username/password, but ideally in the case of them needing it it's already been validated and that validation has been stored in the http session that's spawning their client (applet) and the session (id) itself can just be passed)
Oct. 10th, 2002 04:00 am (UTC)
just to compare, look at what bouncycastle comes with:

Cipher impls:

Keypair impls:
'DSA' 'RSA' 'DH' 'OID.1.2.840.10040.4.1' 'DiffieHellman' 'ECDHC' 'ELGAMAL' '1.2.840.113549.1.1.1' 'ECDSA' '1.2.840.10040.4.1' 'ECIES' 'ECDH' ''
Oct. 10th, 2002 11:43 am (UTC)
I suggest you acquire this book:

2. Schneier, Bruce, 1963-
Applied cryptography : protocols, algorithms, and source code in C
/ Bruce Schneier. 2nd ed.
New York : Wiley, c1996.

Engineering QA76.9.A25.S35 1996
( 3 comments — Leave a comment )

Latest Month

February 2016


Page Summary

Powered by LiveJournal.com
Designed by chasethestars