2

I'm making a new mail protocol (probably already exists, but I've learnt a lot of things about security and privacy on the way).

Here's the summary(much simpler if you know bitcoin's inner workings):

  • Every user has a list of public and private keys.
  • Every mail is in a file that every node has a copy of.
  • users can send messages using the following protocol:
    • message = encrypt("Your message here", receiver.publicKey);
    • signature = sign(message, sender.privateKey);
    • proofOfWork = hashcashAlg(message); see: hashcash
  • When sending a new mail, you send your public key, receiver's public key, message, signature and proofOfWork to all nodes known to you. Every node then sends that mail on to all nodes they know.

Now I've got this problem: public keys (currently RSA) are extremely long. When you would want to send a mail to someone, you would need to know their public key.

Are there any asymmetric encryption algorithms that use smaller public keys? Or some way I can put the long RSA key through a RIPEMD160 and it still being usable?

Improve this question
9
  • 5
    You may want to look at bitmessage: bitmessage.org/bitmessage.pdf
    – Marcel
    Commented Mar 25, 2014 at 11:17
  • 2
    Here is a Podcast about bitmessage by Steve Gibson from GRC: grc.com/sn/sn-420.pdf
    – Marcel
    Commented Mar 25, 2014 at 11:18
  • Oh man that is exactly what I had in mind :( I do have an algorithm for nodes to be completely anonymous though, I wonder if they have it.
    – user1009013
    Commented Mar 25, 2014 at 11:19
  • It seems from their webpage that they can use a helping hand, and there is also room for improvement according to the podcast. So, you may offer your thought to them.
    – Marcel
    Commented Mar 25, 2014 at 11:22
  • The key data is the least of your worries. The number of files this system will maintain (apparently indefinitely) will grow in N*M fashion. Every node will be given every e-mail ever sent by anyone, and be expected to keep that file for some relatively long time. 10 users, whose computers are nodes in the web of trust, who each send an e-mail to all users (including themselves; what, you've never e-mailed yourself?), will result in 100 files stored on each user's computer, only 1/10 of which the user can actually do anything with. A web of hundreds or thousands would be unworkable.
    – KeithS
    Commented Jul 23, 2014 at 19:07

1 Answer 1

Reset to default
1

Now I've got this problem: public keys (currently RSA) are extremely long. When you would want to send a mail to someone, you would need to know their public key.

Are there any asymmetric encryption algorithms that use smaller public keys? Or some way I can put the long RSA key through a RIPEMD160 and it still being usable?

This is a known problem with conventional public key crypto systems, e.g. RSA and DH and among other things one reason why Elliptic Curve Cryptography (ECC) is so appealing. Usual key sizes range from something between 160 to 512 bit, while providing the same level of security.

Another potential way to solve the problem is a scheme similar to the one implemented in DNSSEC. Here you have two key pairs, which are different in length. The shorter one has to be replaced more often (once per month or so), but is the one that actually is doing all of the signatures. Personally I don't like this approach very much, but it was specifically designed in this way to make signatures shorter.

Improve this answer
4
  • I guess the key size of 160 would work good enough. I'll maybe try that. But I'm first going to try and talk to the bitmessage guys and see if I can't help them.
    – user1009013
    Commented Mar 26, 2014 at 9:56
  • Could you give an example of a 160-bit public key encryption algorithm that I can use in Java? KeyPairGenerator.getInstance only makes 1024-bit keys, or am I looking at the wrong numbers?
    – user1009013
    Commented Mar 26, 2014 at 16:39
  • ECC strength is rated at half the bitsize, i.e. 160bit curve has strength 80 which has little safety margin. You shouldn't use anything less than 224 or maybe 192, and P-256 seems to be most widely implemented. Sun^WOracle Java beginning with v7 has a provider SunECC with ECDSA and ECDH, but not ECIES. A 3rd-party like BouncyCastle may have more. Bitcoin does use ECDSA secp256k1 if that influences you. ...
    – dave_thompson_085
    Commented Jun 24, 2014 at 11:07
  • Java through v7 KeyPairGenerator for DSA and DH(!) is limited to max 1024-bit group; this is listed as fixed in v8. But the strength of DSA/DH and RSA is much less, and not linear; DSA/DH or RSA 1024 have strength about 80, which is why they are no longer approved by NIST and CABforum among others beginning this year; see crypto.stackexchange.com/questions/10076/why-is-the-complexity-of-rsa-1024-80-bit-and-not-86-bit
    – dave_thompson_085
    Commented Jun 24, 2014 at 11:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .