Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Verschlüsselung: Der lange Abschied…

Die und ihr Chacha

  1. Thema

Neues Thema Ansicht wechseln


  1. Die und ihr Chacha

    Autor: minnime 17.07.15 - 18:07

    Also ich mag Chachacha auch, als Tanz, aber die Verschlüsselung ist so toll jetzt auch nicht. Abgesehen davon, dass es eigentlich keine Strom-, sondern viel mehr eine Blockverschlüsselung im Counter-Mode ist, eigentlich sogar nur eine Hashfunktion, die auf einem 512 Bit Block ausgeführt wird. Ich habe einige Verschlüsselungen in C# selbst implementiert. Bei diesen Versuchen gab es einige Algorithmen, die von Anfang an recht schnell waren und andere mussten erst optimiert werden. Chacha hatte einigen Optimierbedarf und noch immer Potential. Im Grunde müsste der Chacha mit Assembler implementiert werden, nur damit könnte man noch etwas rausholen. Mein Favorit war übrigens der HC128, selbst unoptimiert sehr schnell. Es gibt durchaus noch andere Kandidaten die recht vielversprechend sind aber es ist halt so, dass Bernstein recht gute Lobbyarbeit leistet. So erklärt es sich auch, dass sein MAC Verfahren Poly1305 standardisiert wurde und das ist erst recht grausam, schlecht dokumentiert und erfordert viel Gefrickel zur Implementierung.

  2. Re: Die und ihr Chacha

    Autor: bstea 17.07.15 - 19:23

    Wer heute noch Algorithmen in Assembler programmiert sollte lieber Kuhzüchter werden und die Finger vom Programmieren lassen.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  3. Re: Die und ihr Chacha

    Autor: George99 17.07.15 - 19:42

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Wer heute noch Algorithmen in Assembler programmiert sollte lieber
    > Kuhzüchter werden und die Finger vom Programmieren lassen.

    Gut, es ist Freitag, es ist heiss, aber das rechtfertigt auch nicht solche Müllpostings...

  4. Re: Die und ihr Chacha

    Autor: crypt0 17.07.15 - 20:57

    minnime schrieb:
    --------------------------------------------------------------------------------
    > Also ich mag Chachacha auch, als Tanz, aber die Verschlüsselung ist so toll
    > jetzt auch nicht.
    Bitte?!

    > Abgesehen davon, dass es eigentlich keine Strom-, sondern
    > viel mehr eine Blockverschlüsselung im Counter-Mode ist
    Das ist ein Vorteil! Sogar ein extremer! -> Ich sag nur beliebige Teilstücke ver/entschlüsseln

    >, eigentlich sogar
    > nur eine Hashfunktion, die auf einem 512 Bit Block ausgeführt wird.
    Per definition NEIN! Schlüsselabhängig!

    > Ich habe einige Verschlüsselungen in C# selbst implementiert. Bei diesen
    > Versuchen gab es einige Algorithmen, die von Anfang an recht schnell waren
    > und andere mussten erst optimiert werden.
    Ja ist in C/C++, Java, Go auch so, ich spreche aus erfahrung ;-)

    > Chacha hatte einigen
    > Optimierbedarf und noch immer Potential. Im Grunde müsste der Chacha mit
    > Assembler implementiert werden, nur damit könnte man noch etwas rausholen.
    Entschuldige, aber dann machst du was falsch...
    Oder du hast EXTREME Anforderungen...

    > Mein Favorit war übrigens der HC128, selbst unoptimiert sehr schnell.
    Ja, HC128/256 erkauft sich die Geschwindigkeit mit Specherplatz -> der riesige status
    In software-impl. allg. kein Problem (außer embbeded) für hardware-impl. dagegen schon! Salsa20/X bzw. Chacha20/X lässt sich dagegen in beiden Fällen effizient implementieren.

    > Es gibt durchaus noch andere Kandidaten die recht vielversprechend sind aber
    > es ist halt so, dass Bernstein recht gute Lobbyarbeit leistet. So erklärt
    > es sich auch, dass sein MAC Verfahren Poly1305 standardisiert wurde und das
    > ist erst recht grausam, schlecht dokumentiert und erfordert viel Gefrickel
    > zur Implementierung.

    naja, Poly1305 ist viell. nich trivial implementierbar, aber es hat auch seine Vorteile:
    - beweisbare sicherheit unter der Voraussetzung die zugrunde-liegende Cipher ist sicher
    - Geringer overhead
    - hohe performance
    ...

    Generell ist die wahl für Chacha20/X nicht unbegründet, gerade der geringe Ressourcenverbrauch + wahlfreie ver/entschlüsselung sind in kombination bis jetzt Alleinstellungsmerkmal

  5. Re: Die und ihr Chacha

    Autor: bstea 17.07.15 - 21:54

    Danke für deinen sinnfreien Beitrag.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  6. Re: Die und ihr Chacha

    Autor: minnime 18.07.15 - 02:26

    crypt0 schrieb:
    --------------------------------------------------------------------------------
    > Das ist ein Vorteil! Sogar ein extremer! -> Ich sag nur beliebige
    > Teilstücke ver/entschlüsseln

    Ja klar ist das praktisch, aber irgendwie ist das nicht so richtig eine Stromchiffre.

    > Per definition NEIN! Schlüsselabhängig!

    Aber der Schlüssel steht in dem Block drin, die eigentliche Transformationsfunktion arbeitet wie eine Hashfunktion. Man könnte diese sogar durch SHA-512 ersetzen (bei anderem Ergebnis versteht sich), denn die Definition des Blocks und dessen Verwendung und die Transformation sind unabhängig voneinander.

    > Entschuldige, aber dann machst du was falsch...
    > Oder du hast EXTREME Anforderungen...

    Ja wieso, bei Verschlüsselungen möchte man doch hohe Geschwindigkeit, die soll ja praktisch transparent arbeiten. Gerade bei sowas bietet sich doch Assembler an. Es handelt sich um kurze überschaubare Operationsfolgen. Ich würde auch nicht alles in Assembler schreiben, sondern nur die Quarterroundfunction, da waren im erzeugten Assemblercode noch einige sinnlose Kopiervorgänge.

    > Ja, HC128/256 erkauft sich die Geschwindigkeit mit Specherplatz -> der
    > riesige status
    > In software-impl. allg. kein Problem (außer embbeded) für hardware-impl.
    > dagegen schon! Salsa20/X bzw. Chacha20/X lässt sich dagegen in beiden
    > Fällen effizient implementieren.

    Ach Mist, das mit dem Speicherplatz habe ich absichtlich unter den Tisch fallen lassen, jetzt kommt da doch einer drauf.
    Der Chacha war jetzt wirklich nicht mein schnellster, noch langsamer als der selbstgebaute RC6 und auch als die bei .Net mitgelieferten AES Varianten.

    > naja, Poly1305 ist viell. nich trivial implementierbar, aber es hat auch
    > seine Vorteile:
    > - beweisbare sicherheit unter der Voraussetzung die zugrunde-liegende
    > Cipher ist sicher
    > - Geringer overhead
    > - hohe performance

    Nicht trivial ist gut. Ich hab den mit dem BigInteger von .Net umgesetzt, erwartungsgemäß mehr als nur schnarchlangsam. Wenn das Ding schnell sein soll, muss man die BigInteger-Arithmetik selbst konstruieren und kann dann auch optimieren. Wie das funktioniert, das ist nicht ganz so einfach, also ich habs noch nicht verstanden. Gut ich bin auch kein Vorzeigeinformatiker. Jedenfalls kann man den Poly nicht einfach so aus dem Paper heraus implementieren was sonst recht gut klappt.

    > Generell ist die wahl für Chacha20/X nicht unbegründet, gerade der geringe
    > Ressourcenverbrauch + wahlfreie ver/entschlüsselung sind in kombination bis
    > jetzt Alleinstellungsmerkmal

    Ich weiß nicht, da hätte es doch auch irgend ne andere Blockchiffre im Counter- oder Output Feedback Mode getan.

  7. Re: Die und ihr Chacha

    Autor: caldeum 18.07.15 - 11:00

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Danke für deinen sinnfreien Beitrag
    Klar ist es mühselig, ganze Algorithmen in Assembler zu implementieren und man muss auch einiges auf dem Kasten haben, damit sich eine manuelle Codeoptimierung in Assembler mit den Optimierungsfähigkeiten eines aktuellen Compilers messen kann. Aber wenn man das kann, gibt es nichts besseres.

  8. Re: Die und ihr Chacha

    Autor: George99 18.07.15 - 12:38

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Danke für deinen sinnfreien Beitrag.

    Sinnfrei war nur dein dummes Bashing gegen Assemblerprogrammierung.


    Wenn es auf schnellen Code ankommt und die CPU dafür Spezialbefehle kennt, wäre es blödsinnig, darauf zu verzichten. Denk z.B. mal an AES-Routinen, einmal in Standard-C und einmal in Assembler oder zumindest mit Intrinsics.

  9. Re: Die und ihr Chacha

    Autor: bstea 18.07.15 - 13:32

    Wenn die Portabilität darunter leidet ist Assembler gerade auch in Hinsicht auf Wartbarkeit eine Katastrophe. Dann nehm ich lieber die manchmal nicht ganz optimale vom Compiler optimierte Fassung statt mir selbst was zu stricken dessen Dokumentation nunja sagen wir schwierig ist.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  10. Re: Die und ihr Chacha

    Autor: crypt0 18.07.15 - 13:37

    minnime schrieb:
    --------------------------------------------------------------------------------
    > Ja klar ist das praktisch, aber irgendwie ist das nicht so richtig eine
    > Stromchiffre.
    Wieso? Bei ner Blockcipher wird ein X bit langer block in einen anderen X bit langen Block transformiert bei einer Stromcipher wird ein keystream erzeugt (nicht von eingabe abhängig) und dann mit dem input XOR verknüpft, viell. ist das ansichtssache, aber der ctr-mode ist für mich auch eine stromcipher...

    > Aber der Schlüssel steht in dem Block drin, die eigentliche
    > Transformationsfunktion arbeitet wie eine Hashfunktion. Man könnte diese
    > sogar durch SHA-512 ersetzen (bei anderem Ergebnis versteht sich), denn die
    > Definition des Blocks und dessen Verwendung und die Transformation sind
    > unabhängig voneinander.

    Ja schon, aber das ist doch bei RC4, HC128/256, Trivium etc. auch so...
    Der schlüssel steht im status, der dann per fortschalte-funktion ein neues bit/byte/.. ausgibt, klar gibt es auch schlüsselabhängige Fortschaltefunktionen aber unüblich ist das jetzt nicht gerade...

    > Ja wieso, bei Verschlüsselungen möchte man doch hohe Geschwindigkeit, die
    > soll ja praktisch transparent arbeiten. Gerade bei sowas bietet sich doch
    > Assembler an. Es handelt sich um kurze überschaubare Operationsfolgen. Ich
    > würde auch nicht alles in Assembler schreiben, sondern nur die
    > Quarterroundfunction, da waren im erzeugten Assemblercode noch einige
    > sinnlose Kopiervorgänge.

    Prinzipiell ja, aber gerade bei embbeded / smartcard z.B ist performance eher zweitrangig, da zählt minimaler Speicherplatz... Ja, optimierungsbedarf gibts fast immer, hängt auch vom Compiler etc. ab.
    Jedoch ist bsp. AES ohne prozessor-befehlserweiterung meiner erfahrungen nach schon langsamer als HC128/256 oder Salsa20/X bzw. Chacha20/x (in C/C++)

    > Ach Mist, das mit dem Speicherplatz habe ich absichtlich unter den Tisch
    > fallen lassen, jetzt kommt da doch einer drauf.
    ;-)

    > Der Chacha war jetzt wirklich nicht mein schnellster, noch langsamer als
    > der selbstgebaute RC6 und auch als die bei .Net mitgelieferten AES
    > Varianten.

    Hast du viell Messwerte z.B. Cy / Byte oder MB / sec
    Kann ich zumindest nicht bestätigen (kenn aber auch die .net implemnetierungen ned)
    Also in Java war eine hochoptimierte AES-variante performancetechnisch c.a vergleichbar mit ner "standardimplementierung" von Salsa20/12

    > Nicht trivial ist gut. Ich hab den mit dem BigInteger von .Net umgesetzt,
    > erwartungsgemäß mehr als nur schnarchlangsam. Wenn das Ding schnell sein
    > soll, muss man die BigInteger-Arithmetik selbst konstruieren und kann dann
    > auch optimieren. Wie das funktioniert, das ist nicht ganz so einfach, also
    > ich habs noch nicht verstanden. Gut ich bin auch kein Vorzeigeinformatiker.
    > Jedenfalls kann man den Poly nicht einfach so aus dem Paper heraus
    > implementieren was sonst recht gut klappt.

    Ja die BigInteger Klassen... War auch noch nie zufrieden mit dieser (Java-)Umsetzung... Performant ist was anderes!
    Ja da geb ich dir schon recht, das macht man nicht mal eben so an einem nachmittag

    > Ich weiß nicht, da hätte es doch auch irgend ne andere Blockchiffre im
    > Counter- oder Output Feedback Mode getan.

    Prinzipell ja, aber ich vermute man wollte auch eine "reine" stromcipher als ersatz für RC4. Mit AES,Camellia... gibt es bereits einige Blockchiffres. Und unter den stromchiffren gibt es derzeit nicht so große Auswahl:
    Trivium -> schnell, extrem klein, aber keine ausreichende Schlüssellängen (80 bzw. 160 bit)
    HC128/256 schnell, sicher aber nicht geeignet für hardware oder embbeded-geräte
    ....
    Salsa20/x bzw. Chacha20/x sind zwar auch nicht das absolute non-plus-ultra, aber erfüllen doch viele Vorraussetzungen sprich relativ klein, schnell, wahlfreier Zugriff.
    Salsa und Chacha sind eher all-rounder, aber genau das hat warscheinlich den Ausschlag gegeben...

    Aber angenehm mal wieder jemanden zu treffen, der sich mit krypt. auskennt!



    1 mal bearbeitet, zuletzt am 18.07.15 13:39 durch crypt0.

  11. Messwerte

    Autor: minnime 19.07.15 - 11:30

    Viel hab ich nicht, eben nur Salsa20/12, Chacha20/12? meinen geliebten RC6 (sehr einfach, anpassbar (32/64Bit, Rundenzahl, Schlüsselgröße) und sonneklare Doku), Phelix (zwar theoretisch unsicher aber das Prinzip ist toll) und eben Poly mit BigInteger.

    Die ersten beiden sind in .Net enthalten. Alle Blockchiffren in ECB Modus. Initialisierungszeiten nicht eingerechnet (dabei HC128 und Phelix besonders schlecht (3ms auf meinem Rechner)).

    AES CryptoServiceProvider (Aufruf von Windows Bibliotheken) 128 Bit Blockgröße
    10,5 MB/s

    RijandaelManaged (rein in C# geschrieben) 256 Bit Blockgröße
    13,9 MB/s

    RC6-32 128 Bit Blockgröße
    11,8 MB/s

    RC6-64 256 Bit Blockgröße
    14,7 MB/s

    HC-128
    15,1 MB/s

    Salsa20/12
    10,7 MB/s

    Chacha20
    11,8 MB/s

    Phelix
    12,7 MB/s

    Poly1305
    3,9 MB/s

    Übrigens es gibt weitere interessante Stromchiffren aus dem EStream-Wettbewerb wie Sosemanuk und Rabbit. An letzterem hab ich mich auch mal versucht, ist aber relativ kompliziert.

  12. Re: Die und ihr Chacha

    Autor: crypt0 19.07.15 - 17:10

    Okay, wundert mich ein bisschen... gerade Salsa20/12 im vergleich zum AES
    Hab auch mal kurz einen meiner speedtests angeworfen:

    BlockCipher: AES (key: 128)
    Transformed bytes: 16000000, Time: 261 ms
    -> 58.46279 MB/s

    BlockCipher: IDEA (key: 128)
    Transformed bytes: 8000000, Time: 218 ms
    -> 34.997223 MB/s

    BlockCipher: Serpent (key: 128)
    Transformed bytes: 16000000, Time: 609 ms
    -> 25.055483 MB/s

    StreamCipher: HC-128 (key: 128)
    Transformed bytes: 16000000, Time: 175 ms
    -> 87.193085 MB/s

    StreamCipher: HC-256 (key: 256)
    Transformed bytes: 16000000, Time: 235 ms
    -> 64.931015 MB/s

    StreamCipher: Salsa20 (key: 256)
    Transformed bytes: 16000000, Time: 298 ms
    -> 51.20399 MB/s

    StreamCipher: Salsa20/12 (key: 256)
    Transformed bytes: 16000000, Time: 242 ms
    -> 63.052845 MB/s

    StreamCipher: ChaCha20 (key: 256)
    Transformed bytes: 16000000, Time: 267 ms
    -> 57.149025 MB/s

    StreamCipher: ChaCha12 (key: 256)
    Transformed bytes: 16000000, Time: 153 ms
    -> 99.73065 MB/s

    Alles in Java implementiert (KEINE(!) crypto-provider) und per warm-up-phase durch hotspot optimiert... (Alles aus der IDE gestarted)
    AES absolut auf perfromance getrimmt, kann gerade so mit den streamciphers mithalten... Und HC128 und Chacha20/12 liegen bei mir recht na beinander

    Ja, Rabbit ist (imho) eine sehr interessante cipher, gerade in sachen performance sehr stark.

  13. Re: Die und ihr Chacha

    Autor: DerVorhangZuUndAlleFragenOffen 20.07.15 - 06:50

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Wer heute noch Algorithmen in Assembler programmiert sollte lieber
    > Kuhzüchter werden und die Finger vom Programmieren lassen.

    So ein Blödsinn. Sobald du SIMD ausnutzen willst kommst um Assembler bzw. Intrinsics nicht herum. Es gibt keinen C-Compiler der zuverlässig Konstellationen, in den SIMD helfen würde, erkennt und den Code entsprechend umbaut. Klar bei manchen ganz einfachen Sachen funktioniert es. Aber sobald der Code etwas komplizierter wird kannst du den Compiler in Bezug auf SIMD vergessen.

    "Entwickeln Sie ein positives Verhältnis zu Daten und freuen sie sich wenn wir mehr wissen!" ~Angela Merkel (12.06.2015)

  14. Re: Messwerte

    Autor: minnime 20.07.15 - 11:37

    Oh je, inspiriert durch deine wesentlich besseren Werte, hab ich mir nochmal meinen Benchmark angesehen, und einen fatalen Fehler entdeckt, nämlich dass es relativ ungünstig ist, jedes Byte einzeln aus dem Stream zu lesen. Wenn die Größe der auf einmal gelesenen Daten variiert wird, ändert sich das Verhältnis der Algorithmen stark, je nachdem welche Blockgröße die jeweils haben. Jetzt werden je 256 Bit gelesen. Da das Interface für den CryptoStream quasi Blockchiffren voraussetzen, hab ich die Stromchiffren mit 4 Byte Blockgröße angegeben, weil sie diese Größe pro Iteration zurückgeben. Als Gesamtdatenmenge werden 16MB verwendet.

    AES CryptoServiceProvider (Aufruf von Windows Bibliotheken) 128 Bit Blockgröße
    30,4 MB/s

    RijandaelManaged (rein in C# geschrieben) 256 Bit Blockgröße
    39 MB/s

    RC6-32 128 Bit Blockgröße
    37,5 MB/s

    RC6-64 256 Bit Blockgröße
    49,2 MB/s

    HC-128
    67,8 MB/s

    Salsa20/12
    22,5 MB/s

    Chacha20
    27,9 MB/s

    Phelix
    48,8 MB/s

    Poly1305
    10,1 MB/s

  15. Re: Messwerte

    Autor: crypt0 20.07.15 - 14:36

    minnime schrieb:
    --------------------------------------------------------------------------------
    > Oh je, inspiriert durch deine wesentlich besseren Werte, hab ich mir
    > nochmal meinen Benchmark angesehen, und einen fatalen Fehler entdeckt,
    > nämlich dass es relativ ungünstig ist, jedes Byte einzeln aus dem Stream zu
    > lesen.

    Ich hab mich schon gewundert auf welchem Rechner der Benchmark lief,
    mein i5-Notebook ist schließlich keine Höllenmaschine...
    Hast du die Daten von der Platte gelesen (inputstream) oder ver/entschlüsselst du immer den gleichen (16 / 32 byte) block? Letzteres ist bei meinem Benchmark der Fall, und wenn ich die Daten per BufferedStreams einlese ziehts die Performance schon runter (außer ich mach das Multi-threaded, dann bleibst einigermaßen stabil)

    Dass die stromciphers nicht noch etwas schneller sind wundert mich zwar trotzdem noch, aber viell. ist dein (bsp.) RC6 Code einfach besser durch JIT/Hotspot optimierbar...
    Aber allgemein schon erstaunlich was JIT so rausholen kann:
    Bei mir Chacha20/12 mit 155 MB/s und HC128 137 MB/s (jeweils mess-spitzen)

    Viell hab ich demnächst mal die Zeit, ne optimierte BigInteger klasse zu schreiben...
    So als CryptoInteger oder so... Der Poly1305 Durchsatz ist (muss man einfach so sagen) zu langsam! Und von modPow() für RSA oder DH will ich gar nicht erst anfangen...

  16. Re: Messwerte

    Autor: DerVorhangZuUndAlleFragenOffen 21.07.15 - 05:28

    Sind das alles Manged-Implementierungen (also ohne Unsafe) oder ist da nativer Code dabei? GitHub anyone?

    "Entwickeln Sie ein positives Verhältnis zu Daten und freuen sie sich wenn wir mehr wissen!" ~Angela Merkel (12.06.2015)

  17. Re: Die und ihr Chacha

    Autor: crypt0 21.07.15 - 09:17

    Jap, meine Implementierungen sind reiner Java-Code, keine nativen Aufrufe etc.
    Github kommt noch, ist alles noch nicht ordentlich dokumentiert und es fehlt an einigen Stellen noch was (util package, io package etc.) Aber wenn die grundstruktur des Frameworks komplett steht, findet mans auf github...

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. NETZSCH-Gerätebau GmbH, Selb
  2. Amt für Statistik Berlin-Brandenburg, Potsdam
  3. Wirtschaftsrat der CDU e.V., Berlin
  4. LOTTO Hessen GmbH, Wiesbaden

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 19,95€
  2. 2,99€
  3. 3,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Bug Bounty Hunter: Mit Hacker 101-Tutorials zum Millionär
Bug Bounty Hunter
Mit "Hacker 101"-Tutorials zum Millionär

Santiago Lopez hat sich als Junge selbst das Hacken beigebracht und spürt Sicherheitslücken in der Software von Unternehmen auf. Gerade hat er damit seine erste Million verdient. Im Interview mit Golem.de erzählt er von seinem Alltag.
Ein Interview von Maja Hoock

  1. White Hat Hacking In unter zwei Stunden in Universitätsnetzwerke gelangen

Kontist, N26, Holvi: Neue Banking-Apps machen gute Angebote für Freelancer
Kontist, N26, Holvi
Neue Banking-Apps machen gute Angebote für Freelancer

Ein mobiles und dazu noch kostenloses Geschäftskonto für Freiberufler versprechen Startups wie Kontist, N26 oder Holvi. Doch sind die Newcomer eine Alternative zu den Freelancer-Konten der großen Filialbanken? Ja, sind sie - mit einer kleinen Einschränkung.
Von Björn König


    Lightyear One: Luxus-Elektroauto fährt auch mit Solarstrom
    Lightyear One
    Luxus-Elektroauto fährt auch mit Solarstrom

    Ein niederländisches Jungunternehmen hat ein ungewöhnliches Fahrzeug entwickelt, das Luxus und Umweltfreundlichkeit kombiniert. Solarzellen auf dem Dach erhöhen die Reichweite um bis zu 220 Kilometer.
    Von Wolfgang Kempkens

    1. Elektromobilität EnBW will weitere 2.000 Schnellladepunkte errichten
    2. Elektromobilität Verkehrsminister will Elektroautos länger und mehr fördern
    3. Elektroautos e.GO Mobile liefert erste Fahrzeuge aus

    1. US-Boykott: Huawei bekommt Probleme bei SD-Karten und Drahtlosnetzen
      US-Boykott
      Huawei bekommt Probleme bei SD-Karten und Drahtlosnetzen

      Durch den Handelsboykott der USA gerät Huawei immer stärker unter Druck: Das chinesische Unternehmen könnte die Möglichkeit verlieren, seine Mobilegeräte nach den gängigen Standards für SD-Karten und Drahtlosnetzwerke zu bauen - oder zumindest mit den entsprechenden Logos zu werben.

    2. Apple: Update auf iOS 12.3.1 behebt Probleme mit VoLTE
      Apple
      Update auf iOS 12.3.1 behebt Probleme mit VoLTE

      Apple hat ohne öffentlichen Betatest ein Update für iOS veröffentlicht. Es löst mehrere Probleme, darunter einen ärgerlichen Bug mit Voice over LTE und zwei Fehler in der Nachrichten-App.

    3. Project Xcloud: Microsoft streamt Spiele mit Xbox-Blades
      Project Xcloud
      Microsoft streamt Spiele mit Xbox-Blades

      Entwickler müssen nichts am Code von Xbox-Spielen ändern, um sie auf den Servern von Microsoft zu streamen. Das hat Kareem Choudhry von Microsoft gesagt - und gleichzeitig eine neue API vorgestellt.


    1. 13:20

    2. 12:11

    3. 11:40

    4. 11:11

    5. 17:50

    6. 17:30

    7. 17:09

    8. 16:50