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

Groups > comp.lang.c > #399057

Re: Is reallocarray() planned to be standardized?

Show all headers | View raw

In article <10u9m51$u6ms$1@dont-email.me>,
David Brown  <david.brown@hesbynett.no> wrote:
>On 16/05/2026 13:00, Janis Papanagnou wrote:
>> On 2026-05-16 11:38, David Brown wrote:
>>> On 16/05/2026 00:12, Scott Lurndal wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>> Iirc, a long time ago I kind of remember reading something about
>>>>> overwrite sensitive data multiple times (e.g., the DoD 5220.22-M
>>>>> standard for storage, though adapted for RAM), sometimes using a 
>>>>> pass of
>>>>> random data followed by a pass of fixed characters, or using a fast
>>>>> CSPRNG (like ChaCha20) to generate fast pseudo-random bytes so they
>>>>> don't deplete the physical TRNG.

(Just to be clear, I did not write the above text; earlier edits
kinda sorta could be read as if I did, but I've tried to clarify
attribution.)

>>>> Yes, that was normal when sanitizing disk platters, to ensure
>>>> no residual analog signal existed on the magnetic media that
>>>> could be teased out with a sillyscope or other analyzers.
>> 
>> During the early 1990's, working in a systems security department, we
>> purged the HDDs by triple-pass overwrite (I think zeroes, random, and
>> patterns, or so). It was mandated back then. There were also national
>> standards requiring that. (But the formal details evade my memories.)
>
>Yes, there have been all sorts of standards by all sorts of groups about 
>what needed to be done to "securely" erase disks.  Some of these were 
>completely pointless, like re-writing more than once - anything that 
>wasn't wiped the first time, such as redundant sectors or sectors marked 
>"bad", would not be affected by additional writes.  Some procedures were 
>not particularly good - a lot of magnet-based wipes were not very 
>effective, and there are companies that specialise in reading data from 
>physically damaged disks.

I can't help but feel like this discussion has been overcome by
events in the storage landscape.  Spinning rust is pretty old
technology, and storage media have changed.  With flash storage,
software at the host-level writing a bunch of bits to the device
may not "overwrite" much of anything: writes from the OS are
most often directed through a translation layer using bits on
device, to spread "wear" across available flash areas.  To
effectively "wipe" the device, you really need to get the FTL
involved, which means effectively asking the device's firmware
to do it for you.

If you really want to destroy the data, probably the best thing
to do is incinerate it and reduce it to ash, but that's got its
own problems.  Maybe that's appropriate for devices holding
state-level secrets, it's overkill from hiding your diary from
your kid sister.

>>> The only lab test of recovering zero overwritten data on a hard disk 
>>> managed to recover a small handful of bits, after several weeks of 
>>> work with a lab full of top-class equipment.  The risk of someone 
>>> reading data on a disk that was overwritten with zeros is non-existent
>> 
>> "a handful of bits" might already compromise security to an unacceptable 
>> degree. 
>
>No.  A very large handful of very specifically chosen bits might reveal 
>a tiny bit of the "we attack at dawn" secret.  A dozen bits scattered at 
>random across a 4 KB sector (I don't remember the size of their sample) 
>reveals nothing.

You have provided more context than explains your conclusion,
and I more or less agree.  But Janus's statement was not wrong
when written.  "A handful of bits" _could_ mean, "a fragment of
ASCII text" but if it's really truly just a few random bits
scattered at random, and not making up a larger quantity, then
yeah, that's pretty useless.

Here's a vignette about how small amounts of information _can_
be used to inadvertantly spill "secrets", however.  Maybe 20-ish
years ago, when I was working at Google, someone wrote a paper
about storage and presented it at a conference.  If I recall
correctly, it was something about how they replaced failed disks
in batches.  Anyway, at the time, Google was pretty tight-lipped
about the size of its fleet (much more is known about it now),
and the paper was carefully sanitized to remove exact quantities
of parts, and so forth.  But there was a graph that showed some
metric of interest; perhaps failures over time or something like
that.  Anyway, after the paper was published, someone outside of
google looked at the graph and said, "well, given the device
manufacturer's predicted MTBF and this graph, we can extrapolate
that they've got on the order of X hard disks...but that's a
huge number that is obviously wrong."  Ho ho; they were correct,
to within a factor of two, just two too small.  :-)

