Mailing List Archive

On 19/09/2023 10:10, Jude DaShiell wrote:
> Once the set spots got figured
> five dice got used for letters add the total and subtract 4 for the
> particular letter.

Which actually isn't random. It's a bell curve peaking probably between
J and M. Think, if you throw 2 dice, there are 36 possible combinations.
Only one of them generates 2, only one generates 12, but 6 combinations
can generate 7.

Cheers,
Wol

On 20/09/2023 19:05, Frank Steinmetzger wrote:
>> In principle, a repeated space character in your passphrase could help
>> reduce the computational burden of an offline brute force attack, by e.g.
>> helping an attacker to identify the number of individual words in a
>> passphrase.

> Due to the rotation, the Enigma encoded each subsequent letter differently,
> even if the same one repeated, which was (one of) the big strengths of the
> Enigma cipher. The flaws were elsewhere, for example that a character could
> never be encrypted onto itself due to the internal wiring and certain
> message parts were always the same, like message headers and greetings.

And, as always, one of the biggest weaknesses was the operator.

Enigma had three (or in later versions four) rotors. The code book
specified the INITIAL "settings of the day" for those rotors. What was
*supposed* to happen was the operator was supposed to select a random
three/four character string, transmit that string twice, then reset the
rotors to that string before carrying on. So literally no two messages
were supposed to have the same settings beyond the first six characters.

Except that a lot of operators re-used the same characters time and time
again. So if you got a message from an operator you recognised, you
might well know his "seventh character reset". That saved a lot of grief
trying to crack which of the several rotors were "the rotors of the day".

And given that, for a large chunk of the war, the radio operators were
"chatty", you generally got a lot of six-character strings for which you
had a damn good idea what the plain text was.

So even where some of the operators were seriously crypto-aware and
careful, once you'd cracked the rotors and initial settings from the
careless, you could read every message sent by everyone (using those
settings) that day.

Along with other things like RDF giving subs positions away (although
I'm not quite sure how much we had good RDF and how much it was a cover
for us reading their location in status reports), it certainly helped us
loads hunting them down.

Cheers,
Wol

On 19/09/2023 10:13, Dale wrote:
> That's a interesting way to come up with passwords tho.  I've seen that
> is a few whodunit type shows.  Way back in the old days, they had some
> interesting ways of coding messages.  Passwords are sort of similar.

Back when we were busy conquering India ...

The story goes of a General trying to send a message back of his latest
conquest, but he didn't want to use codes because he had a suspicion the
Indians could read them if his messenger was captured.

It appears the story is apocryphal, but the message he sent read "peccavi".

https://www.ft.com/content/49036e66-ac48-11e8-94bd-cba20d67390c

Cheers,
Wol

Wols Lists wrote:
> On 20/09/2023 19:05, Frank Steinmetzger wrote:
>>> In principle, a repeated space character in your passphrase could help
>>> reduce the computational burden of an offline brute force attack, by
>>> e.g.
>>> helping an attacker to identify the number of individual words in a
>>> passphrase.
>
>> Due to the rotation, the Enigma encoded each subsequent letter
>> differently,
>> even if the same one repeated, which was (one of) the big strengths
>> of the
>> Enigma cipher. The flaws were elsewhere, for example that a character
>> could
>> never be encrypted onto itself due to the internal wiring and certain
>> message parts were always the same, like message headers and greetings.
>
> And, as always, one of the biggest weaknesses was the operator.
>
> Enigma had three (or in later versions four) rotors. The code book
> specified the INITIAL "settings of the day" for those rotors. What was
> *supposed* to happen was the operator was supposed to select a random
> three/four character string, transmit that string twice, then reset
> the rotors to that string before carrying on. So literally no two
> messages were supposed to have the same settings beyond the first six
> characters.
>
> Except that a lot of operators re-used the same characters time and
> time again. So if you got a message from an operator you recognised,
> you might well know his "seventh character reset". That saved a lot of
> grief trying to crack which of the several rotors were "the rotors of
> the day".
>
> And given that, for a large chunk of the war, the radio operators were
> "chatty", you generally got a lot of six-character strings for which
> you had a damn good idea what the plain text was.
>
> So even where some of the operators were seriously crypto-aware and
> careful, once you'd cracked the rotors and initial settings from the
> careless, you could read every message sent by everyone (using those
> settings) that day.
>
> Along with other things like RDF giving subs positions away (although
> I'm not quite sure how much we had good RDF and how much it was a
> cover for us reading their location in status reports), it certainly
> helped us loads hunting them down.
>
> Cheers,
> Wol
>
>

Another question.  Are people trying to work on better encryption given
current encryption can be cracked?  I read some things changed after
Snowden.  I'm just not sure what and if more changes are needed even
today. 

