New answers tagged

2

I am trying to create a secured policy for storing and maintaining keys between users of my company. The following answer is based on those requirements I assume based on your post (I'll call your users employees in the following): You need to be able to revoke employee keys. You want to be able to decrypt information encrypted for employee. Employees ...


0

After the public key has been imported pgp --import PublicKeyToImport.asc run pgp --list-userids to determine the key or User ID to be used with --encrypt. Alg Type Size/Type Flags Key ID User ID ---- ---- --------- ------- ---------- -------


1

I should not be distributing a 128-bit AES keys with a 56-bit DES key. Why? If you think about this, it is trivially obvious: anyone can obtain the 128 bit key by brute forcing the 56 bit key that you distribute it under. The performance of your security is defined by the weakest point in the system.


0

Generally, in terms of security, reusing passwords is not a good idea. Mind that the revocation is not the only problem if you get compromised. An attacker with access to your previously encrypted messages, by having the key and password, is gonna be able to decrypt them. So, having different passwords makes the attacker's job harder. Also, making this ...


2

There is a reason for encrypting the data where its stored - that being the storage may be compromised (directly or from a backup copy). If we agree that maintaining the data in an encrypted form is a good idea, then access to the decryption key must be restricted. You didn't specify if the encryption was symmetric or asymmetric. In the case of the former, ...


1

Since the communication between web and app servers are secured through SSL/TLS, the data's already being encrypted in transit by the session key - so I think your two options are very similar. There might be a slight advantage for encrypting for the application server's HSM key right off the bat so that the data's plaintext is never on the application ...


0

There are some annoying realities about storing anything on a public cloud. The only safe way to decrypt/encrypt anything is on the local client itself, and all the issues of handling private keys locally - phone theft, key theft, etc. Using the public cloud means you have to trust that, on a multi tenant system, the other tenants are not able to scrape in ...


4

As @schroeder recommended, you should share the key between applications/servers using Public Key Infrastructure (PKI). It's not recommended that you implement this yourself. There is a great article called Choosing the Right Cryptography Library for Your PHP Project. This is worth taking a look at. It recommends the following libraries: Halite Libsodium ...


2

I think you're using non standard terminologies and that is making things confusing for you. I'll define the terms here: Private key: a string that need to be kept secret, used in cryptographic operations to authenticate or encrypt Public key: a string that are mathematically bound to the private key, not a secret. Used in certificate to decrypt and ...


-3

All the cert and keys you are presenting are necessary information for a working openvpn service for the client side. It is nothing wrong to give them in public. The only security weakness is the username:password (if it is weak) and your IP (ddos attacks).


0

The actual meaning of that is how many bits will constitute the desired key to proceed with the encryption or decryption algorithms. Suppose the key size is 256 bits meaning that, if you take an integer which is grater than the 2^255 and lower than 2^256. In between the integer you have to take it as a public or private key.


0

You don't really describe this step very well: If user login credentials are confirmed, a symmetrical AES-128 key is generated from their unencrypted password and their unique salt and attached to their session to decrypt the credentials of the third party accounts stored in the database. Exactly how is that 128-bit key created? That should be a very ...


0

The main benefit of separate keys is what happens in the worst-case scenario: someone gets your private key. SAME key on all hosts: The bad guys now have access to everything. DIFFERENT key on each host: The bad guys only have access to one thing. So--most secure? Unique keys for each host.


2

The client or the server may request a renegotiation at any time. That renegotiation would include a new shared secret. The Server can send a Hello Request to trigger renegotiation (emphasis mine): The HelloRequest message MAY be sent by the server at any time. Meaning of this message: HelloRequest is a simple notification that the client ...


0

Between a single client and server, the "shared secret" (mastersecret) will have last for the session. Session Resumption may be allowed via Session IDs as described in RFC5247 and RFC4346 or Transport Layer Security (TLS) Session Resumption without Server-Side State is described in RFC 5077 allows The ticket lifetime may be longer than the 24-hour lifetime ...


1

Fundamentally, to trust a computer, you need to verify that it knows something that only the computer you're expecting knows. This is how all certificates work: you assume that because they signed something with a key that only they could possibly know then it's actually the person you wanted to talk to. The same applies for computers: the computer has to ...



Top 50 recent answers are included