[dm-crypt] bits vs bytes

[dm-crypt] bits vs bytes

[JT Morée]

When I run luksDump i see that multiple locations give sizes in 'bits'.  Is that correct?   Normally, we operate in 8 bit => bytes.  If I read this correctly then

2: luks2 (unbound)
  Key:        512 bits = 64 bytes

JT

Re: [dm-crypt] bits vs bytes

[Michael Kjörling]

On 30 Mar 2020 20:03 +0000, from moreejt@yahoo.com (JT Morée):
> When I run luksDump i see that multiple locations give sizes in
> 'bits'.  Is that correct?   Normally, we operate in 8 bit => bytes. 
> If I read this correctly then
> 
> 2: luks2 (unbound)
>   Key:        512 bits = 64 bytes

Cryptographic key sizes, hash lengths, block sizes, and similar
quantities are commonly stated in bits, not bytes, especially for
algorithms typically implemented on digital, binary computers (in
either hardware or software).

There's likely a variety of reasons for this; some historical, some
mathematical.

Certainly you can convert the number of bits to a number of bytes by
dividing by 8 _if_ you prefer that for some reason, but a _lot_ more
people will know what you mean if you say, for example, "128-bit AES"
than "16-byte AES". (Never mind "AES-128" versus "AES-16", the latter
of which seems likely to just be confusing.) So for communicating with
others, I _really_ suggest using the more common form.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”

Re: [dm-crypt] bits vs bytes

[Arno Wagner]

On Mon, Mar 30, 2020 at 22:25:02 CEST, Michael Kjörling wrote:
> On 30 Mar 2020 20:03 +0000, from moreejt@yahoo.com (JT Morée):
> > When I run luksDump i see that multiple locations give sizes in
> > 'bits'.  Is that correct?   Normally, we operate in 8 bit => bytes. 
> > If I read this correctly then
> > 
> > 2: luks2 (unbound)
> >   Key:        512 bits = 64 bytes
> 
> Cryptographic key sizes, hash lengths, block sizes, and similar
> quantities are commonly stated in bits, not bytes, especially for
> algorithms typically implemented on digital, binary computers (in
> either hardware or software).
> 
> There's likely a variety of reasons for this; some historical, some
> mathematical.

Probably the most important is that the concept of a byte has no
real meaning for these values.

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] bits vs bytes

[JT Morée]

 On Monday, March 30, 2020, 2:03:17 PM MST, Arno Wagner <arno@wagner.name> wrote: 
> Probably the most important is that the concept of a byte has no real meaning for these values.

>Regards,
>Arno

In this use case--where we store keys on medium such as hard drive or USB drive--the convention is to measure usage in bytes and derivatives thereof.  I'm trying to see how much space my 'key' is using up within the allocated space of the LUKS header and for import/export.  That's real meaning ;-)

Re: [dm-crypt] bits vs bytes

[JT Morée]

On Monday, March 30, 2020, 6:43:11 PM MST, Arno Wagner <arno@wagner.name> wrote: 
> Not in a cryptographic context. You could also want to etch them

is that because the 512 bits is not the size of the key but instead a measurement of one component that goes into generating the key?

Re: [dm-crypt] bits vs bytes

[Arno Wagner]

On Tue, Mar 31, 2020 at 07:35:16 CEST, JT Morée wrote:
> 
> On Monday, March 30, 2020, 6:43:11 PM MST, Arno Wagner <arno@wagner.name> wrote: 
> > Not in a cryptographic context. You could also want to etch them
> 
> is that because the 512 bits is not the size of the key but instead a
> measurement of one component that goes into generating the key?

Well, block-ciphers have gotten to respect CPU operations recently, 
so they are starting to use bytes internally ti increase efficiency. 
But look at classic DES, and every but pretty much gets treated by 
itself or bits get grpuped in ways that have nothing to do with byte
boundaries. Or look at RSA and whether you have a 4096 bit, 4095 bit 
or 4097 bit modulus makes no difference. Of course you usually
go for multiples of 8, but that is just to accomodate a specific
implementation (computers with 8 bit bytes), not anything that is
part of the algebra of the cipher.

Just accept it, it makes sense form a mathematical viewpoint.
Otherwise you would need to multiply by 8 in a lot of places.
And you could also use nibbles (4 bit) words (16 bits), 
long words (32 bits) or quadwords (64 bits) as "units". The 
byte is not really specuial.

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] bits vs bytes

[Michael Kjörling]

On 31 Mar 2020 08:43 +0200, from arno@wagner.name (Arno Wagner):
> Otherwise you would need to multiply by 8 in a lot of places.
> And you could also use nibbles (4 bit) words (16 bits), 
> long words (32 bits) or quadwords (64 bits) as "units". The 
> byte is not really specuial.

And let's not forget that at the time when many long-lasting
encryption algorithms (DES, RSA, anyone?) were being designed, it
still wasn't an open-and-shut case whether even a digital binary
computer would represent data in 8-bit chunks or not. Octal was still
big in the late 1970s.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”

Re: [dm-crypt] bits vs bytes

[Arno Wagner]

On Tue, Mar 31, 2020 at 08:55:32 CEST, Michael Kjörling wrote:
> On 31 Mar 2020 08:43 +0200, from arno@wagner.name (Arno Wagner):
> > Otherwise you would need to multiply by 8 in a lot of places.
> > And you could also use nibbles (4 bit) words (16 bits), 
> > long words (32 bits) or quadwords (64 bits) as "units". The 
> > byte is not really specuial.
> 
> And let's not forget that at the time when many long-lasting
> encryption algorithms (DES, RSA, anyone?) were being designed, it
> still wasn't an open-and-shut case whether even a digital binary
> computer would represent data in 8-bit chunks or not. Octal was still
> big in the late 1970s.

Hehehe, yes. That would be 3-bit units...

Anyways, while SI has no unit for "information", as it is not
a physical thing, Information Theory typically uses "bit" as 
base unit. But there are apparently also people that use "nat" 
(base e) and "decimal digit" (base 10) in Information Theory. 
So we are fortunate they usually use something binary in the 
first place!

Hence "bit" is basically the most common denominator for the
different fields involved and also the most simple one 
which nicely satisfies KISS.

For even more confusion: 
  https://en.wikipedia.org/wiki/Binary_prefix
Not only do SI and IEC disagree, but at least with different 
prefixes, apparently JEDEC does something even worse and 
redefines existing prefixes!

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] bits vs bytes

[Michael Kjörling]

On 30 Mar 2020 21:18 +0000, from moreejt@yahoo.com (JT Morée):
> I'm trying to see how much space my 'key' is using up within the
> allocated space of the LUKS header and for import/export.  That's
> real meaning ;-)

If that is your goal, then you really should be asking about that. In
general, ask about what you want to know (while stating your ultimate
goal), not what you _think_ will tell you the answer to what you
_actually_ want to know. Asking about something other than what you
actually want to know is liable to get you the wrong answer (or at
least a useless one), and likely to waste peoples' time. That helps
noone.

Also, for LUKS, it's not as easy as just taking the cryptographic key
length, because the cryptographic key isn't stored directly, even
encrypted. Rather, the key is stretched on-disk (via the "AF" or
anti-forensic stripes), in part to make it easier to overwrite enough
key material to make recovery via an exhaustive search guided by the
remaining on-disk data impractical. That forces an attacker to either
attack the passphrase (via the iterated, salted hash) or the
randomly-selected bulk encryption key directly. If you choose a good
passphrase and/or set a high enough iteration count, both can be made
equally impractical.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”