Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > ger.ct > #385398 > unrolled thread

"Gehetzte Technologie"

Back to article view | Back to ger.ct

Contents

  "Gehetzte Technologie" Herwig AQSR <herwig.huener@t-online.de> - 2019-01-18 14:55 -0800
    Re: "Gehetzte Technologie" Andreas Fecht <forum@aftec.de> - 2019-01-19 00:32 +0100
    Re: "Gehetzte Technologie" Rainer Knaepper <rainerk@smial.prima.de> - 2019-01-19 11:48 +0100
      Re: "Gehetzte Technologie" Herwig AQSR <herwig.huener@t-online.de> - 2019-01-19 03:35 -0800
        Re: "Gehetzte Technologie" Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2019-01-19 13:18 +0100
          Re: "Gehetzte Technologie" Lars Gebauer <lars.gebauer@yahoo.de> - 2019-01-19 13:10 +0000
        Re: "Gehetzte Technologie" Rainer Knaepper <rainerk@smial.prima.de> - 2019-01-19 13:54 +0100
          Re: "Gehetzte Technologie" Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-01-19 14:04 +0100
            Re: "Gehetzte Technologie" Peter McD <peter.posts@gmx.net> - 2019-01-19 14:27 +0100
              Re: "Gehetzte Technologie" Hanno Foest <hurga-news2@tigress.com> - 2019-01-19 15:21 +0100
                Re: "Gehetzte Technologie" Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-01-19 15:47 +0100
                  Re: "Gehetzte Technologie" Dietz Proepper <dietz-news@rotfl.franken.de> - 2019-01-19 16:01 +0100
                    Re: "Gehetzte Technologie" Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-01-19 16:08 +0100
                      Re: "Gehetzte Technologie" spamfalle2@arcor.de (Marc Stibane) - 2019-01-19 16:33 +0100
                        Re: "Gehetzte Technologie" Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-01-19 16:40 +0100
                          Re: "Gehetzte Technologie" Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2019-01-19 16:55 +0100
                          Re: "Gehetzte Technologie" spamfalle2@arcor.de (Marc Stibane) - 2019-01-19 18:21 +0100
                            Re: "Gehetzte Technologie" Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-01-19 18:28 +0100
                      Re: "Gehetzte Technologie" Dietz Proepper <dietz-news@rotfl.franken.de> - 2019-01-19 18:26 +0100
                        Re: "Gehetzte Technologie" Hanno Foest <hurga-news2@tigress.com> - 2019-01-19 21:24 +0100
                          Re: "Gehetzte Technologie" Dietz Proepper <dietz-news@rotfl.franken.de> - 2019-01-20 11:24 +0100
              Re: "Gehetzte Technologie" Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-01-19 15:44 +0100
                Re: "Gehetzte Technologie" Peter McD <peter.posts@gmx.net> - 2019-01-19 22:38 +0100
          Re: "Gehetzte Technologie" Matthias Eißing <meissing@gmx.de> - 2019-01-19 14:13 +0100
            Re: "Gehetzte Technologie" Rainer Knaepper <rainerk@smial.prima.de> - 2019-01-20 03:56 +0100
    Re: "Gehetzte Technologie" Lars Gebauer <lars.gebauer@yahoo.de> - 2019-01-19 12:34 +0000
      Re: "Gehetzte Technologie" Frank Hucklenbroich <Hucklenbroich01@aol.com> - 2019-01-19 14:45 +0100
        Re: "Gehetzte Technologie" Siegfried Blos <usenet@siegfried-blos.de> - 2019-01-25 12:45 +0100
    Re: "Gehetzte Technologie" Frank Hucklenbroich <Hucklenbroich01@aol.com> - 2019-01-19 14:42 +0100
      Re: "Gehetzte Technologie" Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-01-19 15:43 +0100
        Re: "Gehetzte Technologie" Frank Hucklenbroich <Hucklenbroich01@aol.com> - 2019-01-19 20:10 +0100
          Re: "Gehetzte Technologie" Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-01-19 20:23 +0100
            Re: "Gehetzte Technologie" Frank Hucklenbroich <Hucklenbroich01@aol.com> - 2019-01-19 23:22 +0100
              Re: "Gehetzte Technologie" Ruediger Lahl <ruediger.lahl@gmx.de> - 2019-01-20 00:08 +0100
              Re: "Gehetzte Technologie" Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-01-20 08:21 +0100
          Re: "Gehetzte Technologie" Herwig AQSR <herwig.huener@t-online.de> - 2019-01-19 14:04 -0800
      Re: "Gehetzte Technologie" Andreas Fecht <forum@aftec.de> - 2019-01-19 23:21 +0100
        Re: "Gehetzte Technologie" Herwig AQSR <herwig.huener@t-online.de> - 2019-01-19 15:59 -0800
          Re: "Gehetzte Technologie" Andreas Fecht <forum@aftec.de> - 2019-01-20 10:56 +0100

