Public Key Cryptography

[JPage]

I've got a crypto problem.  I need an asym key pair having a very short length.  Is it possible to make a public key and private key where the key length is 6 - 10 characters?  The level of security is pretty low so no worry about brute force attacks.  Where can I read more about asym key algorithms?

[defcon23]

this is a good point of start tor learn asymmetric cryptography :


http://searchsecurity.techtarget.com/definition/asymmetric-cryptography

&

http://crypto.stackexchange.com/questions/1662/how-can-one-securely-generate-an-asymmetric-key-pair-from-a-short-passphrase

Cheers ! 

[tspacepilot]

this is a good point of start tor learn asymmetric cryptography :


http://searchsecurity.techtarget.com/definition/asymmetric-cryptography

&

http://crypto.stackexchange.com/questions/1662/how-can-one-securely-generate-an-asymmetric-key-pair-from-a-short-passphrase

Cheers ! 

Not sure if the OP is asking to generate a keypair from a short passphrase as seed or if they actually want a very short length for their keys.  The latter seems to be what they actually said but the former is more sane, I think.  I suppose that it's possible in theory to do the latter just for learning purposes but clearly you wouldn't want to put anything valuable behind a 6 character key.

[JPage]

Not sure if the OP is asking to generate a keypair from a short passphrase as seed or if they actually want a very short length for their keys.  The latter seems to be what they actually said but the former is more sane, I think.  I suppose that it's possible in theory to do the latter just for learning purposes but clearly you wouldn't want to put anything valuable behind a 6 character key.

Correct.  I want a key pair which looks like this: public key hent54; private key: jrhfy75894
Very short.  Even shorter than that if possible.  I am not putting money behind this.  I am only putting some very unimportant information which is preferably kept undiscoverable - but if it gets hacked, no big deal.  VERY lightweight encryption.  So the question is, what is the practical lower limit on key pair size (length) in Asym Cryptography schemes?

[gmaxwell]

You haven't said what you wanted to do with it.  Bitcoin's system can already accommodate this, just truncate the public key hash further.  ... or did you want encryption? or something else?

[fbueller]

Bleh. What's your use case? Bitcoin uses strong crypto because it's money. But you should still use strong crypto for customer data. What are you trying (not so hard) to protect?

There is this (false) concept called security by obscurity, and it sounds like what you're aiming for here. If someone knows what algorithm you're using, they could easily brute-force these keys. Protected anything of value with it, and you'll get rainbow tables of priv => public keys get published pretty quickly, meaning everyone already has a copy of all possible private/public keys. You can buy 2TB hard disks which have all the possible encryption keys for GSM - which is stronger than what you're suggesting here.

And perhaps you'd suggest keeping the algorithm secret. That doesn't work for crypto - everything about a strong cryptosystem can be known besides the private key in order for data to be secure.

Why even bother with cryptography if you don't care if the data is exposed?

[tspacepilot]

Bleh. What's your use case? Bitcoin uses strong crypto because it's money. But you should still use strong crypto for customer data. What are you trying (not so hard) to protect?

There is this (false) concept called security by obscurity, and it sounds like what you're aiming for here. If someone knows what algorithm you're using, they could easily brute-force these keys. Protected anything of value with it, and you'll get rainbow tables of priv => public keys get published pretty quickly, meaning everyone already has a copy of all possible private/public keys. You can buy 2TB hard disks which have all the possible encryption keys for GSM - which is stronger than what you're suggesting here.

And perhaps you'd suggest keeping the algorithm secret. That doesn't work for crypto - everything about a strong cryptosystem can be known besides the private key in order for data to be secure.

Why even bother with cryptography if you don't care if the data is exposed?

One use case which I think would be valuable would be simply for teaching purposes.  If you could find a public-private key pair just to illustrate the old "alice wants to talk to bob" scenario with very small numbers, that would help simpletons like me to understand the concepts better (perhaps).

