Best choice out of these six TLS cipher suites I have a small embedded platform that supports 6 TLS ciphers. Is there a good/better/best one to chose?

I was looking around on the web for some kind of rating system or list of ciphers that have known weaknesses, but I couldn't find much.

Back to my project, I used the Wireshark tool to capture the "client hello" when authenticating with the server, and my (slim) options are as follows:

TLS_RSA_WITH_RC4_128_SHA (0x0005)
TLS_RSA_WITH_RC4_128_MD5 (0x0004)
TLS_RSA_WITH_AES_128_CBC_SHA (0x002F)
TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000A)
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

I have heard triple DES, RC4, and MD5 are insecure, so should I be avoiding ciphers with those algorithms? Does this leave me with cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and TLS_DHE_DSS_WITH_AES_128_CBC_SHA?

Ideally, you should not use any of them. At all.
Here's why.

RC4, MD5 and DES should not be used anymore. Old crypto. Toss it.
CBC mode in AES sometimes suffers from implementation problems (cf. Padding Oracles). Thus, CBC should be avoided.
SHA1 is considered insecure and is not be accepted as a certificate signing hash since January 2017 by major browsers.

So, if you absolutely have to stick with one of these ciphers, I agree with @otus here, and would recommend TLS_DHE_DSS_WITH_AES_128_CBC_SHA.

IF ever you have a chance to add other ciphers to your embedded platform, know this :
Symetric ciphers :

AES and ChaCha20 are the best symmetric ciphers to use, as of the
beginning of the 21st century. The difference between them is, simply
put, being a block and stream cipher, therefore being different in
speed.
AES often takes advantage of AES-NI, a hardware acceleration, found on many processors in current laptops and servers.
ChaCha20 is to be preferred on mobile and embedded platforms, where
AES hardware acceleration is rare, because it is really faster.
Poly1305 is de facto the best buddy for ChaCha20, so they go in pair.
For AES, consider AEAD compatible modes, like GCM.
Chose a hash algorithm like SHA2 or above (SHA384, SHA512,...). The higher, the more secure. But this is overkill, will take more time and is heavier in terms of size. So stick with SHA256.

Asymmetric ciphers (for key exchange) :

Today's trend and best use is Diffie-Hellman. Even better, Ephemeral Elliptic-Curve Diffie-Hellman (ECDHE), because it is smaller, faster (you can generate 384bit parameters in a couple of milliseconds, corresponding to 7680 non-EC bits that would take hours to generate on your embedded device).

Certificate Signing :

Nobody uses DH.

RSA was good. To be avoided from now on. is still good.
It's even really faster for validation than DSA - take a look with
openssl speed (up to you to determine whether this matters for your use).

Best use : ECDSA. DSA is new, and coupled with Elliptic curves, it is smaller and really faster than RSA - take another look at openssl speed. Considered more secure. Just a shame that Edwards curves are not supported in OpenSSL as for now.

(Sorry if I missed details or am not being clear, wrote this on lunch break.)
EDIT : Added clarification on choice between ECDSA and RSA. Thanks @Dreadlockyx and @otus for having me have a second look !

You should use one of these two:

TLS_RSA_WITH_AES_128_CBC_SHA (0x002F)
TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)

The reasons are, as you have said, the rest combinations use insecure algorithms. RC4, DES, and MD5 have been vulnerated and they are not the last version of each one.

