7 instruction d'AES en arrivée sur les 32nm...
J'ai pas encore cherché, mais j'ai pas vu de mention d'un générateur de nombres aléatoires genre celui de VIA.
Mes propos n'engagent personne, même pas moi.
7, tu es sûr ? D'après les docs Intel ce serait 6, ou alors je regarde pas les bonnes
AESENC
AESENCLAST
AESDEC
AESDELAST
AESIMC
AESKEYGENASST
Et CLMUL
Mes propos n'engagent personne, même pas moi.
Ha ben c'est marrant Intel ne considère pas PCLMUL comme faisant partie de l'extension AES.
C'est peut-être parce que ça sert à un peu tout en crypto sauf à AES?
En tout cas c'est une instruction nettement plus utile en général et durable que juste une bidouille pour accélérer uniquement un algo particulier comme AES.
On peut faire plein de choses intéressantes avec de l'arithmétique sur corps fini...
C'est bien ce que je me disais aussi
Alors pourquoi ce forcing sur l'AES ? Est-ce tellement utilisé que l'accélérer est si critique ?
Mes propos n'engagent personne, même pas moi.
RSA n'est utilisé que pour l'authentification ? Sinon Intel aurait plutôt dû optimiser sa mul entière qui est toujours plus lente que celle d'AMD...
De toute façon, si j'ai bien suivi, dans TLS d'autres algos qu'AES peuvent être utilisés :
http://en.wikipedia.org/wiki/Cipher_suite
Examples of algorithms used
key exchange
RSA, Diffie-Hellman, ECDH, SRP, PSK
authentication
RSA, DSA, ECDSA
bulk ciphers
RC4, Triple DES, AES, IDEA, DES, or Camellia. In older versions of SSL, RC2 was also used.
Message Authentication Code (MAC)
for TLS, a Hash-based Message Authentication Code using MD5 or one of the SHA hash functions is used. For SSL, SHA, MD5, MD4, and MD2 are used.
Donc j'ai toujours pas ma réponse à : pourquoi ce forcing sur AES si d'autres algos sont utilisés ?
Parce qu'en pratique en 2010 c'est l'algo que tout le monde utilise pour la crypto symétrique. Les autres ne sont pas assez sûrs, ou trop coûteux, ou ont des restrictions d'utilisation (brevets) ou autres raisons politiques.
Tu peux t'amuser à noter l'algo utilisé par chaque site en SSL que tu visites et faire des stats, ça serait intéressant.
(ma banque est en AES 256)
Ce qui serait interessant aussi serait de connaitre le volume de donnees transfere pour chaque type de cryptage utilise au cours d'une session.
Par ailleurs AES s'implemente bien en software sans support dedie (~11 cycles/octet pour le top du top), ce qui n'est pas le cas d'autres methodes. Intel clame un gain de 3-4 avec ses instructions (ref) et je ne parierais pas que ce gain n'a pas ete mesure contre les meilleures implementations soft.
Enfin bref, mon point de vue est que si AES est si important que ca, son implementation doit etre faite dans les chips reseau et pas dans le CPU, surtout pour des serveurs. Et pour un client quand on crypte/decrype a mettons 20 cycles/octet, on n'est clairement pas limite du tout par le CPU, mais par sa connexion internet (meme avec un debit de 50 Mo/s que personne n'a chez soi on parle d'utiliser 1B cycles/s).
Quelques references
http://www.cryptopp.com/benchmarks.html
http://cr.yp.to/streamciphers/timings.html
http://cr.yp.to/aes-speed.html
Ben c'est une convergence vers les serveurs... Et quand tu vois combien le pov nano de via poutre tout en crypto... Ca peut servir pour les VPN y compris passerelle (genre hadopi-box sur un atom DC avec ces instructions...) Mais il manque le RNG je trouve.
Mes propos n'engagent personne, même pas moi.
Je ne suis toujours pas vraiment d'accord : ne vaut-il pas mieux mettre le support AES sur ton chip reseau ? Comme Broadcom le fait depuis 2002 par exemple, ou bien encore certains chips WiFi d'Atheros.
Ton VPN il a besoin de quel debit ? Je parie que la vitesse de ton reseau fait que de toute facon, tu n'es pas limite par le CPU, en tout cas pas au niveau cryptage.
Ca me donne un peu l'impression de dire on a foutu SSE69, vous n'avez plus besoin de GPU.
EDIT : Je precise : je ne dis pas que ces instructions sont inutiles, je voudrais juste savoir si quelqu'un a des donnees quantitatives, s'tout ; mon avis c'est du gut feeling, pas une verite
Intuitivement, je vois bien comment ça marche pour du wifi ou de l'ipsec... Pour du ssl et les autres chiffrement en couche 5, je vois pas bien.
Parce que les chiffrements par la puce réseau, ils le sont jusqu'à la prochaine puce réseau, non ? Ce qui est un problème dès que le réseau est routé et plus commuté.
Je comprend bien... D'autant que sans RNG viril, c'est du soft qui fournit les clés... Mais c'est bien aussi si en parallèle du vpn, ma passerelle continue son taff de pare feu, voir de DNS, voir ... Ou que, du fait de cette amélioration, on peut baisser considérablement fréquence et du coup tension et du coup power des chip considérés.Ton VPN il a besoin de quel debit ? Je parie que la vitesse de ton reseau fait que de toute facon, tu n'es pas limite par le CPU, en tout cas pas au niveau cryptage.
A moi aussi, mais même si c'éatit le cas, ça n'empeche pas de mettre un gpu. Par contre ça permet peut être de s'en passer (à bencher)Ca me donne un peu l'impression de dire on a foutu SSE69, vous n'avez plus besoin de GPU.
Je suis d'accord aussi. D'autant encore une fois que sans rng hard correct, c'est comme le h de hawai.EDIT : Je precise : je ne dis pas que ces instructions sont inutiles, je voudrais juste savoir si quelqu'un a des donnees quantitatives, s'tout ; mon avis c'est du gut feeling, pas une verite
Mes propos n'engagent personne, même pas moi.
Y a une bonne raison : on n'utilise pas AES que dans le réseau. Par exemple, les OS (tout du moins OS X) chiffre le dossier user en AES quand t'active le mode « sécurité » et ça bouffe du CPU (et ça tue les perfs). Et y a de plus en plus de trucs de stockage chiffré en AES.
Autre exemple con, un Via Nano poutre à peu près tous les CPU en décodage Blu-ray (couplé à une carte graphique qui gère le H.264) parce que ce qui reste généralement sur le CPU en lecture de Blu-ray, c'est les DRM. Qui utilise, a priori, de l'AES.
Ha ça c'est un très bon argument
Mais j'ai un doute sur le ralentissement : en prenant 13 cycles/octet pour un CPU à 2.6GHz on parle quand même de 200 MB/s, donc au même niveau que le débit disque (et encore si ça atteint le débit max d'un SSD).
Je t'avoue que le chiffrement du dossier, j'ai essayé, il a pas voulu le faire par manque de place (SSD...) donc j'ai pas testé. Mais les bouquins écrit par des gars compétent indiquent bien une perte de perfs (et la doc Apple aussi)
Après, 13 cycles/octets, c'est sans rien à côté, donc bon.
Faudrait mesurer pour voir : tar du dossier, tar + cryptage du dossier, parce que bien foutu avec des IO non bloquantes...
Faut dire aussi que j'ai vu des implémentations aberrantes d'AES dont les performances étaient une catastrophe.
Bon ça vaut ce que ça vaut :
Code:$ time ( cp -p /home/laurent/Downloads/X3TCRollingDemoSetup.exe . ; sync ) real 0m8.167s user 0m0.002s sys 0m1.262s $ time ( cryptest ae 000102030405060708090A0B0C0D0E0F 000102030405060708090A0B0C0D0E0F X3TCRollingDemoSetup.exe X3TCRollingDemoSetup.exe.aes; sync ) real 0m8.714s user 0m2.385s sys 0m2.302s $ ls -l X3TCRollingDemoSetup.exe -rw-rw-r--. 1 laurent laurent 442749610 2009-11-19 21:25 X3TCRollingDemoSetup.exe
Ha ?
http://www.fsckin.com/2008/01/15/how...ons-in-ubuntu/
http://www.saout.de/tikiwiki/tiki-in...rPageChonhulio
Celui-ci montre qu'il faut bien faire gaffe au FS utilise :
http://www.tomshardware.com/reviews/...book,1303.html
Au fait, j'avais utilise un auto programme que cryptopp avant et c'etait 3x moins performant.
http://www.tomshardware.co.uk/clarkd...iew-31801.html
Je me demande a quel point c'est significatif puisqu'on ne sait pas a quel point les implementations AES n'utilisant pas les instructions specialisees ont ete tunees.
Par exemple on voit Sandra se faire un x6 en AES256 encryption pendant qu'Everest fait x9 (et quand je vois la vitesse d'encryptage de 25 MO/s sans les instructions AES, la je peux clairement affirmer que ce n'est pas optimise).
WinZIP (en encryption pure) et BitLocker font "seulement" x2.
Comme d'habitude on elimine les benchs synthetiques qui ne prouvent pas grand-chose, et on reste avec les x2 applicatifs. C'est pas mal, mais ca ne me convainc toujours pas de l'utilite pratique
Ce qui est effectivement interressant est quelle energie/octet encrypte a quel throughput. Tu arriveras vite a la conclusion que les nouvelles instructions aident. Ce n'est pas une revolution mais ca fait bien longtemps que les revolutions et x86 ne sont plus compatibles (combien de dizaines d'annees est laisse a interpretation personnelle). Au final ca va dans la bonne direction et le code est dispo pour un certain nombre d'applis a la sortie ce qui devrait permettre d'ici quelques annees a avoir l'essentiel du code AES sur x86 qui utilise ces instructions. Le resultat sera meilleur que sans, et ce de n'importe quelle maniere tu decides de tourner le probleme et c'est ce qui est recherche. Des accelerations meme d'un facteur 2 sur un kernel restent suffisament rares pour que cela vaille le coup...
fefe - Dillon Y'Bon
Attention, je suis bien d'accord que ce facteur 2 est assez rare et plutôt bon à prendre. Maintenant puisque tu parles d'énergie consommée, une IP dédiée à cette tâche sera toujours plus efficace, mais bien entendu c'est difficile à intégrer dans une architecture, on passe dans le monde du SoC.
Tout ça me donne l'impression d'une course en avant, toujours plus pour distancer la concurrence.
Tu peux toujours integrer une ip dediee, mais dans le cas des utilisations donnees en exemple je doute que ce soit plus efficace (energie/perf) que les nouvelles instructions (qui integrent ton IP dans le pipeline au lieu de le mettre loin et rendre son integration a du code moins efficace).
Donc si tu n as qu une chose a faire c'est faire de l'AES, l'IP dediee gagnera toujours oui, si tu fais de l'AES au milieu de plein d'autre code et ce a grain fin, j'ai de gros doutes...
---------- Post ajouté à 20h13 ----------
Jusqu a preuve du contraire, tout le monde fait des processeurs pour les vendre, pas juste pour la beaute de la chose. Donc oui course en avant pour etre meilleur que la cmpetition et vendre tes produits, rien de nouveau sous le soleil.
fefe - Dillon Y'Bon
Oui bien sûr, et quand les dév en auront marre de devoir coder 10 variantes, ils arrêteront juste de supporter les nouveautés
---------- Post ajouté à 19h20 ----------
Je partais du postulat que l'AES était utilisé en streaming et sur des blocs pas tout petits. Si ce n'est pas le cas, je renvoie à ma question initiale du pourquoi l'absence d'une mul 64-bit efficace qui accélèrerait RSA