java - Is there a difference between ECDH and ECDSA keys? -

-

i'm building network application uses bouncycastle cryptography provider. let's have generate keypair:

ecparameterspec ecspec = ecnamedcurvetable.getparameterspec("prime192v1"); keypairgenerator g = keypairgenerator.getinstance("ecdsa", "bc"); g.initialize(ecspec, new securerandom()); keypair pair = g.generatekeypair();

i'm confused why you're getting instance of ecdsa keypairgenerator. why doesn't ec? know there's ecdh key type shipped bouncycastle, thought 2 represented same stuff points on curve -- or wrong theory behind it?

the reason ask right application uses ecdh fine establish aes secret key, want use same ec key sign each message using ecdsa.

ecdsa , ecdh distinct standards (ansi x9.62 , x9.63, respectively), , used in distinct contexts. x9.63 explicitly reuses elements x9.62, including standard representation of public keys (e.g. in x.509 certificates). hence, ecdsa , ecdh key pairs largely interchangeable. whether given implementation permit such exchange, however, open question. historically, (ec)dsa , (ec)dh come distinct worlds.

note, though, usage contexts quite distinct. there bit more cryptography computations on elliptic curves; "key lifecycle" must taken account. in plain words, not want manage key agreement keys , signature keys same procedures. instance, if lose key agreement key (your dog eats smartcard -- not laugh, happens), can no longer decrypt data encrypted relatively key (e.g. encrypted emails sent you, , stored in encrypted format). business point of view, loss of key can loss of employee (the employee fired, , struck bus, or retired, or whatever). hence, encryption keys (including key agreement keys) must escrowed (for instance, copy of private key printed , stored in safe). on other hand, loss of signature key implies no data loss; issued signatures can still verified; recovering such loss simple creating new key pair. however, existence of escrow system tends automatically strip signatures of legal value attached them.

also, on more general basis, advise against using same private key in 2 distinct algorithms: interactions between algorithms have not been explored (simply studying 1 algorithm hard work). instance, happens if begins feed ecdh-based protocol curve points extracted ecdsa signatures computed same private key ?

so should not reuse same key ecdh , ecdsa.


Comments

Post a Comment

Popular posts from this blog

javascript - Enclosure Memory Copies -

-
function myclass() { //lots , lots of vars , code here. this.bar = function() { //do numerous enclosed myclass vars } this.foo = function() { alert('hello'); //don't enclosed variables. } } each instance of myclass gets own copy of bar , foo, why prototyped methods use less memory. however, know more memory use of inner methods. it seems obvious me (1) below must true. agree? not distinct myclass instances have own distinct copies of bar, must have own distinct copies of myclass enclosure. (or else how bar method keep myclass variables straight on per instance basis?) now (2) question i'm after. since inner foo method doesn't use in myclass enclosure natural qustion is: javascript smart enough not keep myclass enclosure in memory use of foo? this depend entirely on implementation not language. naive implementations keep far more around others. answer true e.g. v8 (chrome's js engine) may not true spider...
Read more

php - Replacing tags in braces, even nested tags, with regex -

-
example preg_replace('/\{[a-za-z.,\(\)0-9]+\}/', 'replaced', 'lorem ipsum dolor sit {tag1({tag2()})}, consectetur adipiscing elit.'); the result: lorem ipsum dolor sit {tag1(replaced)}, consectetur adipiscing elit. question as can see "tag2" has been replaced, want replace "tag1" know how can this? (in cases might this: {tag1({tag2({tag3()})})}) , on.) btw using preg_replace_callback, easier show preg_replace here site can test code: http://www.spaweditor.com/scripts/regex/index.php you need add curly braces character set. here's pattern used: /\{[a-za-z.,\(\)\{\}0-9]+\}/ and here result: "lorem ipsum dolor sit replaced, consectetur adipiscing elit."
Read more