Page 1 of 2  [1] 2  Next page →

#385398 — "Gehetzte Technologie"

2019-01-18 23:56:00 +0100

Ein neuer Begriff, ein alter SachVerhalt.

Manchmal kommt es vor, dass eine neue
Technologie eine alte ablöst (ach was?!).
Dann hat man manchmal die Beobachtung,
dass die Protagonisten der alten
Technologie noch mal einen Spurt
drauflegen. Beispiel: Das SegelSchiff
erreichte seine höchste Blüte, als bereits
klar war, dass das DampfSchiff das Rennen
machen würde. Nie vorher hat es so
leistungsfähige Clipper gegeben. Und
danach nur für Millionäre zum Spielen,
und das gildet ja nicht.

GegenBeispiel: der Röhren-NF-EndVerstärker.
Oder die Analoge SchallPlatte. Es gibt
Leute, die schwören auf die höhere Qualität
derselben, obwohl eigentlich jedem klar
ist, dass Elektronik mit Röhren einfach
nur eine teure ElektroHeizung ist, und
SchallPlatten nur dazu taugen, Diamanten
auf Abrieb zu testen. Digitale NF-Technik
hat längst gewonnen, like it or not.

Gibt es also das Prinzip der "Gehetzten
Technologie", oder gibt es es nicht?

Heute marschierte ich in MühlDorf an einem
"BettenLager" vorbei - gleissend helle
VerkaufsRäume. Jede Menge LeuchtStoffRöhren
- alle gleich, und alle gleich hell. Ich
nahm an, dass es sich schon um LED-Replica
handelte, aber aus der Nähe betrachtet waren
die Abdampfungen der Elektroden deutlich zu
erkennen - also LeuchtStoffRöhren. Wie in
der SteinZeit: GasEntladungen. Nur eben neu
- alle. Ob IKEA Aktien einer
QueckSilber-Mine hält?

Technologisch haben die LED das Rennen um
die Effiziens schon gewonnen - aber es gibt
kein NaturGesetz, das verbietet, aus einer
LeuchtStoffRöhre noch mehr rauszuholen. Und
nebenbei: hier in dieser NG habe ich einmal
das Prinzip der "Planck-Lampe" vorgestellt,
die mit glühenden Gegenständen Licht mit
100 Prozent Effizienz erzeugt - ein
theoretisches Konzept, das aber keinen
bekannten NaturGesetzen widerspricht.
Wenn jemand den technologischen DurchBruch
erzielt - die gehetzte GlühBirne kann man
es vielleicht nennen - dann ist die PlanckLampe
die Gewinnerin in Sachen Effizienz, und wir
können uns hier wieder daran delektieren,
dass die Politik nicht mehr mitkommt.

Also das Prinzip der "Gehetzten Technologie":
gibt es ausser SegelSchiffen noch weitere
Beispiele?

Mir würde einfallen: Das Buch. Wenn es denn
jemand druckt, aber das hat es mit
SegelSchiffen gemein. Und statt HaushaltsRoboter:
die Fr<BackSpace> verlassen wir das Thema
an dieser Stelle, sonst wird's polemisch.