>> Also, it's not about whether it needs weeks or minutes. The cost
>> of the damage of a leak (or successful attack) is important. There's
>> sorts of data that are supposed to not be disclosed (even only partly or
>> only fragmentary) even after decades.
>
>Sure.
>
>But reading data from a hard disk block that has been re-written is not 
>a source of leaked information.
>
>>> - but that hasn't stopped people making money from selling multi-pass 
>>> software to the paranoid.
>> 
>> Spreading FUD is easy. But paying the damages because of sloppiness or
>> assuming false safety may be serious! Also if you delegate financial
>> responsibility to insurances, these companies have their requirements
>> that you have to follow and means to establish to minimize risks. All
>> based on scientific knowledge and practical evidence.
>
>The point is it was not in any way based on scientific knowledge or 
>practical evidence.  All scientific knowledge and practical evidence 
>available made it clear that reading an erased bit on a hard disk was 
>purely hypothetical, and totally implausible in practice.
>
>When someone higher up the food chain - insurance companies, men in 
>black, etc., - makes rules, then you have to follow them.  That does not 
>mean the rules are at all realistic.
>
>There are all sorts of ways that some amount of data can be recovered 
>from storage media that people throw away.  Using high-tech systems to 
>read bits that have been written over, is not one of them.

The rules don't always make sense, and are often dated.

I am reminded of the time when the US DoD banned the use of USB
flash drives, due to concerns about supply chain attacks through
auto-loaded Windows drivers.  I was in Afghanistan at the time,
and this came up in a Battalion staff meeting; we used computers
for all sorts of stuff, but the government supplied machines
were not great, and there weren't enough of them to go around:
the upshot was that _most_ people resorted to storing data on
USB flash keys out of necessity.  This ban obviously caused some
consternation, with some senior leaders in the Bn saying, "ok,
but what do we do instead?"  The answer was that USB _flash_
drives were banned, but USB _hard disks_ were OK, so use those
(you could buy them on the little PX on our FOB).  Listening to
the Battalion XO (a Marine Major) try to explain this was
painful.  I, one of the only people with industry experience
(having been called up from the reserves to deploy) just shook
my head.

	- Dan C.