If you wanted the most secure and hard to crack encryption, what would
you use?  How does one tell cryptsetup to use it?  I have several
encryption options here but no idea what is the best or even just good. 

I'm making pepper sauce today.  I hope this typing is OK.  The air has a
spicy warmth to it.  o_O

Dale

:-)  :-) 

Wols Lists wrote:
> On 19/09/2023 10:13, Dale wrote:
>> That's a interesting way to come up with passwords tho.  I've seen that
>> is a few whodunit type shows.  Way back in the old days, they had some
>> interesting ways of coding messages.  Passwords are sort of similar.
>
> Back when we were busy conquering India ...
>
> The story goes of a General trying to send a message back of his
> latest conquest, but he didn't want to use codes because he had a
> suspicion the Indians could read them if his messenger was captured.
>
> It appears the story is apocryphal, but the message he sent read
> "peccavi".
>
> https://www.ft.com/content/49036e66-ac48-11e8-94bd-cba20d67390c
>
> Cheers,
> Wol
>
>


It seems that requires a subscription.  Oh well. 

Dale

:-)  :-) 

On 23/09/2023 14:35, Dale wrote:
> Another question.  Are people trying to work on better encryption given
> current encryption can be cracked?  I read some things changed after
> Snowden.  I'm just not sure what and if more changes are needed even
> today.

> If you wanted the most secure and hard to crack encryption, what
> would you use?  How does one tell cryptsetup to use it?  I have several
> encryption options here but no idea what is the best or even just good.

If you want encryption that can't be cracked, go for RSA. It's uncrackable.

Now you might be wondering why I say that, given that is a simple,
well-known attack, but it's true. You can trick me into encoding as much
plain text as you like, where you can intercept the cipher text, and you
will not be able to crack the cipher itself. What you need to do is get
hold of ONE of my key-pairs. The public one of course is usually freely
available, and if you get hold of the private one it's game over.

You can then mathematically solve "the puzzle of the keys" from my
public pair and recover the private key. This is why RSA keys keep
getting bigger - it takes more and more brute force to solve.

I don't know enough about ECC - do you crack it or solve it?

Both these ciphers however have a massive weakness - make a mistake
setting them up and the solution becomes easy. RSA relies on multiplying
two huge primes together. Dunno what ECC relies on. If one of your RSA
primes is not, in fact, prime then factoring the huge product becomes
easy, and recovering all the keys built from it is simple.

ECC specifies various parameters, and the official standard ECC
parameters were discovered to contain a flaw. Was that an intentional
back door? It's thought it was an accident.

But I think cryptographers have abandoned crackable ciphers now - if
it's crackable then it's easily crackable. And all other ciphers simply
rely on the asymmetric effort taken to create a key or solve a key.

Cheers,
Wol

Wol wrote:
> On 23/09/2023 14:35, Dale wrote:
>> Another question.  Are people trying to work on better encryption
>> given current encryption can be cracked?  I read some things changed
>> after Snowden.  I'm just not sure what and if more changes are needed
>> even today.
>
>> If you wanted the most secure and hard to crack encryption, what
>> would you use?  How does one tell cryptsetup to use it?  I have
>> several encryption options here but no idea what is the best or even
>> just good.
>
> If you want encryption that can't be cracked, go for RSA. It's
> uncrackable.
>
> Now you might be wondering why I say that, given that is a simple,
> well-known attack, but it's true. You can trick me into encoding as
> much plain text as you like, where you can intercept the cipher text,
> and you will not be able to crack the cipher itself. What you need to
> do is get hold of ONE of my key-pairs. The public one of course is
> usually freely available, and if you get hold of the private one it's
> game over.
>
> You can then mathematically solve "the puzzle of the keys" from my
> public pair and recover the private key. This is why RSA keys keep
> getting bigger - it takes more and more brute force to solve.
>
> I don't know enough about ECC - do you crack it or solve it?
>
> Both these ciphers however have a massive weakness - make a mistake
> setting them up and the solution becomes easy. RSA relies on
> multiplying two huge primes together. Dunno what ECC relies on. If one
> of your RSA primes is not, in fact, prime then factoring the huge
> product becomes easy, and recovering all the keys built from it is
> simple.
>
> ECC specifies various parameters, and the official standard ECC
> parameters were discovered to contain a flaw. Was that an intentional
> back door? It's thought it was an accident.
>
> But I think cryptographers have abandoned crackable ciphers now - if
> it's crackable then it's easily crackable. And all other ciphers
> simply rely on the asymmetric effort taken to create a key or solve a
> key.
>
> Cheers,
> Wol
>
>


When I run cryptsetup to encrypt my drives, I have no idea what it is
using.  I assumed the defaults would be the most secure.  This is the
luksDump info, some may be changed or snipped, not sure if it is
something I should make public.  ;-) 