Herwig

[toc] | [next] | [standalone]

#385400

Am 18.01.2019 um 23:55 schrieb Herwig AQSR:
> 2019-01-18 23:56:00 +0100

> GegenBeispiel: der Röhren-NF-EndVerstärker.
> Oder die Analoge SchallPlatte. Es gibt
> Leute, die schwören auf die höhere Qualität
> derselben, obwohl eigentlich jedem klar
> ist, dass Elektronik mit Röhren einfach
> nur eine teure ElektroHeizung ist, und
> SchallPlatten nur dazu taugen, Diamanten
> auf Abrieb zu testen. Digitale NF-Technik
> hat längst gewonnen, like it or not.

Es gibt schon noch ein paar Argumente _für_ Röhrenverstärker.

Für den direkten Vergleich hab' ich da mal was vorbereitet:

https://zeuch.vetter-und-fecht.de/SpiceTAmp/

Gruß Andreas

[toc] | [prev] | [next] | [standalone]

#385420

herwig.huener@t-online.de (Herwig AQSR)  am 18.01.19 um 14:55:
> Fr<BackSpace>

Fr<Backspace> nicht gefunden. Meinten Sie Fr^W?

Gehetzte Technologie: Spiegelreflexkameras.

Aber wie bei den Segelschiffen und Schallplatten: Die wird es in
kleinem Rahmen noch sehr, sehr lange geben.

Rainer

-- 
'Office-Produkte' wurden für den Bedarf von Heim- und SOHO-Anwendern
geschrieben. Und so sollte man sie auch betrachten. Quasi als
'fortgeschrittene Kartoffeldruckerei für zuhause'.
(Benedict Mangelsdorff in ger.ct)

[toc] | [prev] | [next] | [standalone]

#385427

2019-01-19 12:36:00 +0100

> ...

> Gehetzte Technologie: Spiegelreflexkameras.

Yepp. Und überhaupt alle chemischen FotoRessourcen.

> Aber wie bei den Segelschiffen und Schallplatten: Die wird es in
> kleinem Rahmen noch sehr, sehr lange geben.

Und es wird jemand behaupten, das sei viel besser
als das digitalisierte Zeug.

(Erinnert sich noch jemand an die Anzeige von
Intel selbst, die sich zu der Behauptung verstieg,
mit Intel-Prozessoren seien die Farben auf einem
PC viel frischer und kräftiger? Und sie meinten
nicht die Verpackung!)

Herwig (morning reboot)

[toc] | [prev] | [next] | [standalone]

#385441

Am 19.01.19 um 12:35 schrieb Herwig AQSR:

> Yepp. Und überhaupt alle chemischen FotoRessourcen.
> 
>> Aber wie bei den Segelschiffen und Schallplatten: Die wird es in
>> kleinem Rahmen noch sehr, sehr lange geben.
> 
> Und es wird jemand behaupten, das sei viel besser
> als das digitalisierte Zeug.

In mancher Hinsicht ist es das.
Es macht als Hobby mehr Spaß. Die Geräte halten Jahrzehnte und lassen 
sich bei Bedarf sogar reparieren. Es gibt kein DRM. Es gibt keine 
ständig wechselnden Standards, die zum Neukauf zwingen. Es gibt keine 
Abhängigkeit von einer Cloud, die nach wenigen Jahren den Betrieb 
einstellt. Es ist eine einfache Technologie, die Krisenzeiten überleben 
und von zukünftigen Generationen rekonstruiert werden kann.

Unsere Epoche wird noch als schwarzes Loch in die Geschichte eingehen, 
weil die meisten Dokumente und Kulturgüter in proprietären Datenformaten 
verschlüsselt auf extrem kurzlebigen Datenträgern abgelegt wurden...

> (Erinnert sich noch jemand an die Anzeige von
> Intel selbst, die sich zu der Behauptung verstieg,
> mit Intel-Prozessoren seien die Farben auf einem
> PC viel frischer und kräftiger? Und sie meinten
> nicht die Verpackung!)

