New answers tagged rsa
3
Before I answer your questions, here are a few principles that will make the answers easier to understand.
Keep network usage to a minimum. All transmissions are vulnerabilities. You are using the network to synchronize passwords between devices. All of the other functions should be performed locally on a cached database.
Sensitive data should stay ...
1
RSA and ECC are asymmetric encryption algorithms which are considered by experts to be the types of algorithms relatively easier to break by quantum than symmetric encryption standards.
For file encryption and storage you should therefore take a better look either at AES256 or Serpent. Both are symmetric.
two Quotes by the expert Daniel Bernstein:
"In ...
1
RSA and ECC are asymmetric encryption algorithms used for remote key exchange. Why would you encrypt your own local files with something that uses private and public keys? Probably you would use AES in this case.
0
In short: The ECB mode is very insecure, the CBC mode alone also in many cases, but it can be supplemented (MAC) and thus become secure.
About ECB mode: The plaintext is encrypted in blocks, whereby the blocks are independent of each other. As a result, identical plaintext blocks result in identical ciphertext blocks. So you can identify by the ciphertext ...
2
DESede/ECB/PKCS5Padding
DES is already broken and TDES is created to use until a new cipher is developed, called now AES.
The block size of DES or TDES is 64-bit and this is insecure, see Sweet32.
ECB mode for block ciphers, forget about it. It is not even a mode of operation. It reveals a pattern in your data. See the penguin on Wikipedia. In some case ...
0
I've managed to do it by using python-pkcs11 and asn1crypto
First, I've implemented a function that encode an RSA private key into PKCS#1 DER-encoded format, it gets the attributes (PRIVATE_EXPONENT, PRIME_1, PRIME_2 ...) from a given key.
Then, I retrieved the private key object and encoded it with previous function (i.e it extracted all the necessary ...
5
This is actually just the opposite; it is a rather in-secure way of handling messages. Repeat after me: "My server should never, ever, be able to read the contents of a 'secure' message." Because you encrypt everything to the server who then re-encrypts & sends it on to someone else, if there is ever a compromise of the server then the entire system is ...
3
Ok, let's look at your proposal:
each of the participants (the server and clients) has a key pair, and the private key is only known by its owner: good
all messages are encrypted with a random symmetric key, and that key is encrypted with the public key of the next hop: not bad. Possible caveats: the choice of the random key (hell lies in details...) - be ...
0
While it's recommended to use a key larger than 1024 bits, you could replace your encryption subkey with a larger one, keeping the same signing key (and by extent GPG identity). GPG keypair effectively consists of multiple separate keys (all signed with the same certification key, C in usage).
Note that this will make all data encrypted for the old key ...
Top 50 recent answers are included
