Obfuscation of private key

[Inca]

Some services need to keep and generate private keys online. I was thinking about obfuscation today.

I was daydreaming about generating an array of ECDSA key pairs and then randomly symmetrically encrypting them together into a chain. Keypair n=1 contains the address for funds.

The chain would be: keypair (n=1) private key encrypted with public key from keypair (n=2). Keypair (n=1) public and private keys deleted. Then keypair (n=2) encrypted with public key from keypair (n=3) etc..eventually ending up with a sequence of encrypted private keys and finally a private key of the last keypair which for fun could be encrypted with any of the other keys.

Of course not all keypairs in the array need to be used so the length and order of the chain is unknown.

Now if the order of the sequence is known the private key that holds the funds can be easily accessed, especially if the sequence is stored off site say hidden in the block chain.

I am curious if some maths whiz can tell me by an increasing n, how many combinations a would be attacker would need to try, if they had complete access to the site but not the sequence.

How many would be needed to stop an attacker for one block confirmation?

 

[Inca]

So reading about calculation of number of combinations or what I was wondering permutations (sequence without repetition of a member of the set) yields the following.

Assuming key generation of 256 ECDSA keypairs (probably massive overkill) with a chain of encrypted private key (length n) yields the following number of permutations (ball park)

n=2 >65,000
n=3 >16,500,000
n=4 >4,195,000,000
n=6 > 10 ^14
n=10 10 ^24
n=20 10 ^47

20 bytes should fit that in.

Of course 20 bytes on its own has 2^160 possible numbers within it..

 

[theZerg]

Modern crypto says that the algorithm should be public so that it can be carefully analyzed for weakness. However, there's no doubt that breaking a cypher is harder if both the key and algorithm is unknown.

The problem with making a small modification to SHA256 (or whatever) though is that unless you are an expert cryptographer (even IF you are one in many cases) you can't be sure you didn't just make it easier to crack.

But it seems like your approach is a clever way to avoid this issue since you are not modifying the cypher but rather compositing them in a way that is structurally (index in an array) not mathematically related. That last part is important. At some point the operations wrap around and start undoing themselves. For example, I read that the optimum # of times to perfectly shuffle a deck of cards is 14. After that, you actually start unshuffling them...