[fungus]

Bleh. What's your use case? Bitcoin uses strong crypto because it's money. But you should still use strong crypto for customer data. What are you trying (not so hard) to protect?

There is this (false) concept called security by obscurity, and it sounds like what you're aiming for here. If someone knows what algorithm you're using, they could easily brute-force these keys. Protected anything of value with it, and you'll get rainbow tables of priv => public keys get published pretty quickly, meaning everyone already has a copy of all possible private/public keys. You can buy 2TB hard disks which have all the possible encryption keys for GSM - which is stronger than what you're suggesting here.

And perhaps you'd suggest keeping the algorithm secret. That doesn't work for crypto - everything about a strong cryptosystem can be known besides the private key in order for data to be secure.

Why even bother with cryptography if you don't care if the data is exposed?

One use case which I think would be valuable would be simply for teaching purposes.  If you could find a public-private key pair just to illustrate the old "alice wants to talk to bob" scenario with very small numbers, that would help simpletons like me to understand the concepts better (perhaps).

I was taught that keys are based on extremely big prime numbers so using small ones that are easy to break should be ideal for teaching purposes.

[tspacepilot]

Bleh. What's your use case? Bitcoin uses strong crypto because it's money. But you should still use strong crypto for customer data. What are you trying (not so hard) to protect?

There is this (false) concept called security by obscurity, and it sounds like what you're aiming for here. If someone knows what algorithm you're using, they could easily brute-force these keys. Protected anything of value with it, and you'll get rainbow tables of priv => public keys get published pretty quickly, meaning everyone already has a copy of all possible private/public keys. You can buy 2TB hard disks which have all the possible encryption keys for GSM - which is stronger than what you're suggesting here.

And perhaps you'd suggest keeping the algorithm secret. That doesn't work for crypto - everything about a strong cryptosystem can be known besides the private key in order for data to be secure.

Why even bother with cryptography if you don't care if the data is exposed?

One use case which I think would be valuable would be simply for teaching purposes.  If you could find a public-private key pair just to illustrate the old "alice wants to talk to bob" scenario with very small numbers, that would help simpletons like me to understand the concepts better (perhaps).

I was taught that keys are based on extremely big prime numbers so using small ones that are easy to break should be ideal for teaching purposes.

Right, or points on a curve in the case of bitcoin.  I'm not also interested in the OPs question just for my own education, what are the smallest numbers x,y that I can use as a public, private key pair just to run the encryption/signature/verification algorithms by hand.  Fungus, your point about seing how easy that'd be to crack is also valid.

[RawDog]

Bleh. What's your use case? Bitcoin uses strong crypto because it's money. But you should still use strong crypto for customer data. What are you trying (not so hard) to protect?

There is this (false) concept called security by obscurity, and it sounds like what you're aiming for here. If someone knows what algorithm you're using, they could easily brute-force these keys. Protected anything of value with it, and you'll get rainbow tables of priv => public keys get published pretty quickly, meaning everyone already has a copy of all possible private/public keys. You can buy 2TB hard disks which have all the possible encryption keys for GSM - which is stronger than what you're suggesting here.

And perhaps you'd suggest keeping the algorithm secret. That doesn't work for crypto - everything about a strong cryptosystem can be known besides the private key in order for data to be secure.

Why even bother with cryptography if you don't care if the data is exposed?

One use case which I think would be valuable would be simply for teaching purposes.  If you could find a public-private key pair just to illustrate the old "alice wants to talk to bob" scenario with very small numbers, that would help simpletons like me to understand the concepts better (perhaps).

The actual use case is this: Bob is an adolescent male who wants to tell Charlie (who incidentally is now in jail) that he fucked Alice.  But he doesn't want anyone else to know.  So, he puts this info in an OP_Return output with some light encryption to prevent all but determined snoops from knowing as Alice isn't very good looking and it would be bad for his reputation.