New answers tagged aes
0
Yes it uses 256 bit AES encryption.
With the help of Commander One, you can encrypt your personal data
stored on any of your online connections, protecting it from any
unwanted access. When this feature is enabled, Commander One uses the
Advanced Encryption Standard (AES) with a 256-bit key length to
translate data into a different form, so that ...
0
What are you trying to achieve here? Utilize a user's password for (1) authentication/login as well as a (2) key to encrypt their data? If so, then consider what password managers typically do - I see as bearing similarities with what you're proposing. Here are the operations cannibalized from an answer to a different question:
client_rounds = 5000 // ...
0
Your basic understanding is fundamentally correct:
You have a media file or a media stream, which is encrypted with a symmetric key (almost always an AES-128 variant).
Users who want to play back that stream need to obtain a copy of that key but, just as crucially, need to have a piece of trusted software and trusted hardware. An example of that is the CDM ...
1
(Disclaimer: My POV can be slightly biased by the protection I tried to crack, I sometime speak about stuff I don't know, I presume it work this way because I know similar DRM tools working like that)
Conor is right: Speaking about DRM in general is far too broad: You speak about a server in your question but one of the most used copyright content doesn't ...
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 ...
2
If the above is the case, I assume that an attacker could simply edit the binary for the CDM to access the key or the file after is decrypted.
That's why a lot of DRM systems are not implemented on Linux systems ...
To be able to run a DRM, the player must be "certified" by the DRM provider and must provide some secure way for this set key/decryption ...
1
Finally, five years later, some well-known cryptographers have developed the tool: https://age-encryption.org/
It uses chacha20-poly1305, works with scrypt KDF or elliptic curve keys.
9
1) password hashing iterations
If you don't care about waiting a little longer, you can use the maximum count value, which is 65011712. This isn't strictly the number of iterations so much as the number of bytes to be hashed. S2K works by repeatedly feeding the password and salt to a hash function for a specific number of bytes. The more bytes, the longer ...
0
@steffen-ullrich, your advice was helpful!
I decode my sample traffic as some protocols in wireshark (because there was non-standard ports on traffic) and finally i found 'ServerHello message' and all information i needed!
2
These modules communicate with SSL (PSK) ...
If these modules use SSL the encryption algorithm (AES, ...) and key length are encoded in the cipher used. Which cipher is used can be seen from the TLS handshake, notably the ServerHello message send by the server.
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 ...
Top 50 recent answers are included