RC4: The last version is RC6. The use of RC4 in TLS was prohibited. Besides, you can read more about his security problems [here].(https://en.wikipedia.org/wiki/RC4#Security)
MD5: The last version is MD6. MD5 was violated using Collision attacks in 1, 2, 3, and 4 and preimages.
3DES: 3DES was violated using Brute force. 3DES has vulnerabilities and theorical attacks.


What is the main difference between a key, an IV and a nonce? What are the main differences between a nonce, a key and an IV? Without any doubt the key should be kept secret. But what about the nonce and the IV? What's the main difference between them and their purposes? Is it only that, in literature and in practice, an IV is being used as "initiator" of a block cipher encryption mode which should be unique? And the same property should hold for a nonce as well, but since it doesn't instantiate something we call it a nonce? I.e: in AES-CTR mode the IV is a nonce+counter. And both are put in plaintext format in the beginning of the ciphertext.

A key, in the context of symmetric cryptography, is something you keep secret.  Anyone who knows your key (or can guess it) can decrypt any data you've encrypted with it (or forge any authentication codes you've calculated with it, etc.).
(There's also "asymmetric" or public key cryptography, where the key effectively has two parts: the private key, which allows decryption and/or signing, and a public key (derived from the corresponding private key) which allows encryption and/or signature verification.)
An IV or initialization vector is, in its broadest sense, just the initial value used to start some iterated process.  The term is used in a couple of different contexts and implies different security requirements in each of them.  For example, cryptographic hash functions typically have a fixed IV, which is just an arbitrary constant which is included in the hash function specification and is used as the initial hash value before any data is fed in:

Conversely, most block cipher modes of operation require an IV which is random and unpredictable, or at least unique for each message encrypted with a given key.  (Of course, if each key is only ever used to encrypt a single message, one can get away with using a fixed IV.)  This random IV ensures that each message encrypts differently, such that seeing multiple messages encrypted with the same key doesn't give the attacker any more information than just seeing a single long message.  In particular, it ensures that encrypting the same message twice yields two completely different ciphertexts, which is necessary in order for the encryption scheme to be semantically secure.
In any case, the IV never needs to be kept secret — if it did, it would be a key, not an IV.  Indeed, in most cases, keeping the IV secret would not be practical even if you wanted to since the recipient needs to know it in order to decrypt the data (or verify the hash, etc.).
A nonce, in the broad sense, is just "a number used only once".  The only thing generally demanded of a nonce is that it should never be used twice (within the relevant scope, such as encryption with a particular key).
The unique IVs used for block cipher encryption qualify as nonces, but various other cryptographic schemes make use of nonces as well.
There's some variation about which of the terms "IV" and "nonce" is used for different block cipher modes of operation: some authors use exclusively one or the other, while some make a distinction between them.  For CTR mode, in particular, some authors reserve the term "IV" for the full cipher input block formed by the concatenation of the nonce and the initial counter value (usually a block of all zero bits), while others prefer not to use the term "IV" for CTR mode at all.  This is all complicated by the fact that there are several variations on how the nonce/IV sent with the message in CTR mode is actually mapped into the initial block cipher input.
Conversely, for modes other than CTR (or related modes such as EAX or GCM), the term "IV" is almost universally preferred over "nonce".  This is particularly true for CBC mode since it has requirements on its IV (specifically, that they are unpredictable) which go beyond the usual requirement of uniqueness expected of nonces.

The three terms (key, IV, nonce) you mentioned, and another, the salt, basically describe random numbers and each term is used in another context. The key is used as input for a cryptographic primitive and should be kept secret.

A nonce is a random number only used once and for a short time with the intention to get replaced by or converted into something better. A initialization vector is also used as input for a cryptographic primitive to achieve randomization of normally deterministic primitives. Stream ciphers are called stateful where the same key is used for many states and the nonces are used to ensure different key streams. For this reason, we use IVs for the modes of operations of block ciphers but nonces for stream ciphers. This is a little bit confusing when we talk about AES-CTR because we use the term IV for the block cipher and the term nonce+counter for the state of the stream cipher.

For the sake of completeness, a salt is also some kind of initialization vector for one-way functions but with the goal to achieve additional entropy for low-entropy inputs, e.g. password hashing.


K out of N encryption A friend just showed me how to combine padlocks to achieve a lock that opens when k out of n people turn their keys.

I was wondering if there was something similar for encryption; using n or fewer public keys encrypt a piece of data so it can only be unlocked if at least k out of n specific private keys are applied.

I've tried ideas of stacking normal public key encryption, but without luck. I'm sure somebody must have done research on the topic, but I have no idea what such a thing is called. Maybe it's even widely accessible through standard encryption libraries?

I don't know of anything that does that.

I guess you could use a data scheme with high redundancy and reconstruction attributes, like a CRC type algorithmn, with properties where if you have like 2/3rd of the bytes, it can reconstruct the entire input. Encode the 1st, 4th, 7th byte, etc, with one key, the 2nd, 5th, etc with the second, and 3rd, 6th, etc with the third.

Overall though, I don't think computer encryption really works like that - it's fundamentally different from a padlock, which is an access control scheme, not data hiding.


Vigenère cipher: Security when key length and plaintext length are the same I have read the Vigenère cipher is secure as long as the key length is the same as the length of the data to be ciphered.

Is this true when the same key is used multiple times?
In such cases, after how many uses would the key be considered insecure?

Forming my comment into an answer:

If the key has the same length as the message and is used only once, it is basically a One-Time-Pad. This means, that in theory you can match any ciphertext to any plaintext with $a key$. If this key has to match certain criteria (e.g. be a word of a certain language), the information theoretic aspect will be lost. It depends on the actual keyspace if this is a problem.

However, the re-usage is more tricky, because all security is lost in Vigenere once a key is reused. If you have two ciphertexts created by the same key, you can just combine them and have the key eliminated. Then you are left with the combination of the two plaintexts, which is easy to deal with by using frequency analysis.

If the Key is completely random, used only once and the same length as the plain text then it is a One time Pad.
It may NOT be secure though, for example if the message is very short.

If the Message is short, and your Key is a word or a couple of words then it is unsecure, because there are what ? a few thousand words to try to brute force.
So I think a good Key should be the same length as the plaintext AND truly random OR use a sufficient number of words (around 12 minimum) selected randomly, along the lines of battery, horse, staple....and used only once, otherwise patterns may emerge in the resultant ciphertexts.


Solid summary of what encryption remains strong after recent events Following the recent government hacking (and subsequent news and fallout), I'm wondering what crypto-systems remain strong (and why) and what crypto-systems were exploited too heavily to be reliable. I'm wondering what will remain strong for the foreseeable future and why these systems were not affected (while the others presumably were).

I tried to find the information on the following and many other pages, but they were not very helpful in this case…

http://en.wikipedia.org/wiki/NSA_encryption_systems
http://en.wikipedia.org/wiki/NSA_cryptography

Perhaps someone can help me understand this.

We don't know what NSA (or any other spy agency--the US isn't the only country with code breakers) has broken.  Other than Dual EC DRBG, we are left with everyone making their best guess, just like before.  The NIST elliptic curves and the SHA2 hashes and DSA all came from NSA, but that seems to be the only real reason to suspect anything bad about them.  Neither AES nor SHA3/Keccak have anything at all to do with NSA.

