L'algorithme est plus forte pour les TLS: AES-256 ou Camellia-256?

Introduction:
Pour mon serveur, j'ai de configuration d'apache avec un certificat auto-signé pour activer la sécurité TLS pour apprendre et tester.
J'ai cette ligne dans un virtualhost:

SSLProtocol -all -SSLv3 +TLSv1  
SSLCipherSuite TLSv1:+HIGH:!MEDIUM

Avec firefox, j'obtiens Camélia-256 connexion cryptée, et avec l'opéra-je obtenir TLS v1.0 AES 256 bits (1024 bits DHE_RSA/SHA) avec la même config dans le même serveur.

Qui m'amène à la question, qui est plus fort, AES, ou Camellia?

J'ai remarqué que si je désactive le camellia avec SSLCipherSuite TLSv1:+HIGH:!MEDIUM:!CAMELLIA ensuite, firefox prend la même suite de l'opéra.

Dans ma config, j'ai aussi essayer de désactiver toutes les versions SSL pour activer uniquement le protocole TLS (conseiller nécessaire si je n'avais pas le faire correctement), mais la question est toujours debout: ce Qui devrait être le plus fort?

Pourrait être mieux adapté pour la Sécurité de la TI: security.stackexchange.com
N'avez pas de compte là-dedans, mais c'est OK si quelqu'un pouvait le déplacer à n' @Oleksi

OriginalL'auteur StormByte | 2012-04-30

  1. 15

    Je serais plus préoccupé par le fait que votre cryptage SSL n'est pas sûr parce que vous êtes seulement à l'aide de 1024 bits chiffrement asymétrique pour protéger vos clés.

    Adi Shamir (le 'S' dans RSA) a recommandé le déplacement à 2048 bits clés en 2006, même l'american standards institute (NIST) ont fait de 2048 bits minimal de la force depuis janvier 2011 (voir NIST SP800-57 recommandé pour un minimum d'principaux points forts -- les états de 2048 bits pour les deux RSA et DH/el-gamal).

    En bref, assurez-vous que votre chiffrement RSA est assez fort tout d'abord, comme il est utilisé pour protéger les clés symétriques (AES/Camélia). Ne jamais compter sur une clé, qui est protégé par un affaiblissement de la clé (c'est comme à l'aide d'un secure 256 bits aléatoires WPA 2 clé sur un point d'accès sans fil, puis faire confiance qu'il WPS qui se révèlent dans quelques heures!)

    Même si c'est un système de test, apprendre à utiliser la cryptographie la façon dont vous avez l'intention d'aller de l'avant; ne pas faire de compromis sur la clé de certificat de force (en tous CAs ces jours-ci devrait rejeter 1024 bits demandes ou aux préposés du service à l'aide de MD5 sur la vue, si ce n'est pas ne pas les utiliser; de créer votre propre test certs comme vous le feriez pour une vraie demande, et n'utilisez pas de clé par défaut tailles).

    Difficile de comparer les points forts, les deux ont reçu analyse cryptographique AES (domaine public) et sont adéquates pour la sécurisation des données.

    Au risque de me répéter, je serais plus inquiet à propos de l'1024 bits utilisés pour sécuriser les clés de la négociation.

    OriginalL'auteur Graham Coles

  2. 9

    Il est difficile de juger de la force de ces algorithmes. Camellia est considéré comme à peu près équivalent à AES en matière de sécurité (source). En tout cas, la différence ne sera probablement pas d'importance. Soit l'algorithme est suffisamment sécurisé pour faire de votre canal de données n'est plus le maillon le plus faible dans votre système, de sorte que vous n'avez pas besoin de s'embêter à modifier la configuration.

    Merci, c'est ce que j'avais besoin de savoir. Mais juste par curiosité, avez-vous une idée pourquoi opéra choisit AES et firefox choisit CAMELLIA par défaut?
    aucune idée, désolé
    Le raisonnement est contenue dans le NSS bibliothèque de code source et est un peu alambiqué, mais il n'a rien à voir avec la sécurité. Il a à voir avec un désir de soutenir national de la vanité des algorithmes.
    C'est expliqué un peu plus en détail ici: crypto.stackexchange.com/a/6548/5249

    OriginalL'auteur Oleksi

  3. 1

    OpenSSL cipherlist TLSv1:+HAUT est vraiment un mauvais choix. Le "+quelque chose de" notation " signifie déplacer tous les algorithmes qui correspondent à "quelque chose" à la fin de la liste.
    Donc, vous êtes à l'aide de HAUT qu'en dernier recours, avec tout ce qui n'est pas HAUT de ont préféré.

    Un bien meilleur choix est "par DÉFAUT:!MOYEN:!FAIBLE:!EXPORT:+3DES", qui commence avec des paramètres par défaut, supprime MOYENNE, FAIBLE et l'EXPORTATION, et utilise 3DES dernier (ça l'est probablement, de toute façon, mais sur certains systèmes, il s'agit avant AES128, car il peut être considéré comme de 168 bits forte).

    Compte tenu de la récente Sweet32 exploiter, vous devriez vraiment arrêter avec 3DES, sauf si vous êtes obligés de prendre en charge Windows XP, dans ce cas, je doute que la sécurité est une préoccupation. openssl.org/blog/blog/2016/08/24/sweet32

    OriginalL'auteur Viktor Dukhovni