Hot answers tagged

77

Without access to the key, then the problem for attackers is the same as if there was no backdoor key: the attackers would have to break the encryption itself. But ... If we assume that the private key of the base station is secure Your base assumption is the one that requires challenge. That there is a key is the problem. key handling key misuse key ...


71

Sure it's possible, but it doesn't really help. The number of possibilities is just too large. Consider that a 256-bit key has 2256 possible values. That's 12✕1076, or 12 followed by 76 zeroes. If we generously assume that a computer can test a trillion (that's 1012) possible keys a second, and that we have a trillion computers (where will we get them from?)...


41

As specified, the problem is completely impossible. You can not, and should not attempt to, make a program - much less a script - do something its user can't see. There are many ways the attacker could break this. They could just read and analyze your python scripts (even if compiled, .pyc is easy to decompile). They could debug the program as it runs. They ...


40

I did a calculation on this one once. Let's assume AES can only be broken using brute force. Clearly we are going to need a counter, which counts from 0 to 2256-1, and on average it will need to count to 2255. Running this counter takes energy. How much energy does it take? As it turns out, there is a thermodynamic limit here, Landauer's principle. At ...


32

Yes, it does mean that the key will be stored in the application’s memory. Yes, there is a risk that malware (with sufficient privilege) can read it from there. This risk is hard to avoid — if you want to use the key, you need to put it in memory, just as you need to put your house key in your pocket after you lock the door. This is usually not considered a ...


27

While I agree that every point of schroeder's response is true, there are two deeper issues that make it so much more dangerous than the current model of security. Right now, if you install an encryption key on a system, that key only controls your system and can only be accessed by the people you trust to access your system. Breaking into any system is ...


17

If there's a backdoor, it will be abused. The question is when, not if it will be abused. There are too many actors that could compromise such a system, and no easy way to plug the holes. If a private key leaks, it's done. It's cheaper to all involved to ignore the leak until there's a high profile case blowing to the press. Changing every key on every base ...


12

Public keys are intended to be published. The corresponding private key is the secure part that should not be published. The purpose of a public key is twofold: It is something anyone can use to encrypt a message that only the holder of the private key should be able to read (message encryption). It is something that can be used to verify a message sent by ...


10

Obviously, I need a way to encrypt they keys so they're not accessible to the user running the program Obviously, this is impossible. Keys are just data. Software is just data. Everything is just data, and if the data is in someone else’s computer, you cannot prevent them from accessing the data! (It is just like writing something on a piece of paper and ...


8

So, you're asking if you can store the API Key in the App, but also protect it from being stolen? This is not possible. There is a possible solution to make theft more difficult. Use OTP XOR encryption so that the API Key is split into two parts that must be combined. The first part is stored in your application. The second part is downloaded from your ...


8

Yes. In order for the public key to be valid (i.e. not just 32 random bytes), the point must be on the curve. You can test if the point is on the curve by plugging the x and y values into the equation of the curve, and solving the equation 'over the field', to see if the equation checks. For example, the equation for the secp256k1 curve is: y^2 = x^3 + ...


7