NSA's own nuclear, military, navy, airforce and classified government networks are probably some of the most secure systems on the planet. They need to be extremely strong to protect the armed forces, government and populace. However the same cannot be said for their publicly recommended encryption systems because recent leaks have shown their intention is to backdoor/weaken those systems/standards that are in commercial/public use so they can use their surveillance network to monitor what everyone is doing. Their aim is totalitarian control and subversion of democracy.

They have not just been weakening one standard (Dual EC DBRG), they have been weakening a lot of them. You would be ill advised to continue using them. As of 2013-10-15 The Wikipedia link you gave provides a good list of those likely compromised systems to avoid. Until we know the full extent of the damage to cryptography in general it is better to lean on the side of caution. For starters that means avoiding any standard to do with NSA/NIST.

Standards with NSA involvement to avoid:

  Suite B - set of cryptographic algorithms promulgated by the NSA as part of its Cryptographic Modernization Program

  Advanced Encryption Standard (AES) - an encryption
  algorithm, selected by NIST after a public competition. In 2003, NSA
  certified AES for Type 1 use in some NSA-approved systems.

  Secure Hash Algorithm - a widely used family of hash algorithms developed by NSA
  based on earlier designs by Ron Rivest.

  Digital Signature Algorithm

  Data Encryption Standard (DES)

  Skipjack - the cipher developed for Clipper and finally published in 1998.

  Clipper chip - a controversial failure that convinced NSA that it was advisable to stay out of the public arena.

  Security-Enhanced Linux - not strictly an encryption system, but a recognition that in the 21st century, operating system improvements are vital to information security as well.

So what is left that is still good to use?

At the perfect security end you have got one-time pads and other
cryptosystems that are information-theoretically secure. These are
still in use by governments today. They transfer the one-time pads
between embassies with diplomatic bags etc which are protected under
the Vienna Convention.
After that you've got stream ciphers which attempt to mimic the
one-time pad. These are likely still secure assuming you have a very
long, quality random seed to begin with, an unbroken implementation
and well designed CSPRNG. They do not offer perfect security however
but would probably still frustrate the NSA.
After that there is independently designed block ciphers that should
be ok to use for less important things e.g. hard disk encryption. For
example, Serpent, Twofish, Threefish etc. Remember you want 256 bits
or greater to take into effect recent developments in quantum
computing and cryptanalytic breakthroughs.
Newer hashing algorithms not designed by NSA should be fine to use.
Recent examples might be finalists in the recent NIST hash
competition. Obviously steer clear of the finalised SHA-3 standard by
NIST and use the original Keccak algorithm which has already been
vetted by various cryptographers. You do not need NIST's "tweaks"
that are being made to suit their purposes, not yours.
Elliptic curve cryptography is not my area of expertise.
However if you are going that route avoid the NIST recommended curves
and use some independently vetted ones.
Public key cryptography is fundamentally broken, especially with
Certificate Authorities for authentication. The NSA only needs to
compromise just one CA which is already trusted in your browser. Then
they can silently MITM your connection and send you a false
certificate signed by the same authority. Your browser will
automatically accept it. Also because your web browser trusts over
500 different certificate authorities they can actually just send you
a certificate signed by one of the compromised authorities and your
browser will silently accept it and show a green padlock. Most users
will not notice this. This is regardless of whether the real
certificate was signed by that authority in the first place. Remember
the certificates in your browser is like a keychain of all the people
you trust. If there is just one bad apple then the whole trust system
breaks down.

Public key cryptography is a nice idea in theory, but it breaks down in the real world. In today's
world with all the internet backbones tapped by "Five Eyes" countries
and numerous untrusted router hops along the way, you do not actually
have an authentic channel to transfer the public key to someone in
the first place. In other words you have no idea if the public key
you are receiving is actually the one you want to receive and not an
attacker's. There is no provable authenticity. If you really wanted to
use public key cryptography you would transfer the public key to them
in person and load it into your keychain as trusted. That lets you know for sure that this is the real key and not an attacker's key. Potentially you could at least verify a
checksum/hash of the key over another channel e.g. telephone. It is
probably harder for an attacker to synthesize someone's voice in
real-time. The CIA or MI6 could probably pull it off though.