Wenn ich mich recht erinnere, hing das mit der Einführung von MMX 
zusammen. Und war gar nicht sooo falsch, denn dadurch wurde es erstmals 
möglich, qualitativ hochwertige Videoformate ohne Spezialhardware auf 
normalen PCs wiederzugeben.

Hergen

[toc] | [prev] | [next] | [standalone]

#385452

* Hergen Lehmann:
> Am 19.01.19 um 12:35 schrieb Herwig AQSR:
>>> Aber wie bei den Segelschiffen und Schallplatten: Die wird es in
>>> kleinem Rahmen noch sehr, sehr lange geben.
>> 
>> Und es wird jemand behaupten, das sei viel besser
>> als das digitalisierte Zeug.
>
> In mancher Hinsicht ist es das.

Ist ein Ölgemälde besser als ein Aquarell? Oder umgekehrt?

Es ist nicht besser, es ist /anders/. Für manche Zwecke besser
geeignet. Für andere nicht.

Fotografie ist auch nicht "besser" als Malerei. Fotografie ist
vielmehr eine prima Ergänzung. Genau so wie jetzt die digitale
Fotografie.

[toc] | [prev] | [next] | [standalone]

#385448

herwig.huener@t-online.de (Herwig AQSR)  am 19.01.19 um 03:35:
> 2019-01-19 12:36:00 +0100

>> ...

>> Gehetzte Technologie: Spiegelreflexkameras.

> Yepp. Und überhaupt alle chemischen FotoRessourcen.

Oh, sorry, ich meinte DSLR. Die chemischen sind schon lange nur noch
was für Liebhaber und Spezialaufgaben.

>> Aber wie bei den Segelschiffen und Schallplatten: Die wird es in
>> kleinem Rahmen noch sehr, sehr lange geben.

> Und es wird jemand behaupten, das sei viel besser
> als das digitalisierte Zeug.

Manchmal hat digital technische Nachteile und bei manchen speziellen
Aufgaben gibt es nix digitales.

Ich habe jedenfalls noch keinen 8*10" Digitalsensor gesehen.

> (Erinnert sich noch jemand an die Anzeige von
> Intel selbst, die sich zu der Behauptung verstieg,
> mit Intel-Prozessoren seien die Farben auf einem
> PC viel frischer und kräftiger? Und sie meinten
> nicht die Verpackung!)

Da war mal was, ja.

Aber Intel verspricht ja auch jedes Jahr revolutionäre
Leistungssteigerungen. Seit geraumer Zeit ist ja dieses "optane" zeugs
der heiße Scheiß.

Ja, man kann damit in einigen Szenarios eine gewisse Beschleunigung
messen.

Btw: SSD können, wenn sie sehr vollgelaufen sind, (nicht) überraschend
langsam werden.

Rainer

-- 
Na gut, vielleicht waren in meinem Posting auch zu viele lange Sätze
(Dieter Goost in ger.ct)

[toc] | [prev] | [next] | [standalone]

#385450

On 1/19/19 1:54 PM, Rainer Knaepper wrote:
> 
> Btw: SSD können, wenn sie sehr vollgelaufen sind, (nicht) überraschend
> langsam werden.

Deshalb lasse icb beim Partionieren immer ein paar GB unbenutzt. Damit 
hat der Controller immer einen Pool von Blöcken von denen er weiss, daß 
sie unbenutzt sind.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#385456

Am 19.01.19 um 14:04 schrieb Gerrit Heitsch:
> On 1/19/19 1:54 PM, Rainer Knaepper wrote:
>>
>> Btw: SSD können, wenn sie sehr vollgelaufen sind, (nicht) überraschend
>> langsam werden.
> 
> Deshalb lasse icb beim Partionieren immer ein paar GB unbenutzt. Damit 
> hat der Controller immer einen Pool von Blöcken von denen er weiss, daß 
> sie unbenutzt sind.
> 

Ich denke, dem SSD Controller ist Dein Partitionsschema wurscht.