RSA is about the simplest known instance of asymmetric encryption. There are a few others, but all of them rely on mathematics. Symmetric encryption is easy (conceptually), because it is just about making a big knot with the data, and remembering how the knot was made; with that knowledge (that's the "key") you can untie the knot, basically by undoing all ...


7

No. Since in usual, theres single-direction communication with the car. So usually, each key has its own "encryption key" and a "counter". In the car, theres a list of valid encryption keys and a counter for each key. Each time you push a button, the key will send count + 1, encrypted with the key. The car simply encrypts count + 1 with its own encryption ...


7

I don't know anything about Dropbox in particular, but my understanding of API keys from other storage providers like Google Drive, Amazon S3, etc is that they allow users to log in either through their apps, or through 3rd party apps and they want to be able to track which is which. The quote in the question makes it sound like this is about privacy: ...


7

In theory, you could try to brute force the key and recover the data. In practice, that's extraordinarily unlikely to be successful as it would be expected to take a very, very long time. Per Wikipedia: AES permits the use of 256-bit keys. Breaking a symmetric 256-bit key by brute force requires 2128 times more computational power than a 128-bit key. ...


6

I answered a similar question here. For a normal hardware solution, a hardware security module (HSM) does this. For software, .NET offers the Secure String mechanism to encrypt and protect sensitive data in RAM. Other platforms may offer something similar. For an AWS solution, Amazon offers CloudHSM to do pretty much what you are asking for, I think. ...


6

For RSA there are special requirements on how to formulate a key. Primarily (pun not intended) you need the p and q values, which are large primes. There are, however, schemes (see here and here) which can be used to deterministically generate asymmetric key material from a passphrase. The easiest way to achieve such a goal is to take a known-secure PRNG ...


6

What are the chances that the key is the very last key for the brute force attack to check? If there are N keys, the chance is 1/N. If you have n bits of entropy, that means the chance is 2-n. ...if it's one of the keys in the first 10% of all keys to be checked by the brute force attack? Given that the key is random, the chance of a brute force search ...


6

An HMAC is a very simple construction. You could have come up with it yourself, except that HMAC is standardised which means that a lot of people looked at it and found it to be resistant against attacks. Because of the simplicity, we can just dive into the details: hmac = hash( (key xor opad) + hash((key xor ipad) xor message) ) So it's just some ...


6

No. You do not need to add a salt to an API key's hash. The API key should have been created from a high entropy random source, capable of resisting attacks that attempt to guess future keys based on past keys. Most passwords are created from very low entropy sources: Users. Additionally, most passwords will also be reused, so there's value in pre-...


6

This question is both too broad and too narrow, but I'll see what I can do. Your understanding about AES block and key sizes is correct. Usually, yes, you'd want to use a cryptographically secure (P)RNG to generate encryption keys (for any cipher, AES included). However, there are times when this isn't practical, such as when a human needs to be able to ...


5

The reason for key strengthening is that passwords don't have as much entropy as is expected for the key. The time it takes to break a key is proportional to the number of possible keys. Strengthening algorithms used on passwords compensate for the poor entropy by increasing the proportionality constant. But the gap is so large that strengthening cannot ...


5

The first question is, for the love of $DEITY, why are you using password encryption? Passwords should be passed through a secure and slow key derivation function, something like PBKDF2 or scrypt, and should never be stored reversibly encrypted. Using reversibly encrypted passwords is already insecure! Actually, the zeroth question is, why are you ...


5

Put simply, there is no bulletproof way of concealing a string if it is being made available on the client-side. Maybe instead of giving the user access to the API key, make the client contact your own server and perform API requests from there, if you do this then you will be able to limit unauthorised use of your API key.


5

The whole point of your public key is that you can share it with anyone. It doesn't matter if someone gets it, it doesn't matter if it's on your machine. It isn't a target for attackers so it would be of no value to anyone in having it on your machine. It does have a benefit in keeping it: you can then easily share it. (Yes, I know there is a possible ...


5

Using AES and 4096 bit RSA would certainly help. At least openssl uses 3 key triple DES but that means both the triple DES and the RSA private key are stuck at a security strength of 112 bits. See https://keylength.com for information on key strengths. 112 bit is just enough but a bit too close for comfort; I'd sleep better with 128 bit security. openssl ...


5

You might want to take a look at the RFC 2104: Definition of HMAC The definition of HMAC requires a cryptographic hash function, which we denote by H, and a secret key K. We assume H to be a cryptographic hash function where data is hashed by iterating a basic compression function on blocks of data. We denote by B the byte-length of such blocks (B=64 for ...


5

LUKS does not support requiring both a keyfile and a passphrase to decrypt. The encrypted volume can be decrypted as long as you provide satisfactory credentials to any one of the configured keyslots. That's not to say that it's impossible to get what you want. You could use a detached LUKS header (where the encrypted master key and other key information is ...


5

tl/dr: A JWT is simply not the correct solution for a server-to-server API token/key. API keys need to be revokable in the case the user needs to change it (for whatever reason), and JWTs by their nature cannot be revoked. You need a completely different solution for server-to-server authentication. I'm going to answer with a frame-challenge. You are ...


5

It is common that a certificate gets revoked if the private key is known to be compromised. Publishing the private key so that it is known publicly is obviously compromise of the secrecy of the private key.


Only top voted, non community-wiki answers of a minimum length are eligible