Tag Info

New answers tagged

3

Exact answer depends on the involved mode of operation, but most of them begin to exhibit unwanted structure when about 2n/2 blocks have been processed, when the underlying block cipher uses n-bit blocks. The fundamental reason for this is that a block cipher like AES is a permutation: any two distinct input blocks are encrypted into two distinct output ...


1

Ultimately, many of the vulnerabilities noted in these answers come from mixing levels of trust. But if you understand how wildcard certs work, you can mitigate these vulnerabilities for particular use cases. I think that explaining this in more detail will improve the usefulness of this question and its answers. Unless all of the systems in your domain ...


3

Due to the use of the Diffie-Hellman key exchange, knowing the server's private key does not help a passive-only attacker. If the attacker wants to learn the data, then he must go active. If the attacker knows the server private key, then he can impersonate the server, i.e. run a fake server and let users connect to it. For a full Man-in-the-Middle attack, ...


1

If the client initially starts a connection with the correct server, then no, the attacker can't do anything against that connection, but if the attacker can get the user to attach to them instead, then they can play the middle man and make a connection with the client and a separate connection with the server as long as client certificates are not being ...


0

My guess would be that the worst an attacker could perform is impersonating the server, leading users to log into his system instead of the legit one. This actually means that attacker can read traffic, acting as proxy. Question is: will key-based authentication have some positive effect for client Answers of that question covering that in some ...


1

This sounds like a good task for Shamir's Secret Sharing, as Stephen pointed out in comments. One example of off-the-shelf software that can do this is Crypto++ (relevant docs: http://www.cryptopp.com/docs/ref/class_secret_sharing.html).


0

GSM uses three different security algorithms - A3, A5, and A8. The A3 algorithm is used to authenticate the mobile device, the A5 algorithm to encrypt the data transmitted, and the A8 algorithm is used to generate the session key. Hence, I believe you are interested in the A8 algorithm which deviates the session keys through a challenge and response ...


1

It would take me (and anyone with HTTP proxy) exactly 2 minutes to defeat this kind of protective measure. The only effective protective measure for software is not to ship it to user. E.g. you can include only half of the functionality in the demo version. When user wants to upgrade to full version you take their money, give them one time link to download ...


0

There is a lot of misconceptions and myths about /dev/random or /dev/urandom. It's not true in general that using /dev/urandom is always good enough and that /dev/random is for paranoid only. The key here is the total amount of entropy collected during the lifespan of the instance before you start to generate numbers. That's what matters most. After ...


1

Assuming no other variables and parameters come into play than the ones that you have described, then YES your system is secure if and only if the method of hiding the secret is secure, i.e. it is not vulnerable to any ciphertext-only or chosen-ciphertext attacks. In both of these attack types, the knowledge of the key is not required. So for example if ...


0

The concept you are talking about is key rotation. Key rotation has pros and cons. While you are changing the key so it can't be found, this usually means you need to de-crypt and re-encrypt; that processes can now be attacked because there is a period where the data is now plaintext. The attack you describe would be basic brute forcing or targeted brute ...


1

The setup you described is not ideal. It would be better to implement a certificate authority and setup everyone with their own private-public keypairs. There are schemes where you would then grant access to a shared resource using ACLs at the application level or by having a symmetric key which is used for access and encrypted with each person's public key. ...


0

There is no way to distribute the key to everyone and at the same time being able to withdraw access to anybody of the team. Possible solutions for encryption: The sender encrypts to all members of your team, each having his private key. If you need to have a single key, have a central "decryption service" where all team members can put stuff to decrypt ...



Top 50 recent answers are included