root@fireball / # cryptsetup luksDump /dev/sdo1
LUKS header information
Version:        2
Epoch:          3
Metadata area:  16384 [bytes]
Keyslots area:  16744448 [bytes]
UUID:           967257e5-ccc8-48ab-8f46-c6b05dc3bf37
Label:          (no label)
Subsystem:      (no subsystem)
Flags:          (no flags)

Data segments:
  0: crypt
        offset: 16777216 [bytes]
        length: (whole device)
        cipher: aes-xts-plain64
        sector: 4096 [bytes]

<<<< SNIP >>>>
Digests:
  0: pbkdf2
        Hash:       sha256
        Iterations: 83062
        Salt:       20 d5 f5 3b 51 43 31 29 8a b0 31 dc ad 56 0c 15
                    50 18 aa f8 df a0 4e 9e 8e e1 b2 bb f1 04 67 01
        Digest:     96 18 90 9e 89 7a 16 71 72 d0 97 ec 84 e1 b5 38
                    fc cb ea 97 93 29 19 4c 83 a6 fb 4e e9 ba 79 7b
root@fireball / #


I'm not to clear on this but it looks like it is using 'aes-xts-plain64'
to me.  If so, is that good enough?  Is there better? 

While I'm mostly worried about someone maybe stealing my rig, I also
don't want someone with some skills getting in there either.  Some
crooks may know someone.  ;-)

Dale

:-)  :-) 

Den 23.09.2023 15:42, skrev Dale:
> Wols Lists wrote:
>> On 19/09/2023 10:13, Dale wrote:
>>> That's a interesting way to come up with passwords tho.  I've seen that
>>> is a few whodunit type shows.  Way back in the old days, they had some
>>> interesting ways of coding messages.  Passwords are sort of similar.
>> Back when we were busy conquering India ...
>>
>> The story goes of a General trying to send a message back of his
>> latest conquest, but he didn't want to use codes because he had a
>> suspicion the Indians could read them if his messenger was captured.
>>
>> It appears the story is apocryphal, but the message he sent read
>> "peccavi".
>>
>> https://www.ft.com/content/49036e66-ac48-11e8-94bd-cba20d67390c
>>
>> Cheers,
>> Wol
>>
>>
>
> It seems that requires a subscription.  Oh well.
Try
https://www.euronews.com/culture/2023/02/17/culture-re-view-peccavi-a-misattributed-quote-and-the-british-raj
Probably ripped off from FT, but I was  curious :-) .

On Sat, Sep 23, 2023 at 11:05?AM Dale <rdalek1967@gmail.com> wrote:
>
> I'm not to clear on this but it looks like it is using 'aes-xts-plain64'
> to me. If so, is that good enough? Is there better?

You are using the defaults, which is what you should be using, as
they're very secure. As far as I'm aware there is no known attack on
AES that is faster than a brute force attack, and a brute-force attack
on AES itself is not practical. I think it is unlikely that anybody
knows of an attack on the cipher, but of course that cannot be ruled
out. Current estimates of the time required to brute-force AES are in
the billions of years.

If somebody wanted to decrypt the drive without your knowledge, the
only practical attacks would be to evesdrop on you somehow to capture
your passphrase, or to brute force your passphrase. LUKS is designed
to make a brute-force attack on a passphrase impractical as long as it
is reasonably long. On typical hardware it should take a full second
or two to make one decryption attempt on the passphrase - obviously an
attacker could have more sophisticated hardware available but to even
be able to attempt tens of thousands of guesses per second would
require a very large expense, and your passphrase should be long
enough to make that search very long.

The most likely attack would be evesdropping. Stopping that requires
good physical security, and also keeping any malware out of your
bootloader. Unfortunately, the latter is generally not something
linux distros do much to prevent. Corporate laptops running windows
are typically set up to protect against this using a TPM and secure
boot. I'm not sure if any linux distros support a fully signed boot
processes up to disk decryption - doing that on Gentoo would be tricky
since the OS is being modified so often. A release-based distro could
do it a bit more easily - just stick the essential bits in a squashfs
and sign everything up to that point, and use secure boot.

Then of course if an attacker didn't mind you knowing about their
intrusion, they could use the rubber hose method. The only way to
defeat that sort of thing is to have some trusted external agent
involved in the process who could revoke your own access to your
device (think TPM and remote attestation to secure the boot chain plus
online authentication required for the device to obtain the session
key - though at that point you'd probably also just run a thin client
and keep the bulk of the data someplace more secure).

--
Rich

On 19/09/2023 08:36, Dale wrote:
> In the real world tho, how do people reading this make passwords that no
> one could ever guess?
I use nonsensical phrases that also contain symbols instead of words.
For example "all stars and cats for pies":

all*s&cats4pies

I can memorize those.