Aus der c't
"Die SSD nutzt den ungenutzten Speicher ohnehin – ob er nun einer 
Partition zugeordnet ist oder nicht."
https://www.heise.de/ct/artikel/SSD-Lebensdauer-Antworten-auf-die-wichtigsten-Fragen-3849412.html

Peter

[toc] | [prev] | [next] | [standalone]

#385467

Am 19.01.19 um 14:27 schrieb Peter McD:

>>> Btw: SSD können, wenn sie sehr vollgelaufen sind, (nicht) überraschend
>>> langsam werden.
>>
>> Deshalb lasse icb beim Partionieren immer ein paar GB unbenutzt. Damit 
>> hat der Controller immer einen Pool von Blöcken von denen er weiss, 
>> daß sie unbenutzt sind.
> 
> Ich denke, dem SSD Controller ist Dein Partitionsschema wurscht.
> 
> Aus der c't
> "Die SSD nutzt den ungenutzten Speicher ohnehin – ob er nun einer 
> Partition zugeordnet ist oder nicht."

Wenn der Speicher einer Partition zugeordnet ist, dann ist er aber nach 
dem vollschreiben nicht mehr ungenutzt.

Ob sich das nach dem Löschen wieder bessert, hängt vermutlich vom 
Einsatz von TRIM ab. Was aber bei Vollverschlüsselung wieder 
problematisch sein kann.  (Machen RAID Controller eigentlich TRIM?)

Ich laß ebenfalls lieber was bei SSDs frei...

Hanno

[toc] | [prev] | [next] | [standalone]

#385471

On 1/19/19 3:21 PM, Hanno Foest wrote:
> Am 19.01.19 um 14:27 schrieb Peter McD:
> 
>>>> Btw: SSD können, wenn sie sehr vollgelaufen sind, (nicht) überraschend
>>>> langsam werden.
>>>
>>> Deshalb lasse icb beim Partionieren immer ein paar GB unbenutzt. 
>>> Damit hat der Controller immer einen Pool von Blöcken von denen er 
>>> weiss, daß sie unbenutzt sind.
>>
>> Ich denke, dem SSD Controller ist Dein Partitionsschema wurscht.
>>
>> Aus der c't
>> "Die SSD nutzt den ungenutzten Speicher ohnehin – ob er nun einer 
>> Partition zugeordnet ist oder nicht."
> 
> Wenn der Speicher einer Partition zugeordnet ist, dann ist er aber nach 
> dem vollschreiben nicht mehr ungenutzt.
> 
> Ob sich das nach dem Löschen wieder bessert, hängt vermutlich vom 
> Einsatz von TRIM ab. Was aber bei Vollverschlüsselung wieder 
> problematisch sein kann.  (Machen RAID Controller eigentlich TRIM?)

Man soll auch bei NVMe-SSDs kein TRIM benutzen, haben zumindest einige 
Dokus behauptet als ich hier das System aufgesetzt habe.

Zumindest die WDC-SSD hier mag TRIM auch nicht, wenn man es versucht 
gibts einen Hänger und IO-MMU-Fehlermeldungen.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#385475

Gerrit Heitsch wrote:

> On 1/19/19 3:21 PM, Hanno Foest wrote:
>> Ob sich das nach dem Löschen wieder bessert, hängt vermutlich vom
>> Einsatz von TRIM ab. Was aber bei Vollverschlüsselung wieder
>> problematisch sein kann.  (Machen RAID Controller eigentlich TRIM?)
> 
> Man soll auch bei NVMe-SSDs kein TRIM benutzen, haben zumindest einige
> Dokus behauptet als ich hier das System aufgesetzt habe.

$hier tut eine NVMe-SSD mit TRIM ohne Probleme und mit Vollverschlüsselung.

-- 
CASE NIGHTMARE GREEN

[toc] | [prev] | [next] | [standalone]

#385476

