User Cero | chat.stackexchange.com

Cero

yst 13:57

@ThoriumBR Thanks for the suggestion! I’ll definitely explore erasure codes—it seems like a practical way to achieve redundancy and security without reinventing the wheel. Do you have any recommended libraries or implementations that are reliable for production use?

Cero

yst 13:29

@ThoriumBR Good point, ThoriumBR! Agreed, security must always come first—slow or broken systems defeat the whole purpose. My thought was more about exploring whether adding a dynamic mapping layer could increase complexity for attackers without significantly hurting performance.

But you’re right, if Tahoe-LAFS already achieves a similar level of protection efficiently, maybe I should study it deeply before overcomplicating things. Thanks for the honest insight—it really helps me refine my approach.

Cero

yst 13:25

@ThoriumBR Agreed, security should never be compromised for performance. My approach tries to ensure security first, with performance as a secondary optimization. But your point is valid — adding unnecessary layers might risk stability if not carefully designed. I’ll definitely keep this balance in mind while refining the concept.

Cero

yst 13:17

@ThoriumBR Good point! I agree, adding extra layers can indeed degrade performance if not carefully designed. My intention was to explore whether a dynamic mapping layer could add security without heavily impacting system efficiency. But you’re right, I should look deeper into Tahoe-LAFS—it might achieve similar goals natively without the extra complexity. Thanks for the suggestion!

Cero

yst 08:34

@ThoriumBR Thanks! Yes, full-disk encryption does address most offline dump risks, and Tahoe-LAFS is indeed an interesting approach for distributed trust. My idea was exploring whether adding a dynamic mapping layer could add any extra resilience in partial-snapshot scenarios, but I’ll definitely review Tahoe-LAFS more closely—it might already achieve a similar goal.

Cero

Thu 09:41

Yeah, sounds like Shamir’s Secret Sharing. Cool idea—maybe adapting that for snapshots could work too, where only n valid time-window parts reconstruct the full context.

Cero

Thu 09:39

@Journeyman, Fair point 😅 – if they have consistent file system access, yeah, no magic layer will save you. My angle was more about attackers getting only periodic offline dumps or stolen drives, not live ongoing access. In that limited snapshot scenario, maybe some extra friction is possible.

Cero

Thu 09:36

@Journeyman, Thanks! That makes sense if we consider normal SSD behavior. I was just wondering if attackers with only periodic offline snapshots (not live system access) might still face extra complexity with a shifting logical mapping layer. Or do you think SSD wear-leveling already randomizes data enough that such snapshots wouldn’t give any meaningful advantage to an attacker either way?

Cero

Thu 09:31

Good point! True, SSDs inherently fragment data for wear leveling and performance. But my idea is more about adding a logical, shifting mapping layer (on top of the physical behavior) so even if SSD-level data is copied, the context to reconstruct a full file changes over time. Do you think this adds any practical security, or would SSD-level fragmentation already make it redundant?

Cero

Thu 09:05

Hi everyone, I’m exploring a security concept and would love your quick thoughts.
The idea: What if files didn’t exist as fixed, static objects but as “floating” fragments mapped dynamically (mapping changes per session or over time)?
Goal: making stolen periodic snapshots harder to reconstruct into a full usable file.
Does this add any meaningful security over TPM/HSM-backed encryption, or is it just complexity without gain?

Cero

The DMZ