(PS: any dumb rule in the military is the result of someone
doing the dumb thing.  "Ok Marines, do not tie the corners of
a PONCHO to your arms and legs and try to turn youself into a
HUMAN KITE during the coming Typhoon....Your three buddies
holding the rope tied around your waist will NOT precvent you
from SLAMMING into the deck"  [Yes, that happened. No, not me.])

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Is reallocarray() planned to be standardized? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-14 20:09 +0000
  Re: Is reallocarray() planned to be standardized? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-14 21:10 +0000
    Re: Is reallocarray() planned to be standardized? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-14 23:35 +0000
      Re: Is reallocarray() planned to be standardized? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-14 17:46 -0700
        Re: Is reallocarray() planned to be standardized? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-15 02:00 +0000
          Re: Is reallocarray() planned to be standardized? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-14 19:22 -0700
            Re: Is reallocarray() planned to be standardized? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-15 11:02 +0000
              Re: Is reallocarray() planned to be standardized? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-15 14:44 -0700
                Re: Is reallocarray() planned to be standardized? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-15 21:50 +0000
                Re: Is reallocarray() planned to be standardized? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-15 14:55 -0700
                Re: Is reallocarray() planned to be standardized? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-15 15:02 -0700
                Re: Is reallocarray() planned to be standardized? scott@slp53.sl.home (Scott Lurndal) - 2026-05-15 22:12 +0000
                Re: Is reallocarray() planned to be standardized? David Brown <david.brown@hesbynett.no> - 2026-05-16 11:38 +0200
                Re: Is reallocarray() planned to be standardized? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-16 13:00 +0200
                Re: Is reallocarray() planned to be standardized? David Brown <david.brown@hesbynett.no> - 2026-05-16 13:58 +0200
                Re: Is reallocarray() planned to be standardized? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-16 12:34 +0000
                Re: Is reallocarray() planned to be standardized? David Brown <david.brown@hesbynett.no> - 2026-05-16 16:25 +0200
                Re: Is reallocarray() planned to be standardized? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-16 12:32 -0700
                Re: Is reallocarray() planned to be standardized? David Brown <david.brown@hesbynett.no> - 2026-05-17 11:10 +0200
                Re: Is reallocarray() planned to be standardized? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-19 14:03 -0700
                Re: Is reallocarray() planned to be standardized? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-17 06:36 +0200
                Re: Is reallocarray() planned to be standardized? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-16 12:25 -0700
                Re: Is reallocarray() planned to be standardized? David Brown <david.brown@hesbynett.no> - 2026-05-17 11:12 +0200
                Re: Is reallocarray() planned to be standardized? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-17 02:26 -0700
                Leader Keith has spoken! (Was: Is reallocarray() planned to be standardized?) gazelle@shell.xmission.com (Kenny McCormack) - 2026-05-17 12:54 +0000
                Re: Is reallocarray() planned to be standardized? scott@slp53.sl.home (Scott Lurndal) - 2026-05-17 19:19 +0000
                Re: Is reallocarray() planned to be standardized? David Brown <david.brown@hesbynett.no> - 2026-05-17 21:53 +0200
                Re: Is reallocarray() planned to be standardized? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-17 20:30 +0000
                Re: Is reallocarray() planned to be standardized? David Brown <david.brown@hesbynett.no> - 2026-05-18 08:14 +0200
                Re: Is reallocarray() planned to be standardized? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-17 20:01 +0000
                Re: Is reallocarray() planned to be standardized? David Brown <david.brown@hesbynett.no> - 2026-05-18 09:13 +0200
                Re: Is reallocarray() planned to be standardized? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-18 09:51 +0200
                Re: Is reallocarray() planned to be standardized? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-18 14:34 +0000
                Re: Is reallocarray() planned to be standardized? David Brown <david.brown@hesbynett.no> - 2026-05-18 16:49 +0200
                Re: Is reallocarray() planned to be standardized? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-18 16:19 -0700
                Re: Is reallocarray() planned to be standardized? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-15 22:32 +0000
            Re: Is reallocarray() planned to be standardized? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-15 15:23 +0000
              Re: Is reallocarray() planned to be standardized? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-15 17:28 +0000
              Re: Is reallocarray() planned to be standardized? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-15 17:40 +0000
                Re: Is reallocarray() planned to be standardized? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-15 17:50 +0000
                Re: Is reallocarray() planned to be standardized? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-15 18:28 +0000
                Re: Is reallocarray() planned to be standardized? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-15 21:35 +0000
                Re: Is reallocarray() planned to be standardized? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-15 15:05 -0700
                Re: Is reallocarray() planned to be standardized? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-15 22:35 +0000
                Re: Is reallocarray() planned to be standardized? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-15 17:18 -0700
                Re: Is reallocarray() planned to be standardized? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-16 08:07 +0000
                Re: Is reallocarray() planned to be standardized? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-16 12:44 +0000
                Re: Is reallocarray() planned to be standardized? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-15 23:44 +0200
                Re: Is reallocarray() planned to be standardized? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-15 21:47 +0000
                Re: Is reallocarray() planned to be standardized? scott@slp53.sl.home (Scott Lurndal) - 2026-05-15 22:10 +0000
                Re: Is reallocarray() planned to be standardized? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-16 01:13 +0200
                AIX (was Re: Is reallocarray() planned to be standardized?) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-15 22:30 +0000
                Re: Is reallocarray() planned to be standardized? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-16 08:04 +0000
    Re: Is reallocarray() planned to be standardized? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-15 07:07 +0000
      Re: Is reallocarray() planned to be standardized? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-15 13:58 +0000
        Re: Is reallocarray() planned to be standardized? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-16 00:25 +0000
  Re: Is reallocarray() planned to be standardized? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-14 17:26 -0700
    Re: Is reallocarray() planned to be standardized? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-15 02:08 +0000
  Re: Is reallocarray() planned to be standardized? Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-16 11:28 +0200

csiph-web