Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 24 sur 26 PremièrePremière ... 141617181920212223242526 DernièreDernière
Affichage des résultats 691 à 720 sur 764
  1. #691
    Citation Envoyé par Møgluglu Voir le message
    Specs des Clarkdale et Arrandale après l'IDF, tableaux au format poster et version floutée de photo du Doc :
    http://pc.watch.impress.co.jp/docs/c...27_331818.html

    Les Arrandale (mobile) supportent le "Package Turbo", où le CPU et le GMCH sont overclockés indépendamment jusqu'aux limites du TDP global et/ou de la température des hotspots.

    Sinon quand fefe disait que les power gates ça prenait de la surface, je pensais pas que c'était à ce point-là:
    http://pc.watch.impress.co.jp/img/pc...317/526/23.jpg
    C'est parce qu'elles sont faites à la main, c'est la qualité Intel Inside

  2. #692
    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.

  3. #693
    7, tu es sûr ? D'après les docs Intel ce serait 6, ou alors je regarde pas les bonnes

  4. #694
    AESENC
    AESENCLAST
    AESDEC
    AESDELAST
    AESIMC
    AESKEYGENASST

    Et CLMUL
    Mes propos n'engagent personne, même pas moi.

  5. #695
    Ha ben c'est marrant Intel ne considère pas PCLMUL comme faisant partie de l'extension AES.

  6. #696
    Citation Envoyé par newbie06 Voir le message
    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...

  7. #697
    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 ?

  8. #698
    Citation Envoyé par newbie06 Voir le message
    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 ?
    Ben je crois que c'est le chiffrement utilisé pour TLS par openssl (une fois l'authentification OK)... Donc je dirais "oui, partout, pour toutes les transmissions chiffrées à peu près convenables, dont banques, VPN chiffrés, Skype, ..."
    Mes propos n'engagent personne, même pas moi.

  9. #699
    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.

  10. #700
    Citation Envoyé par newbie06 Voir le message
    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
    Vu les perfs des crypto asymétriques, oui, c'est juste pour authentification/échange de la clé symétrique.
    Mes propos n'engagent personne, même pas moi.

  11. #701
    Donc j'ai toujours pas ma réponse à : pourquoi ce forcing sur AES si d'autres algos sont utilisés ?

  12. #702
    Citation Envoyé par newbie06 Voir le message
    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)

  13. #703
    Dès que TrueCrypt supportera ces fonctions, je peut te garantir que ça fera beaucoup d'heureux ! Et l'AES c'est bien le truc le plus répandu, de loin quand même.

  14. #704
    Citation Envoyé par Møgluglu Voir le message
    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

  15. #705
    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.

  16. #706
    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

  17. #707
    Citation Envoyé par newbie06 Voir le message
    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.
    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é.
    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.
    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.
    Ca me donne un peu l'impression de dire on a foutu SSE69, vous n'avez plus besoin de GPU.
    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)
    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
    Je suis d'accord aussi. D'autant encore une fois que sans rng hard correct, c'est comme le h de hawai.
    Mes propos n'engagent personne, même pas moi.

  18. #708
    Citation Envoyé par newbie06 Voir le message
    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
    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.

  19. #709
    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).

  20. #710
    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.

  21. #711
    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.

  22. #712
    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

  23. #713
    Citation Envoyé par newbie06 Voir le message
    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).
    Fais donc un LVM chiffré, tu vas voir :X

  24. #714
    Citation Envoyé par Lissyx Voir le message
    Fais donc un LVM chiffré, tu vas voir :X
    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.

  25. #715
    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

  26. #716
    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

  27. #717
    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.

  28. #718
    Citation Envoyé par newbie06 Voir le message
    Tout ça me donne l'impression d'une course en avant, toujours plus pour distancer la concurrence.
    Euh... Normal, non ?
    Mes propos n'engagent personne, même pas moi.

  29. #719
    Citation Envoyé par newbie06 Voir le message
    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 ----------

    Citation Envoyé par Neo_13 Voir le message
    Euh... Normal, non ?
    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

  30. #720
    Citation Envoyé par Neo_13 Voir le message
    Euh... Normal, non ?
    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 ----------

    Citation Envoyé par fefe Voir le message
    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...
    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

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •