2

What are the security implications of storing the keystore in a public repo, along with the source code?

The reason for storing it in the repo is convenience. There are no dependencies when you do a 'git pull or clone' and build on your local machine (for e.g. with sbt sign-release): you just provide the password when prompted and a signed application gets created.

Say I protect it with 20 character password (letters, numbers, special chars etc) obtained from a password-generating program. I think that it would be computationally infeasible for an attacker to mount an attack and get access to the private key in the keystore. I would like security/cryptography experts' opinion on whether it is safe to store keystore in a public repo.

Thanks

Babu Srinivasan
  • 2,339
  • 23
  • 24
  • @babu-srinivasan : It is feasible since there is limit on attempts after somebody downloads and does a offline attack. Anyway private keys are assigned to a particular entity (so that it can be used for Identity Authentication also) and you do not send ID/Access card by post (as i think). – yadab Oct 20 '10 at 09:48
  • I guess you meant "no limit on attempts". My point is that this is a randomly generated password and so only a brute force attack is possible. The attacker does not know the password length. So, even if the attacker can check a billion passwords in a second, it will take millions of years to find the password. Question is, are there non-brute force attacks for this problem. – Babu Srinivasan Oct 20 '10 at 17:27
  • @babu-srinivasan : yeah, i meant "no limit on attempts". thanks. But the password length may make task of getting from password to key very time-consuming for an attacker after that all is based on the key length, you can have AES-256. Now, it is not easy to break AES in brute force and which is very difficult. But in the process you are reducing the security of 1024 key length ( your RSA rpivate key) to 256 key strength (aes-256). Becuase a 256 key length is protecting 1024 length key?? Am I wrong? – yadab Oct 20 '10 at 17:57
  • yadab, you cannot compare 256 bit key of AES with 1024 bit key of RSA, and conclude that the former is weaker as 256 < 1024. This would be an apples to oranges comparison as AES is based on symmetric-key cryptography and RSA on public key cryptography. Public key cryptography depends on the fact that factoring large numbers is computationally infeasible. With current computing resources, to ensure that factoring is not feasible, the number has to be very large. In fact, 1024 bit keys used to be fine several years ago but now the recommendation is 2048. – Babu Srinivasan Oct 23 '10 at 19:01

2 Answers2

0

Hide keyring and Code belongs to "Security through Obscurity" Principals. In theory security should be far from this concept, but in that kind of scenario, the answer could be that exposing sensitive data on a public repository could expose you to attacks that work onto specific vulnerability of the keyrings or the implementation of the secure algorithm and so on.

I mean that all the algorithm you use sure are 100% secure and Keyrings too, but the version of keyrings could contain a specific vulnerability or bug or a bad implementation of the secure algorithm.

So exposing that data on a public repository could expose you to hacker who only want to prove their skill.

robob
  • 1,739
  • 4
  • 26
  • 44
  • 1
    robob, security thru obscurity doesn't apply here. It applies where you depend on the attacker not knowing what the crypto algo is. This is not the case here. The algorithm is well known. – Babu Srinivasan Oct 22 '10 at 16:05
  • I do not agree with you or with this restricted concept of "Sec through Obsc". I do not show you the plan for a military attack or I do not tell you where is the key, for me is "Sec Through Obsc" :-) – robob Oct 22 '10 at 16:17
  • Anyway the problem is another, the problem is that moving this keyrings to a public place could expose these data to a lot of attacks.. – robob Oct 22 '10 at 16:18
  • robob, I understand that by allowing the public to access the keystore, I am exposing the private key to offline attacks. My question was whether it was computationally feasible for the attacker to succeed. – Babu Srinivasan Oct 23 '10 at 20:49
  • No it's not feasible fro the attacker if you choos e what you said before. But it's very rare a brute force attack! Good Luck :-) – robob Oct 24 '10 at 06:41
0

I did some research. I found info on JKS algo in How does keytool protect keys? and JKS protection (http://metastatic.org/source/JKS.html).

Based on this I am answering my own question: I have come to the conclusion that with my 20 character randomly generated password, use of random salt of length 20 bytes and chained SHA1(password, salt) to get a random stream of length equal to key length of 2048, which is XORed with the private key, that it is computationally infeasible for the foreseeable future to extract the private key.

Community
  • 1
  • 1
Babu Srinivasan
  • 2,339
  • 23
  • 24