On 1/19/19 4:01 PM, Dietz Proepper wrote:
> Gerrit Heitsch wrote:
> 
>> On 1/19/19 3:21 PM, Hanno Foest wrote:
>>> Ob sich das nach dem Löschen wieder bessert, hängt vermutlich vom
>>> Einsatz von TRIM ab. Was aber bei Vollverschlüsselung wieder
>>> problematisch sein kann.  (Machen RAID Controller eigentlich TRIM?)
>>
>> Man soll auch bei NVMe-SSDs kein TRIM benutzen, haben zumindest einige
>> Dokus behauptet als ich hier das System aufgesetzt habe.
> 
> $hier tut eine NVMe-SSD mit TRIM ohne Probleme und mit Vollverschlüsselung.

Dann ist TRIM allerdings kontraproduktiv denn dadurch ist erkennbar wo 
interessantes liegt und was leer ist.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#385480

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
> On 1/19/19 4:01 PM, Dietz Proepper wrote:

>> $hier tut eine NVMe-SSD mit TRIM ohne Probleme und mit
>> Vollverschlüsselung.
> Dann ist TRIM allerdings kontraproduktiv denn dadurch ist erkennbar wo
> interessantes liegt und was leer ist.

Was hat ein Angreifer davon wenn er sieht dass 10% der SSD leer sind?

Außerdem könnte die SSD ja auch lediglich intern speichern welcher Block
frei ist, den aber nicht anfassen solange sie ihn nicht braucht. Der
Angreifer sieht nach wie vor nur verschlüsselte Blocks beim Lesen (der
kann ja die interne Liste der freien Blocks nicht auslesen), aber die
SSD kann Blocks remappen.


-- 
In a world without walls and fences,
   who needs windows and gates?

[toc] | [prev] | [next] | [standalone]

#385483

On 1/19/19 4:33 PM, Marc Stibane wrote:
> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>> On 1/19/19 4:01 PM, Dietz Proepper wrote:
> 
>>> $hier tut eine NVMe-SSD mit TRIM ohne Probleme und mit
>>> Vollverschlüsselung.
>> Dann ist TRIM allerdings kontraproduktiv denn dadurch ist erkennbar wo
>> interessantes liegt und was leer ist.
> 
> Was hat ein Angreifer davon wenn er sieht dass 10% der SSD leer sind?

Bei Verschlüsselung ist jedes bisschen Information für den Angreifer zu 
vermeiden. Er soll möglichst viel Arbeit haben.


> Außerdem könnte die SSD ja auch lediglich intern speichern welcher Block
> frei ist, den aber nicht anfassen solange sie ihn nicht braucht.

Das ist sinnlos, denn was die Zeit braucht ist einen Block zu löschen 
und wieder verwendbar zu machen. Daher TRIM, damit werden unbenutzte 
Blöcke gelöscht und sind sofort verfügbar wenn man sie braucht.

Aktuelle Firmware benutzt GarbageCollection, bekannt unbenutzte Blöcke 
werden gelöscht wenn der Controller Zeit hat. Und hier kommt der 
unpartitionierte Bereich ins Spiel. Damit hat der Controller immer ein 
paar GB bekannt unbenutzte Blöcke die er bei Bedarf benutzen kann und 
die, die er ersetzt landen wieder dort und werden gelöscht wenn sonst 
nichts anliegt.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#385484

Am 19.01.19 um 16:40 schrieb Gerrit Heitsch:

> On 1/19/19 4:33 PM, Marc Stibane wrote:
>> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>>> Dann ist TRIM allerdings kontraproduktiv denn dadurch ist erkennbar wo
>>> interessantes liegt und was leer ist.
>>
>> Was hat ein Angreifer davon wenn er sieht dass 10% der SSD leer sind?
> 
> Bei Verschlüsselung ist jedes bisschen Information für den Angreifer zu 
> vermeiden. Er soll möglichst viel Arbeit haben.

Das ist aber eher akademisch.
Ein realer Angreifer wird sich erst mal über den Superblock des 
Filesystems her machen, denn dieser ist nicht nur am leichtesten zu 
entschlüsseln (bekannte Position, known plaintext), sondern liefert auch 
wichtige Informationen für die weitere Analyse. Nachdem dieser Block 
geknackt ist, liegt dann auch schnell die Freiliste offen.

