9

When you run luksDump on a LUKS device, I get this:

$ sudo cryptsetup luksDump /dev/sda1 
LUKS header information
Version:        2
Epoch:          3
Metadata area:  16384 [bytes]
Keyslots area:  16744448 [bytes]
UUID:           4640c6e4-[…]
Label:          (no label)
Subsystem:      (no subsystem)
Flags:          (no flags)
[…]

I’s quite obvious what “version” refers to (the current best is v2, so this is what you should aim for) and I’ve seen values for Epoch from 3 to 5.

However, what does Epoch refer to, actually? And what value should I aim at? Does it matter (security-wise) what number is stated there? Is it bad if it is still Epoch 3 e.g.? Can one upgrade that Epoch?

I’ve searched the web and the FAQ for information, but the word epoch is not mentioned there.

rugk
  • 2,806
  • 6
  • 28
  • 58

2 Answers2

15

The Epoch increases every time you change anything in your LUKS header (like when adding or removing keys, etc.).

The LUKS2 header specification states:

uint64_t seqid; // sequence ID, increased on update

seqid is a counter (sequential number) that is always increased when a new update of the header is written. The header with a higher seqid is more recent and is used for recovery (if there are primary and secondary headers with different seqid, the more recent one is automatically used).

Why this is called a "sequence ID" in code and technical documentation, but uses the term "Epoch" when shown to the end user, remains a mystery.

That it is in fact the same thing, can be seen if you read the fine source, which prints seqid as Epoch:

log_std(cd, "Epoch:         \t%" PRIu64 "\n", hdr->seqid);

tl;dr You can safely ignore the Epoch, it is a harmless counter with no specific meaning.

frostschutz
  • 47,228
  • 5
  • 112
  • 159
-7

I disagree - RE: tl;dr You can safely ignore the Epoch, it is a harmless counter with no specific meaning.

It does have a specific meaning:

In computing, an epoch is a date and time from which a computer measures system time. Most computer systems determine time as a number representing the seconds removed from particular arbitrary date and time. For instance, Unix and POSIX measure time as the number of seconds that have passed since 1 January 1970 00:00:00 UT, a point in time known as the Unix epoch. The NT time epoch on Windows NT and later refers to the Windows NT system time in (10^-7)s intervals from 0h 1 January 1601

According to the source code for LUKS (lib/bitlk/bitlk.c) contains the following constant:

#define EPOCH_AS_FILETIME 116444736000000000

Using a date converter like the one at: Epoch & Unix Timestamp Conversion Tools, yields this constant as the following date and time:

Output from Converter

Assuming that this timestamp is in nanoseconds (1 billionth of a second): GMT: Sunday, September 9, 1973 5:45:36 PM Your time zone: Sunday, September 9, 1973 12:45:36 PM GMT-05:00 DST Relative: 48 years ago

This Constant is numerical representation of the above date in Nanoseconds. The epoch is nearly always used in comparison tests that compare datasets, files, columns, and other assorted items tagged with one date to the epoch, i.e:

// Pseudo-code
long (DataSet 1.Date - Epoch) = X, 
long (DataSet 2.Date - Epoch) = Y
// Comparison
If X = Y then
   // Perform items for valid data sets
Else If X != Y then
   // Attempt to repair data sets
Else
  // Perform Error Trapping
End

In LUKS case, the Epoch counter is increased by one each time the 2 bitwise copies of the encryption sets match, after a change or update. See Question about LUKS header information. I can't tell you why this particular epoch was chosen, but just for fun: What Happened on September 9, 1973

eyoung100
  • 5,717
  • 21
  • 50
  • 6
    The `EPOCH_AS_FILETIME` is not used in LUKS and has nothing to do with the `Epoch` value in the `luksDump` output. It is used in the BitLocker support code to convert between the [Microsoft FILETIME](https://docs.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime) structure to Unix Time. `116444736000000000` is the start of the Unix Time (Jan 1, 1970) in the FILETIME format (which starts Jan 1, 1601). – Vojtech Trefny May 09 '21 at 04:15
  • This is confusing. Why would one first calculate x = (a - e) and y = (b - e) and then compare x to y, instead of just comparing a to b directly? The epoch in the question is a rather small number, far from anything like 116444736000000000, or what the current date in seconds or nanoseconds since 1973 would be. How are they related? The quote says Windows NT uses 10^-7 seconds, so units of 100 ns, and the Unix time is customarily counted in seconds. So why the assumption that the number shown would be in nanoseconds instead? Especially if there's no explanation at all to the odd date... – ilkkachu May 09 '21 at 13:33
  • @VojtechTrefny: I admit I'm wrong on what the constant is used for, but you have converted the value incorrectly. The eppoch integer in Unix is:Timestamp in milliseconds: 21600000 – eyoung100 May 09 '21 at 21:54
  • @ilkkachu X and Y compute the offset from the Epoch. For verification, i.e. to ensure the datasets are exact copies of each other, the offsets must be equal. Comparing A to B directly, would only pass if the result were 0. I want to test for the small differences, ie same day but different times, so that when repairing, I can repair in increments – eyoung100 May 09 '21 at 22:10
  • @eyoung100 FILETIME 116444736000000000 is Unix Time 0, you can check it [with the epoch converter you linked](https://www.epochconverter.com/ldap). It' possible I'm just bad at explaining it, but I shouldn't be wrong, I wrote that damn thing :-) – Vojtech Trefny May 10 '21 at 04:44
  • @eyoung100, "Comparing A to B directly, would only pass if the result were 0." -- ... what? the result of what? How does subtracting a constant make unequal numbers equal again? Unless you're thinking of floating point where subtracting a huge number from a small one would lose all the precision in the small number... – ilkkachu May 10 '21 at 08:06
  • @eyoung100, 21600000 milliseconds is 6 hours. What has that have to do with anything? Are you just making this s**t up? – ilkkachu May 10 '21 at 08:07