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

Groups > linux.debian.user > #190559 > unrolled thread

Re: GRUB and boot partition

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: GRUB and boot partition Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-01-02 20:40 +0100
    Re: GRUB and boot partition Gary Dale <garydale@torfree.net> - 2018-01-03 15:50 +0100
      Re: GRUB and boot partition David Christensen <dpchrist@holgerdanske.com> - 2018-01-03 20:10 +0100
        Re: GRUB and boot partition Gary Dale <garydale@torfree.net> - 2018-01-05 16:30 +0100
          Re: GRUB and boot partition Richard Hector <richard@walnut.gen.nz> - 2018-01-06 13:10 +0100

#190559 — Re: GRUB and boot partition

Le 02/01/2018 à 02:29, microsoft gaofei a écrit :
> So AES is very lightweight ? I thought cryptography takes very much space , but I saw 1MB space is plenty for AES

What are you talking about ? Where did you see this ? It does not make 
sense. Encryption does not require extra space (except for header and 
block padding). Encrypted data have the same size of cleartext data.

[toc] | [next] | [standalone]

#190600

On 2018-01-02 02:35 PM, Pascal Hambourg wrote:
> Le 02/01/2018 à 02:29, microsoft gaofei a écrit :
>> So AES is very lightweight ? I thought cryptography takes very much 
>> space , but I saw 1MB space is plenty for AES
>
> What are you talking about ? Where did you see this ? It does not make 
> sense. Encryption does not require extra space (except for header and 
> block padding). Encrypted data have the same size of cleartext data.
>
Encryption is similar in concept to compression. It could even reduce 
the space requirements.

Encryption and compression both work by replacing strings of letters 
with something else. What we call clear text, for example, is just a 
Caesar cipher where each letter is replaced by a number (its ASCII code 
or unicode). Morse code, on the other hand, replaces common letters with 
shorter sequences of dots and dashes than less common letters.

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

#190619

On 01/03/18 06:45, Gary Dale wrote:
> On 2018-01-02 02:35 PM, Pascal Hambourg wrote:
>>
>> Encryption does not require extra space (except for header and 
>> block padding). Encrypted data have the same size of cleartext data.

+1


> Encryption is similar in concept to compression. 

AFAIK common use on Debian systems:

1.  Encryption functions [1] are reversible functions that transform 
data 1:1 in size, and are lossless.

2.  Compression functions [2] are reversible functions that strive for 
size ratios of N:1, where N > 1 (uncompressed:compressed), and can be 
lossless or lossly.


A related topic is hashing functions [3] (N:fixed, can be difficult to 
reverse).


> It could even reduce the space requirements.

I'm curious -- can you cite a compressing cipher code that cannot be 
reduced to independent compression and cipher functions?


> Encryption and compression both work by replacing strings of letters with something else.

I agree that encryption and compression are both forms of coding [4].


> Encryption and compression both work by replacing strings of letters 
> with something else. What we call clear text, for example, is just a  > Caesar cipher where each letter is replaced by a number (its ASCII code
> or unicode). 

ASCII [5] is a transliteration code -- replace a token from one alphabet 
(Roman letters, Arabic numerals, common English symbols, etc.) with a 
token from another alphabet (7-bit binary number).  Spelling, grammar, 
and meaning are unchanged.


The goal of a substitution cipher is to conceal meaning, and can be done 
without changing alphabets (e.g. rot13 [6]).  Spelling and grammar are 
unchanged (which facilitates cryptanalysis).


> Morse code, on the other hand, replaces common letters with 
> shorter sequences of dots and dashes than less common letters.

I agree that Morse Code [7] uses frequency-based techniques.


David


References:

[1] https://en.wikipedia.org/wiki/Encryption

[2] https://en.wikipedia.org/wiki/Data_compression

[3] https://en.wikipedia.org/wiki/Hash_function

[4] https://en.wikipedia.org/wiki/Code

[5] https://en.wikipedia.org/wiki/ASCII

[6] https://en.wikipedia.org/wiki/ROT13

[7] https://en.wikipedia.org/wiki/Morse_code

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

#190679

On 2018-01-03 01:59 PM, David Christensen wrote:
> On 01/03/18 06:45, Gary Dale wrote:
>> On 2018-01-02 02:35 PM, Pascal Hambourg wrote:
>>>
>>> Encryption does not require extra space (except for header and block 
>>> padding). Encrypted data have the same size of cleartext data.
>
> +1
>
>
>> Encryption is similar in concept to compression. 
>
> AFAIK common use on Debian systems:
>
> 1.  Encryption functions [1] are reversible functions that transform 
> data 1:1 in size, and are lossless.
>
> 2.  Compression functions [2] are reversible functions that strive for 
> size ratios of N:1, where N > 1 (uncompressed:compressed), and can be 
> lossless or lossly.
>
>
> A related topic is hashing functions [3] (N:fixed, can be difficult to 
> reverse).
>
>
>> It could even reduce the space requirements.
>
> I'm curious -- can you cite a compressing cipher code that cannot be 
> reduced to independent compression and cipher functions?
>
>
>> Encryption and compression both work by replacing strings of letters 
>> with something else.
>
> I agree that encryption and compression are both forms of coding [4].
>
>
>> Encryption and compression both work by replacing strings of letters 
>> with something else. What we call clear text, for example, is just a  
>> > Caesar cipher where each letter is replaced by a number (its ASCII 
>> code
>> or unicode). 
>
> ASCII [5] is a transliteration code -- replace a token from one 
> alphabet (Roman letters, Arabic numerals, common English symbols, 
> etc.) with a token from another alphabet (7-bit binary number). 
> Spelling, grammar, and meaning are unchanged.
>
>
> The goal of a substitution cipher is to conceal meaning, and can be 
> done without changing alphabets (e.g. rot13 [6]).  Spelling and 
> grammar are unchanged (which facilitates cryptanalysis).
>
>
>> Morse code, on the other hand, replaces common letters with shorter 
>> sequences of dots and dashes than less common letters.
>
> I agree that Morse Code [7] uses frequency-based techniques.
>
>
> David
>
>
> References:
>
> [1] https://en.wikipedia.org/wiki/Encryption
>
> [2] https://en.wikipedia.org/wiki/Data_compression
>
> [3] https://en.wikipedia.org/wiki/Hash_function
>
> [4] https://en.wikipedia.org/wiki/Code
>
> [5] https://en.wikipedia.org/wiki/ASCII
>
> [6] https://en.wikipedia.org/wiki/ROT13
>
> [7] https://en.wikipedia.org/wiki/Morse_code
>

While the intent is different, the techniques are quite similar. One 
once-popular code was to replace all words in a message with 2 numbers 
each, referring to a page & word number within an agreed-upon book. If 
you used it electronically, you could send a binary file where each 
original word was reduced to 2 bytes.

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

#190715

[Multipart message — attachments visible in raw view] — view raw

On 06/01/18 03:56, Gary Dale wrote:
> One once-popular code was to replace all words in a message with 2
> numbers each, referring to a page & word number within an agreed-upon
> book. If you used it electronically, you could send a binary file where
> each original word was reduced to 2 bytes.

That would restrict your choice of book quite a bit - or at least, you'd
only be able to use a small part of most/many books. I guess you can
optimise it by not splitting the numbers at the byte boundary.

Richard

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web