>> Außerdem könnte die SSD ja auch lediglich intern speichern welcher Block
>> frei ist, den aber nicht anfassen solange sie ihn nicht braucht.
> 
> Das ist sinnlos, denn was die Zeit braucht ist einen Block zu löschen 
> und wieder verwendbar zu machen. Daher TRIM, damit werden unbenutzte 
> Blöcke gelöscht und sind sofort verfügbar wenn man sie braucht.
> 
> Aktuelle Firmware benutzt GarbageCollection, bekannt unbenutzte Blöcke 
> werden gelöscht wenn der Controller Zeit hat. Und hier kommt der 
> unpartitionierte Bereich ins Spiel. Damit hat der Controller immer ein 
> paar GB bekannt unbenutzte Blöcke die er bei Bedarf benutzen kann und 
> die, die er ersetzt landen wieder dort und werden gelöscht wenn sonst 
> nichts anliegt.

ACK.

Hergen

[toc] | [prev] | [next] | [standalone]

#385496

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
> On 1/19/19 4:33 PM, Marc Stibane wrote:
>> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:

>>> Dann ist TRIM allerdings kontraproduktiv denn dadurch ist erkennbar
>>> wo interessantes liegt und was leer ist.
>> Was hat ein Angreifer davon wenn er sieht dass 10% der SSD leer sind?
> Bei Verschlüsselung ist jedes bisschen Information für den Angreifer zu
> vermeiden. Er soll möglichst viel Arbeit haben.

10% gespart ist irrelevant. Vor allem weil ja eh - wie Hergen schrub -
vom SuperBlock ausgehend vorwärts gesucht werden kann.


>> Außerdem könnte die SSD ja auch lediglich intern speichern welcher
>> Block frei ist, den aber nicht anfassen solange sie ihn nicht
>> braucht.
> Das ist sinnlos, denn was die Zeit braucht ist einen Block zu löschen
> und wieder verwendbar zu machen.

Es geht bei TRIM doch nicht um Zeit...

> Daher TRIM, damit werden unbenutzte Blöcke gelöscht und sind sofort
> verfügbar wenn man sie braucht.

Der Sinn und Zweck von TRIM ist es, dem Controller mehr Blöcke für das
Wear-Leveling zu geben.



> Aktuelle Firmware benutzt GarbageCollection, bekannt unbenutzte Blöcke
> werden gelöscht wenn der Controller Zeit hat. Und hier kommt der 
> unpartitionierte Bereich ins Spiel. Damit hat der Controller immer ein
> paar GB bekannt unbenutzte Blöcke die er bei Bedarf benutzen kann und
> die, die er ersetzt landen wieder dort und werden gelöscht wenn sonst
> nichts anliegt.

Kann man bei unverschlüsselten SSDs ja machen. Verschlüsselte SSDs
sollten das entweder unterlassen (aber trotzdem TRIM für Wear-Leveling
nutzen), oder aber man pfeift auf die paar Prozent weniger Arbeit für
Angreifer.

-- 
In a world without walls and fences,
   who needs windows and gates?

[toc] | [prev] | [next] | [standalone]

#385500

On 1/19/19 6:21 PM, Marc Stibane wrote:
> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>> On 1/19/19 4:33 PM, Marc Stibane wrote:
>>> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
> 
>>>> Dann ist TRIM allerdings kontraproduktiv denn dadurch ist erkennbar
>>>> wo interessantes liegt und was leer ist.
>>> Was hat ein Angreifer davon wenn er sieht dass 10% der SSD leer sind?
>> Bei Verschlüsselung ist jedes bisschen Information für den Angreifer zu
>> vermeiden. Er soll möglichst viel Arbeit haben.
> 
> 10% gespart ist irrelevant. Vor allem weil ja eh - wie Hergen schrub -
> vom SuperBlock ausgehend vorwärts gesucht werden kann.
> 
> 
>>> Außerdem könnte die SSD ja auch lediglich intern speichern welcher
>>> Block frei ist, den aber nicht anfassen solange sie ihn nicht
>>> braucht.
>> Das ist sinnlos, denn was die Zeit braucht ist einen Block zu löschen
>> und wieder verwendbar zu machen.
> 
> Es geht bei TRIM doch nicht um Zeit...

