Unsinn

[the_crow]

Bei einer wirklich sicheren Lösung haben den Server-Anbieter die Klardaten nicht zu interessieren. Sie dürfen auf dem Server auch nie entschlüsselt werden (können), denn das ist Aufgabe des Clients oder eine Middleware die unter der Kontrolle des Nutzers steht.

Der Server (Cloud) darf also grundsätzlich schon vom Client nur verschlüsselte Daten bekommen!!!

[Versuchsperson]

> Der Server (Cloud) darf also grundsätzlich schon vom Client nur
> verschlüsselte Daten bekommen!!!

Hatte deinen Beitrag nicht wahrgenommen - und nahezu das selbe geschrieben. Es ist doch echt peinlich das die sich tatsächlich erdreisten solche nachweislich falschen Behauptungen zu verbreiten. Für mich grenzt solch eine Produktbeschreibung schon an Betrug!

[derdiedas]

Theoretisch stimmt das, praktisch geht das aus vielen Gründen nicht.

- Performance: on the fly ver und entschlüsselung überfordern die meisten mobilen Geräte

- Speicher: zum entschlüsseln muss die erst einmal nutzlose Datei entschlüsselt werden, was den Speicher doppelt belastet.

- Akkulaufzeit: Ver und Entschlüsselung sind performance intensiv und killen die Akkulaufzeit.

- Bandbreite: bei verschlüsselten Content funktionieren WAN-Optimizer nicht mehr was den Dienst noch teurer macht.

- Komplexe API denn nur APPs die direkt für die Nutzung dieser Cloud geschrieben werden funktionieren. Standard APPs können diesen Speicher nicht Nutzen.

usw...

Daher ist dieser Weg noch der beste der (derzeit) möglich ist.

[the_crow]

Ja, ich finde es auch bestenfalls unglücklich, dass seriöse IT Medien derart unreflektiert über Security-Themen berichten. Am Ende meinen schlecht informierte Entscheider, nach dem dem Lesen eines solchen Arikels tatsächlich, so eine Lösung wäre sicher... :-(

[the_crow]

derdiedas schrieb:
--------------------------------------------------------------------------------
> Theoretisch stimmt das, praktisch geht das aus vielen Gründen nicht.
>
> - Performance: on the fly ver und entschlüsselung überfordern die meisten
> mobilen Geräte

Das stimmt nicht. Jedes Smartphone kann heute Problemlos HTTPs-Verbindungen aufbauen, hier muss auch ver- und entschlüsselt werden. Die CPU-Last ist ganz sicher kein Engpass.

> - Speicher: zum entschlüsseln muss die erst einmal nutzlose Datei
> entschlüsselt werden, was den Speicher doppelt belastet.

Je nach Lösung. Wenn man uneffiziente Software entwickelt ist das so, sonst nicht! ;-)

> - Akkulaufzeit: Ver und Entschlüsselung sind performance intensiv und
> killen die Akkulaufzeit.

Siehe oben. CPU Last ist hier kein Engpass. Und selbst wenn der energieverbrauch ein paar Prozent steigt, ist das in den meisten Fällen besser als unsichere Software zu verwenden.

> - Bandbreite: bei verschlüsselten Content funktionieren WAN-Optimizer nicht
> mehr was den Dienst noch teurer macht.

!? Die Daten sind auch bei der im Artikel beschriebenen Lösung für die Übertragung verschlüsselt. Alles andere wäre unsicher.

> - Komplexe API denn nur APPs die direkt für die Nutzung dieser Cloud
> geschrieben werden funktionieren. Standard APPs können diesen Speicher
> nicht Nutzen.

Bei den Servern im Artikel gibt es keine Standard APIs. Bietet der Server nur "dummen" Speicherplatz lassen sich sehr wohl Standardschnittstellen nutzen.

[Ekelpack]

the_crow schrieb:
--------------------------------------------------------------------------------
> Der Server (Cloud) darf also grundsätzlich schon vom Client nur
> verschlüsselte Daten bekommen!!!

Es muss allerdings auch erst einmal irgendjemand Interesse an den Daten haben.

[the_crow]

Das ist natürlich richtig. Aber dann braucht man eben auch keine "sichere" Cloud.