I've been looking around for an article describing these modes in layman's terms but have not yet found anything helpful. So, what are the positives and negatives of each mode?
Thanks
GCM
CCM
CBC-MAC
CCM-
this mode accepts a variable-length authentication tags from 32-bits to 128-bits so it actually allowing varying degrees of protection against unauthorized modifications the cons:
The CCM mode dose not provide for confidentiality-only services. in some cases, it
uses data authenticity mechanism from external.
GCM-
The encryption and authentication of GCM are secure against the chosen-plaintext attack, and GCM is also secure while using the AES block cipher. but:
There are security problems when reusing the IV
For both GCM and CCM you have to use timestamps or replay attack can occur and of course you need an appropriate tag length.
for CBC-MAC it depends because you use CBC to create the MAC and CBC offers serial encryption and parallel decryption but a change of one bit in a block changes everything that comes after in the encryption but doesn't affect the decryption. A known problem with CBC-MAC is using the same key for encryption and for authentication in this case if you use CBC mode so the last block would be the MAC.
just for the smile - Cryptography
*here is the place to mention that one of the sources I used is from a german university research.
**EDIT:**found the name of it: ruhr-universität-bochum.
Related
This question is about video streaming using MPEG-DASH and/or HLS. I am trying to understand the value added by commercial DRM systems (such as EZDRM, BuyDRM, etc.) compared to simple encrypted streaming e.g. AES-128 encrypted HLS. I am a bit lost in the commercial slogans.
So if I have a live or VOD stream I can easily send the stream encrypted with AES-128 if I use HLS "for free". It seems to me that when I set up a paid DRM for my MPEG-DASH streaming, basically the same thing happens, the stream gets encrypted and the details are shared in a standardized way (CENC).
So in both cases on the player side all I need is the key for decryption. It should not be a big deal to fetch that key from any webservice separately. Is that all..?
Based on this it would be very simple to implement some custom key provider service, but apparently the market is owned by big providers, so I must be missing some important aspect here.
(To clarify: I am not talking about everything within DRM, just the case when I have some live or vod videos and a website to offer these)
Any help and good comprehensive article links are appreciated.
It's a valid point. But there are quite a few differences, albeit not entirely obvious at first glance:
"Real" DRM systems don't just deliver a content decryption key as AES-128 HLS does. They deliver what is usually called licenses, which in turn also contain a set of usage rights, such as for example an expiry date (useful for rentals), or the ability to play through HDMI, or a constraint on the max resolution you're allowed to watch, and more.
Real DRM systems typically allow offline storage of licenses, which is useful in those scenarios where playback can also happen offline, or those online cases where you have to maintain state (such as rentals, if for example you play the movie in separate watching sessions).
Real DRM systems require individualization, meaning that the local license database is cryptographically bound to the device on which it was created. This is to prevent situations where user A obtains legally a valid usage license for content X, and then trivially posts the license database on BitTorrent for everyone to use. User A can do that, but the database is unusable for everyone else.
Real DRM systems allow revocation, meaning that -- since each device has a cryptographically unique identity -- if a device (or, more likely, a class thereof) is detected to be rogue, then it can be earmarked as unable to obtain future licenses.
Licenses are signed, meaning that one cannot tamper with one while in transit over HTTP, in order perhaps to extend his rental period or to allow HDMI playback where it was not originally allowed.
And there is more... Also, the above is what most commercial DRM systems have in common, but if you look at individual ones (PlayReady, Widevine, FairPlay, ...) you'll see they also have several individual characteristics that differentiate them from one another and from plain AES-128 HLS.
I can't really better #Guido Domenici answer, but the difference between AES-128 encryption and DRM is immense.
The most obvious example can be seen in the simplicity of ripping off an HLS AES-128 key. The User-agent (browser or app) has to fetch the key to decrypt the content. This is often given in the EXT-X-KEY HLS "header". A simple tcpdump or MiTM SSL proxy (with the certs trusted by the OS) can reveal the key in seconds. It's really no-more than an inconvenience.
In generic terms, with most modern DRMs, a secure plugin or low-level kernel module is responsible for raising a "Challenge Request", containing an identifier for the device, the content id and often a user token. The Challenge is passed, often via an event hook in the application, to the license server that will evaluate the request and on success, issue the decryption key in a signed and encrypted payload. The plugin or kernel module will receive the response and will decrypt the video/audio, passing the media back to the application.
Some DRM solutions also prevent screen recorders.
Another benefit of some DRMs, is that content is rarely completed encrypted and instead employs partial or sample encryption - enough to render the video and audio unplayable. This reduces the overhead required for decryption.
To complete the great answers bellow, DRM is right solution if you want to prevent manipulation on the device playing your video. For instance, if you video is been playing in a browser, it is possible to stole it (think about all download video extension for chrome) DRM prevent this.
For securing NFS (Network File System), the mount option krb5p can be used to encrypt all traffic between the file server and the NFS client. Authentication and key exchange is based on Kerberos.
Here is an example on how to configure that for Debian: https://wiki.debian.org/NFS/Kerberos
Unfortunately, there seems to be no way to configure the cipher used for this transport enryption. What cipher is used and how can this be configured, selected, or enforced?
Without having used NFSv4 with Kerberos but used it in many other places, you are referring to confidentiality provided by the GSS-API through Kerberos which is implemented with gss_wrap(3)/gss_unwrap(3). It provides a quality of protection parameter but I am quite certain that NFSv4 will leave it null => at discretion of the mechanism.
Anyway, given that GSS-API completely abstracts from the mechanism, you probably have no choice but you still can do something about it. Enable in your KDC at least RC4, at best AES128 and AES256. Implementations will use best available cipher. You can scan traffic between the client and TGS (TGS-REQ and TGS-REP), client and server (NFS) to see which encryption type has been negotiated and this will highly be used for wrapping/unwrapping. You can always read the RFCs as I did but this will take a lot of time to understand.
Hope this helps. Of course, I could be completely wrong about NFSv4 internals.
Just made some digging and I am quite certain now that my analysis is correct. RFC 7530, chapter 3.2.1 talks about Kerberos 5 mandatory privacy for krb5p as well as AES along with HMAC-SHA1. Further reading leads to the RFC 2203 (RPCSEC_GSS spec) which talks about gss_wrap/gss_unwrap.
Some (especially bank) password systems require you to enter three (specified) letters out of your password to log in.
This is supposed to defeat keyloggers, and possibly wire-sniffing replay attacks (for unencrypted sessions).
Clearly, there's no way such a scheme can work using ordinary password hashing, since you'd need to know the whole password to compute the hash.
What do such systems commonly store server-side to make this work?
Do they store the password in plaintext, or maybe a separate hash of each letter, or what?
As you correctly note, standard password hashing schemes won't work if authentication is done using only a substring of the password. There are a number of ways that such a system could be implemented:
Store the password in plain:
Simple and easy to implement.
Insecure if the database is compromised.
May not comply with regulations requiring hashed or encrypted password storage (but using low-level database encryption might get around that).
Store the password encrypted, decrypt to check:
No more secure than storing it in plain if the encryption key is also compromised.
May satisfy regulations forbidding password storage in plain.
Could be made more secure by using a dedicated hardware security module or a separate authentication server, which would store the key and provide a black-box interface for encryption and substring verification.
Store hashes of all (or sufficiently many) possible substrings:
Needs much more storage space than other solutions.
Password can still be recovered fairly easily by brute force if the database is compromised, since each substring can be attacked separately.
Use k-out-of-n threshold secret sharing:
Needs less space than storing multiple hashes, but more than storing the password in plain or using reversible encryption.
No need to decrypt the password for substring verification.
Still susceptible to brute force attack if database is compromised: anyone who can guess k letters of the password can recover the rest. (In fact, with some implementations, k-1 letters might be enough.)
Ultimately, all of these schemes suffer from weakness against brute force attacks if the database is compromised. The fundamental reason for this is that there just isn't very much entropy in a three-letter substring of a typical password (or, indeed, of even a particularly strong one), so it won't take many guesses to crack.
Which of these is best? That's hard to say. If I had to choose one of these schemes, I'd probably go for encrypted storage using strong symmetric encryption (such as AES), with a separate server or HSM to handle encryption and verification. That way, at least, an attacker compromising a front-end server wouldn't be able to just copy the database and attack it offline (although they could still mount a brute force attack on the HSM if it didn't implement effective rate limiting).
However, I'd say that the whole idea of using only part of the password for authentication is deeply flawed: it doesn't really deliver the security benefits it's supposed to, except in a few particularly constrained attack scenarios (such as an eavesdropper that can only observe one authentication event, and cannot just keep trying until they get the same challenge), yet it fundamentally weakens security by reducing the amount of information needed for successful authentication. There are much better solutions, such as TANs, to the security concerns that partial password authentication is supposed to address.
I am considerung to use zeromq as messaging layer between my applications. At least in some cases I want the communication to be secure and I am thinking about SSL.
Is there some standard way how to ssl-enable zeromq? As far as I understand it doesn't support it out of the box.
It would be nice if I just had a parameter when connnecting to a socket (bool: useSsl) :)
Any ideas?
Understanding that this is not really an answer to your question, I'm going to be encrypting the messages directly with RSA, before sending them with 0mq.
In the absence of a more integrated encryption method that is fully tested and implemented in my platform of choice, that's what I'm going with. 0mq just recently released version 4, which has encryption baked in, but it's still considered experimental and isn't fully supported by the language bindings.
Encrypting the message, rather than the connection, seems to provide the simplest upgrade path, and the difference for our purposes are pretty much just semantics given how we'd have to implement encryption currently, today.
Edit: I know more about encryption now than I did when I wrote this, RSA is not an appropriate choice for encrypting message data. Use AES, either with manually sharing keys (this is our approach for the short term) or implementing a key sharing scheme as in Jim Miller's answer... but beware if you take the latter approach, designing and implementing a key-sharing scheme securely is hard. Way harder than you'd think. You can implement SSL/TLS directly (using message BIOs), and others have done so, it's also not simple but at least know that the SSL scheme is industry standard and therefore meets a minimum security requirement.
In short, before the Elliptic Curve crypto baked into ZMQ 4 is considered reliable and becomes standard, the "accepted solution" would be to implement SSL/TLS over the connection manually, and failing that, use AES 128 or 256 with a secure key sharing mechanism (key sharing is where RSA would appropriately be used).
We are currently implementing a pre-shared key solution using 0mq that implements a key exchange protocol based loosely on TLS/SSL.
Essentially, we have a data aggregator service that publishes encrypted state of health data over a multicast 0mq publisher. A symmetric key is used (AES128) to encrypt the data and can be retrieved from a second service running as a simpler request/response model over 0mq.
To retrieve the symmetric key (PSK), we are implementing the following protocol:
Client connects
Server sends its certificate
Client verifies server certificate against a CA chain of trust
Client sends its certificate
Server verifies client certificate against its CA chain
Server encrypts PSK using client public key
Server sends encrypted PSK to client
Client decrypts PSK
Once a client has the PSK, it can decrypt the messages retrieved over multicast.
We are also looking at implementing a session expire algorithm that uses two enveloped keys in the multicast service. One key is the current session key, and the second is the old, expiring key. That way, a client has a little more time to retrieve the new key without having to buffer encrypted messages before retrieving the new key.
According to zeromq.org, it's not supported yet but they are looking into it. It looks like it's suggested as a project for Google Summer of Code.
I'm developing a program with a client/server model where the client logs on to the server, and the server assigns a session id/handshake which the client will use to identify/authorize its subsequent messages to the server.
I'm wondering what length should the handshake be for it to be reasonably secure but also short enough to minimize data overhead, since I'd like to have it be low latency.
I'm thinking of using MD5 or murmurhash2 with the username and a random number salt with a collision detection, but I'm wondering if there's a more efficient solution (i.e. a better algorithm) and whether 32bits is too much/too little for this kind of thing.
Any input is highly appreciated.
I would use a HTTPS connection for your client/server communications.
It's easy to use (almost all the major SDKs implement it) and it provides good encription.
Regards.
PD: In reference of encryption method I would use Whirlpool because Mr. Rivest said in 2005 it was broken.
This may not be as simple as it looks. Note that if you send anything in clear over the network (e.g. session id/handshake), anyone can eavesdrop the communication and reuse this value to act as the client.
If you cannot use https, as the first answer suggested, you probably need to look at key agreement protocols. Once both parties agree on a shared secret key (which cannot be reconstructed based on observed communications), you can use it to authenticate all the remaining transmissions with a MAC (e.g. HMAC).
Whatever you do, don't use MD5, it's so totally broken. Whirlpool may also not be the good option, it's slower and there is a recent (theoretical) attack on the main part of it, see
ASIACRYPT 2009 Program.
I would stick with SHA-256 for now.