Doch, darum geht es. Ohne Trim funktioniert die SSD auch, nur wird sie 
irgendwann langsam wenn dem Comtroller die ungelöschten Blöcke ausgehen.


>> Daher TRIM, damit werden unbenutzte Blöcke gelöscht und sind sofort
>> verfügbar wenn man sie braucht.
> 
> Der Sinn und Zweck von TRIM ist es, dem Controller mehr Blöcke für das
> Wear-Leveling zu geben.

Die hat er auch so. Aber er braucht eben Zeit die noch nicht gelöschten 
Blöcke zu löschen bevor er sie benutzen kann. Das bremst.


>> Aktuelle Firmware benutzt GarbageCollection, bekannt unbenutzte Blöcke
>> werden gelöscht wenn der Controller Zeit hat. Und hier kommt der
>> unpartitionierte Bereich ins Spiel. Damit hat der Controller immer ein
>> paar GB bekannt unbenutzte Blöcke die er bei Bedarf benutzen kann und
>> die, die er ersetzt landen wieder dort und werden gelöscht wenn sonst
>> nichts anliegt.
> 
> Kann man bei unverschlüsselten SSDs ja machen. Verschlüsselte SSDs
> sollten das entweder unterlassen (aber trotzdem TRIM für Wear-Leveling
> nutzen), oder aber man pfeift auf die paar Prozent weniger Arbeit für
> Angreifer.

Da man die vom Controller angebotene Verschlüsselung nicht benutzt ist 
das nicht relevant. Das OS macht das selber, idealerweise mit einer 
Software deren Source verfügbar ist. Verschlüsselung im Laufwerk selbst 
ist schon mehr als einmal durch fehlerhafte Implementierung aufgefallen.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#385501

Gerrit Heitsch wrote:

> On 1/19/19 4:01 PM, Dietz Proepper wrote:
>> Gerrit Heitsch wrote:
>> 
>>> On 1/19/19 3:21 PM, Hanno Foest wrote:
>>>> Ob sich das nach dem Löschen wieder bessert, hängt vermutlich vom
>>>> Einsatz von TRIM ab. Was aber bei Vollverschlüsselung wieder
>>>> problematisch sein kann.  (Machen RAID Controller eigentlich TRIM?)
>>>
>>> Man soll auch bei NVMe-SSDs kein TRIM benutzen, haben zumindest einige
>>> Dokus behauptet als ich hier das System aufgesetzt habe.
>> 
>> $hier tut eine NVMe-SSD mit TRIM ohne Probleme und mit Vollverschlüsselung.
> 
> Dann ist TRIM allerdings kontraproduktiv denn dadurch ist erkennbar wo
> interessantes liegt und was leer ist.

Mir langt Verschlüsselung. Ich brauche keine deniability.

-- 
CASE NIGHTMARE GREEN

[toc] | [prev] | [next] | [standalone]

#385518

Am 19.01.19 um 18:26 schrieb Dietz Proepper:

>> Dann ist TRIM allerdings kontraproduktiv denn dadurch ist erkennbar wo
>> interessantes liegt und was leer ist.
> 
> Mir langt Verschlüsselung. Ich brauche keine deniability.

Ist wohl nicht nur deniability - siehe

https://www.saout.de/pipermail/dm-crypt/2012-April/002420.html

Das Informationsleck ist zwar offenbar gering, aber der Nutzen von TRIM 
auch, oder? Ich bin kein Kryptologe und kann das Risiko daher nicht 
einschätzen, entsprechend irre ich lieber auf der sicheren Seite. YMMV.

Hanno

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | ger.ct

csiph-web