Re: [gentoo-user] Network throughput from main Gentoo rig to NAS box.

[Dale]

Mark Knecht wrote:
> 
> >
> > Oh.  My pepper sauce was getting loud and my eyes were watery.  Now
> that I got that done, I can see better after opening the doors a few
> minutes.  This is what I get now.  My NAS box, running it first:
> >
> > root@nas:~# iperf -s
> > 
> > Server listening on TCP port 5001
> > TCP window size:  128 KByte (default)
> > 
> >
> >
> > From main rig, running NAS box command first and it appeared to be
> waiting.
> >
> >
> > root@fireball / # iperf3 -c 10.0.0.7
> > iperf3: error - unable to connect to server - server may have
> stopped running or use a different port, firewall issue, etc.:
> Connection refused
> > root@fireball / #
> >
> >
> > So, it appears to be waiting but my main rig isn't getting it.  Then
> it occurred my VPN might be affecting this somehow.  I stopped it just
> in case.  OK, same thing.  I did run the one on the NAS box first,
> since I assume it needs to be listening when I run the command on my
> main rig.  After stopping the VPN, I ran both again.
> >
> > Just so you know the machine is reachable, I am ssh'd into the NAS
> box and I also have it mounted and copying files over with rsync. 
> Could my router be blocking this connection?  I kinda leave it at the
> default settings.  Read somewhere those are fairly secure.
> >
> > I'm working in garden a bit so may come and go at times.  I'm sure
> you doing other things too.  :-D
> >
> > Dale
> >
> > :-)  :-)
>
> If you're running a VPN then you'll need someone at a higher pay grade
> than me, but packetizing TCP packets into and out of VPN security is
> certainly going to use CPU cycles and slow things down, at least a
> little. No idea if that's what caused your gkrellm pictures. Also, any
> network heavy apps, like playing video from the NAS or from the
> Internet is also going to slow file transfers down.
>
> Your error message is telling you that something is in the way.
>
> Can you ping the NAS box?
>
> ping 10.0.0.7
>
> Can you tracepath the NAS box?
>
> tracepath 10.0.0.7
>
> Are you sure that 10.0.0.7 is the address of the NAS box? 
>
> Do you have a /etc/hosts file to keep the names straight?
>
> HTH,
> Mark
>
>


Sorry so long.  I was working in the garden some when my neighbor called
and wanted to move his mailbox.  He got one of those pre-made things a
long time ago and it is really to short.  I dug a new hole, put in a
piece of tubing that the mailbox post would slip over and then poured
concrete around it.  Should hold up now.  Can't move it and the concrete
isn't even dry yet.  I really like a auger that fits on the back of a
tractor especially when the road used to be a gravel road.  Post hole
diggers are a TON of hard work.  Auger took less than a minute, with
tractor at idle.  LOL  Anyway, mailbox is up and I got some sore
joints.  I sense meds coming pretty soon.  :/ 

I can ping it.  I always have the VPN running and believe it or not, I
can connect to the NAS box, ping, transfer files and everything with it
running.  I just thought the VPN might affect that one thing for some
reason.  Anytime something odd is going on network wise, I stop the VPN
first and test again.  I rule that out first thing. 

I read the other replies and I think it is caching the data, the drives
writes and catches up and then it asks for more data again.  I can't
imagine anything to do with the NAS box given it did the exact same
thing with Truenas.  If anything, I'd expect it to be on my main rig but
the main rig has a lot more power and memory than the NAS box does.  I
suspect between the cache thing and encryption, that is the bottleneck. 
I also replaced the network card a week or so ago.  Turned out it was a
setting I needed to change.  So, not a bad card either. 

I got to cool off and rest a bit.  I may read some more replies later or
again, after I get my wits back.  :/ 

Dale

:-)  :-) 

Re: [gentoo-user] Network throughput from main Gentoo rig to NAS box.

[Mark Knecht]

On Sat, Sep 23, 2023 at 9:22 AM Rich Freeman  wrote:
>
> On Sat, Sep 23, 2023 at 8:04 AM Dale  wrote:
> >
> > I'm expecting more of a consistent throughput instead of all the
> > idle time.  The final throughput is only around 29.32MB/s according to
> > info from rsync.  If it was not stopping all the time and passing data
> > through all the time, I think that would improve.  Might even double.
>
> Is anything else reading data from the NAS at the same time?  The
> performance is going to depend on a lot of details you haven't
> provided, but anything that reads from a hard disk is going to
> significantly drop throughput - probably to levels around what you're
> seeing.
>
> That seems like the most likely explanation, assuming you don't have
> some older CPU or a 100Mbps network port, or something else like WiFi
> in the mix.  The bursty behavior is likely due to caching.
>
> --
> Rich

Let's not forget that Dale also likes to put layers of things on his
drives, LVM & encryption at a minimum. We also don't know anything
about his block sizes at either end of this pipe.

I would think maybe running iotop AND btop on both ends would give some
clues on timing. Is the time when gkrellm is idle due to the host disk not
responding or the target getting flooded with too much data?

- Mark

Re: [gentoo-user] Network throughput from main Gentoo rig to NAS box.

[Rich Freeman]

On Sat, Sep 23, 2023 at 8:04 AM Dale  wrote:
>
> I'm expecting more of a consistent throughput instead of all the
> idle time.  The final throughput is only around 29.32MB/s according to
> info from rsync.  If it was not stopping all the time and passing data
> through all the time, I think that would improve.  Might even double.

Is anything else reading data from the NAS at the same time?  The
performance is going to depend on a lot of details you haven't
provided, but anything that reads from a hard disk is going to
significantly drop throughput - probably to levels around what you're
seeing.

That seems like the most likely explanation, assuming you don't have
some older CPU or a 100Mbps network port, or something else like WiFi
in the mix.  The bursty behavior is likely due to caching.

--
Rich

Re: [gentoo-user] Network throughput from main Gentoo rig to NAS box.

[Jack]

On 9/23/23 08:04, Dale wrote:

Howdy,

As most everyone knows, I redone my NAS box.  Before I had Truenas on it
but switched to Ubuntu server thingy called Jimmy.  Kinda like the
name.  lol  Anyway, Ubuntu has the same odd transfer pattern as the
Truenas box had.  I'm not sure if the problem is on the Gentoo end or
the Ubuntu end or something else.  I'm attaching a picture of Gkrellm so
you can see what I'm talking about.  It transfers a bit, then seems to
stop for some reason, then start up again and this repeats over and
over.  I'm expecting more of a consistent throughput instead of all the
idle time.  The final throughput is only around 29.32MB/s according to
info from rsync.  If it was not stopping all the time and passing data
through all the time, I think that would improve.  Might even double.

A little more info.  The set of drives this is being copied from use LVM
and are encrypted with dm-crypt.  They are also set up the same way on
the NAS box.  I also notice that on the NAS box, using htop, the CPUs
sit at idle for a bit then show heavy use, on Ubuntu about 60 or 70%,
then go back to idle.  This seems to be the same thing I'm seeing on
htop with the data throughput.  One may have something to do with the
other but I don't know what.  I got so much stuff running on my main rig
that I can't really tell if that CPU has the same changes or not.  By
the way, it showed the same when Truenas was on there.  These things are
mounted using nfs.  I don't know if that matters or not.  In case this
is a routing issue, I have a Netgear router with 1GB ports.  This is the
first part of the mount command:

mount -t nfs -o nolock

Has anyone ever seen something like this and know why it is idle for so
much of the time?  Anyone know if this can be fixed so that it is more
consistent, and hopefully faster?

If you need more info, let me know.  If you know the command, that might
help too.  Just in case it is a command I'm not familiar with.
I can't add to what others have suggested to improve the throughput, but 
the gkrellm pic you posted tells me something is handling the data in 
batches.  enp3s0 (your network interface) gets a peak of activity then 
stops while crypt (the disk) has a peak of activity. Rinse and repeat.  
I don't know if this is caused by the program invoked by the command you 
issued or by some interaction of different pieces that get called to do 
the work.  My guess is that it is reading until it fills some buffer, 
then writes it out. (Note, it doesn't matter which device is reading and 
which is writing, the two just don't overlap)  If encryption is 
involved, it might be that there is actually a encrypt/decrypt which 
takes place in between the disk and network flows.  I don't know of any 
way to change this, but it might explain why the network transfer rate 
is as fast as it can get, but the overall throughput is lower.

Re: [gentoo-user] Password questions, looking for opinions. cryptsetup question too.

[Rich Freeman]

On Sat, Sep 23, 2023 at 11:05 AM Dale  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

Re: [gentoo-user] Network throughput from main Gentoo rig to NAS box.

[ralfconn]

On 9/23/23 14:04, Dale wrote:

Howdy,

As most everyone knows, I redone my NAS box.  Before I had Truenas on it
but switched to Ubuntu server thingy called Jimmy.  Kinda like the
name.  lol  Anyway, Ubuntu has the same odd transfer pattern as the
Truenas box had.  I'm not sure if the problem is on the Gentoo end or
the Ubuntu end or something else.  I'm attaching a picture of Gkrellm so
you can see what I'm talking about.  It transfers a bit, then seems to
stop for some reason, then start up again and this repeats over and
over.  I'm expecting more of a consistent throughput instead of all the
idle time.  The final throughput is only around 29.32MB/s according to
info from rsync.  If it was not stopping all the time and passing data
through all the time, I think that would improve.  Might even double.

...
Has anyone ever seen something like this and know why it is idle for so
much of the time?  Anyone know if this can be fixed so that it is more
consistent, and hopefully faster?

I found a similar pattern when I checked some time ago, while 
transferring big (several Gb) files from one desktop to the other. I 
concluded the cause of the gaps was the destination PC's SATA spinning 
disk that needed to empty its cache before accepting more data. In 
theory the network is 1Gb/s (measured with iperf, it is really close to 
that) and the SATA is 6Gb/s so it should not be the limit, but I have 
strong doubts as how this speed is measured by the manufacturer. As 
indirect confirmation, when I switched the destination disk to a flash 
one the overall network transfer speed improved a lot (a lot lot!).


raffaele

Re: [gentoo-user] Password questions, looking for opinions. cryptsetup question too.

[Håkon Alstadheim]

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 :-) .

Re: [gentoo-user] Network throughput from main Gentoo rig to NAS box.

[Mark Knecht]

>
> Oh.  My pepper sauce was getting loud and my eyes were watery.  Now that
I got that done, I can see better after opening the doors a few minutes.
This is what I get now.  My NAS box, running it first:
>
> root@nas:~# iperf -s
> 
> Server listening on TCP port 5001
> TCP window size:  128 KByte (default)
> 
>
>
> From main rig, running NAS box command first and it appeared to be
waiting.
>
>
> root@fireball / # iperf3 -c 10.0.0.7
> iperf3: error - unable to connect to server - server may have stopped
running or use a different port, firewall issue, etc.: Connection refused
> root@fireball / #
>
>
> So, it appears to be waiting but my main rig isn't getting it.  Then it
occurred my VPN might be affecting this somehow.  I stopped it just in
case.  OK, same thing.  I did run the one on the NAS box first, since I
assume it needs to be listening when I run the command on my main rig.
After stopping the VPN, I ran both again.
>
> Just so you know the machine is reachable, I am ssh'd into the NAS box
and I also have it mounted and copying files over with rsync.  Could my
router be blocking this connection?  I kinda leave it at the default
settings.  Read somewhere those are fairly secure.
>
> I'm working in garden a bit so may come and go at times.  I'm sure you
doing other things too.  :-D
>
> Dale
>
> :-)  :-)

If you're running a VPN then you'll need someone at a higher pay grade than
me, but packetizing TCP packets into and out of VPN security is certainly
going to use CPU cycles and slow things down, at least a little. No idea if
that's what caused your gkrellm pictures. Also, any network heavy apps,
like playing video from the NAS or from the Internet is also going to slow
file transfers down.

Your error message is telling you that something is in the way.

Can you ping the NAS box?

ping 10.0.0.7

Can you tracepath the NAS box?

tracepath 10.0.0.7

Are you sure that 10.0.0.7 is the address of the NAS box?

Do you have a /etc/hosts file to keep the names straight?

HTH,
Mark

Re: [gentoo-user] Network throughput from main Gentoo rig to NAS box.

[Tsukasa Mcp_Reznor]

There are quite a few things to tweak that can lead to much smoother transfers, 
so I'll make an unordered list to help.

mount -o nocto,nolock,async,nconnect=4,rsize=1048576,wsize=1048576
rsize and wsize are very important for max bandwidth, worth checking with mount 
after linked up
nocto helps a bit, the man page has more info
nconnect helps reach higher throughput by using more threads on the pipe
async might actually be your main issue, nfs does a lot of sync writes, so that 
would explain the gaps in your chart, needs written to physical media before 
replying that it's been committed so more data can be sent.

sysctl.conf mods
net.ipv4.tcp_mtu_probing = 2
net.ipv4.tcp_base_mss = 1024

if you use jumbo frames, that'll allow it to find the higher packet sizes.

fs.nfs.nfs_congestion_kb = 524288

that controls how much data can be inflight waiting for responses, if it's too 
small that'll also lead to the gaps you see.

subjective part incoming lol

net.core.rmem_default = 1048576
net.core.rmem_max = 16777216
net.core.wmem_default = 1048576
net.core.wmem_max = 16777216

net.ipv4.tcp_mem = 4096 131072 262144
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216

net.core.netdev_max_backlog = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_limit_output_bytes = 262144
net.ipv4.tcp_max_tw_buckets = 262144

you can find your own numbers based on ram size.  Basically those control how 
much data can be buffered PER socket, big buffers improve bandwidth usage to a 
point, after that point they can lead to latency being added, if most of your 
communication is with that NAS, you basically ping the NAS to get the average 
latency then divide your wire speed by it to see how much data it would take to 
max it out.  Also being per socket means you can have lower numbers than I use 
for sure, I do a lot of single file copies, so my workload isn't the normal 
usage.

Re: [gentoo-user] Password questions, looking for opinions. cryptsetup question too.

[Dale]

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:  1678 [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

:-)  :-) 

Re: [gentoo-user] Network throughput from main Gentoo rig to NAS box.

[Dale]

Mark Knecht wrote:
>
>
> On Sat, Sep 23, 2023 at 6:41 AM Dale  > wrote:
> >
> > Mark Knecht wrote:
> >
> >
> >
> > On Sat, Sep 23, 2023 at 5:05 AM Dale  > wrote:
> > 
> > > If you need more info, let me know.  If you know the command, that
> might
> > > help too.  Just in case it is a command I'm not familiar with.
> > >
> > > Thanks.
> > >
> > > Dale
> > >
> > > :-)  :-)
> >
> > You can use the iperf command to do simple raw speed testing.
> >
> > For instance, on your server open a terminal through ssh and run
> >
> > iperf -s
> >
> > It should tell you the server is listening.
> >
> > On your desktop machine run
> >
> > iperf -c 192.168.86.119
> >
> > (replace with the IP of your server)
> >
> > It runs for 5-10 seconds and then reports what it sees
> > as throughput.
> >
> > Remember to Ctrl-C the server side when you're done.
> >
> > HTH,
> > Mark
> >
> >
> >
> > I had to install those.  On Gentoo it's called iperf3 but it works. 
> Anyway, this is what I get from running the command on the NAS box to
> my main rig.
> >
> >
> > root@nas:~# iperf -c 10.0.0.4
> > tcp connect failed: Connection refused
> > 
> > Client connecting to 10.0.0.4, TCP port 5001
> > TCP window size: -1.00 Byte (default)
> > 
> > [  1] local 0.0.0.0 port 0 connected with 10.0.0.4 port 5001
> > root@nas:~#
> >
> >
> > This is when I try to run from my main rig to the NAS box.
> >
> >
> > root@fireball / # iperf3 -c 10.0.0.7
> > iperf3: error - unable to connect to server - server may have
> stopped running or use a different port, firewall issue, etc.:
> Connection refused
> > root@fireball / #
> >
> >
> > I took what you said to mean to run from the NAS box.  I tried both
> just in case I misunderstood your meaning by server.  ;-)
> >
> > Ideas?
> >
> > Dale
>
> I thought the instructions were clear but let's try again.
>
> When using iperf YOU have to set up BOTH ends of the path, so:
>
> 1) On one end - let's say it's your NAS server - open a terminal. In
> that terminal type
>
> mark@plex:~$ iperf -s
> 
> Server listening on TCP port 5001
> TCP window size:  128 KByte (default)
> 
>
> 2) Then, on your desktop machine that wants to talk to the NAS server
> type this command,
> replacing my service IP with your NAS server IP
>
> mark@science2:~$ iperf -c 192.168.86.119    
> 
> Client connecting to 192.168.86.119, TCP port 5001
> TCP window size: 85.0 KByte (default)
> 
> [  1] local 192.168.86.43 port 40320 connected with 192.168.86.119
> port 5001
> [ ID] Interval   Transfer Bandwidth
> [  1] 0.-10.0808 sec   426 MBytes   354 Mbits/sec
> mark@science2:~$ 
>
> In this case, over my wireless network, I'm getting about 354Mb/S.
> Last time
> I checked it I hooked a cable between the 2 rooms I got about 900Mb/s.


Oh.  My pepper sauce was getting loud and my eyes were watery.  Now that
I got that done, I can see better after opening the doors a few
minutes.  This is what I get now.  My NAS box, running it first: 

root@nas:~# iperf -s

Server listening on TCP port 5001
TCP window size:  128 KByte (default)



>From main rig, running NAS box command first and it appeared to be waiting.


root@fireball / # iperf3 -c 10.0.0.7
iperf3: error - unable to connect to server - server may have stopped
running or use a different port, firewall issue, etc.: Connection refused
root@fireball / #


So, it appears to be waiting but my main rig isn't getting it.  Then it
occurred my VPN might be affecting this somehow.  I stopped it just in
case.  OK, same thing.  I did run the one on the NAS box first, since I
assume it needs to be listening when I run the command on my main rig. 
After stopping the VPN, I ran both again. 

Just so you know the machine is reachable, I am ssh'd into the NAS box
and I also have it mounted and copying files over with rsync.  Could my
router be blocking this connection?  I kinda leave it at the default
settings.  Read somewhere those are fairly secure. 

I'm working in garden a bit so may come and go at times.  I'm sure you
doing other things too.  :-D 

Dale

:-)  :-)

Re: [gentoo-user] Password questions, looking for opinions. cryptsetup question too.

[Wol]

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

Re: [gentoo-user] Network throughput from main Gentoo rig to NAS box.

[Mark Knecht]

On Sat, Sep 23, 2023 at 6:41 AM Dale  wrote:
>
> Mark Knecht wrote:
>
>
>
> On Sat, Sep 23, 2023 at 5:05 AM Dale  wrote:
> 
> > If you need more info, let me know.  If you know the command, that might
> > help too.  Just in case it is a command I'm not familiar with.
> >
> > Thanks.
> >
> > Dale
> >
> > :-)  :-)
>
> You can use the iperf command to do simple raw speed testing.
>
> For instance, on your server open a terminal through ssh and run
>
> iperf -s
>
> It should tell you the server is listening.
>
> On your desktop machine run
>
> iperf -c 192.168.86.119
>
> (replace with the IP of your server)
>
> It runs for 5-10 seconds and then reports what it sees
> as throughput.
>
> Remember to Ctrl-C the server side when you're done.
>
> HTH,
> Mark
>
>
>
> I had to install those.  On Gentoo it's called iperf3 but it works.
Anyway, this is what I get from running the command on the NAS box to my
main rig.
>
>
> root@nas:~# iperf -c 10.0.0.4
> tcp connect failed: Connection refused
> 
> Client connecting to 10.0.0.4, TCP port 5001
> TCP window size: -1.00 Byte (default)
> 
> [  1] local 0.0.0.0 port 0 connected with 10.0.0.4 port 5001
> root@nas:~#
>
>
> This is when I try to run from my main rig to the NAS box.
>
>
> root@fireball / # iperf3 -c 10.0.0.7
> iperf3: error - unable to connect to server - server may have stopped
running or use a different port, firewall issue, etc.: Connection refused
> root@fireball / #
>
>
> I took what you said to mean to run from the NAS box.  I tried both just
in case I misunderstood your meaning by server.  ;-)
>
> Ideas?
>
> Dale

I thought the instructions were clear but let's try again.

When using iperf YOU have to set up BOTH ends of the path, so:

1) On one end - let's say it's your NAS server - open a terminal. In that
terminal type

mark@plex:~$ iperf -s

Server listening on TCP port 5001
TCP window size:  128 KByte (default)


2) Then, on your desktop machine that wants to talk to the NAS server type
this command,
replacing my service IP with your NAS server IP

mark@science2:~$ iperf -c 192.168.86.119

Client connecting to 192.168.86.119, TCP port 5001
TCP window size: 85.0 KByte (default)

[  1] local 192.168.86.43 port 40320 connected with 192.168.86.119 port
5001
[ ID] Interval   Transfer Bandwidth
[  1] 0.-10.0808 sec   426 MBytes   354 Mbits/sec
mark@science2:~$

In this case, over my wireless network, I'm getting about 354Mb/S. Last time
I checked it I hooked a cable between the 2 rooms I got about 900Mb/s.

Re: [gentoo-user] Password questions, looking for opinions. cryptsetup question too.

[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

:-)  :-) 

Re: [gentoo-user] Network throughput from main Gentoo rig to NAS box.

[Dale]

Mark Knecht wrote:
>
>
> On Sat, Sep 23, 2023 at 5:05 AM Dale  > wrote:
> 
> > If you need more info, let me know.  If you know the command, that might
> > help too.  Just in case it is a command I'm not familiar with.
> >
> > Thanks.
> >
> > Dale
> >
> > :-)  :-)
>
> You can use the iperf command to do simple raw speed testing.
>
> For instance, on your server open a terminal through ssh and run
>
> iperf -s
>
> It should tell you the server is listening.
>
> On your desktop machine run
>
> iperf -c 192.168.86.119
>
> (replace with the IP of your server)
>
> It runs for 5-10 seconds and then reports what it sees 
> as throughput.
>
> Remember to Ctrl-C the server side when you're done.
>
> HTH,
> Mark


I had to install those.  On Gentoo it's called iperf3 but it works. 
Anyway, this is what I get from running the command on the NAS box to my
main rig. 


root@nas:~# iperf -c 10.0.0.4
tcp connect failed: Connection refused

Client connecting to 10.0.0.4, TCP port 5001
TCP window size: -1.00 Byte (default)

[  1] local 0.0.0.0 port 0 connected with 10.0.0.4 port 5001
root@nas:~#


This is when I try to run from my main rig to the NAS box. 


root@fireball / # iperf3 -c 10.0.0.7
iperf3: error - unable to connect to server - server may have stopped
running or use a different port, firewall issue, etc.: Connection refused
root@fireball / #


I took what you said to mean to run from the NAS box.  I tried both just
in case I misunderstood your meaning by server.  ;-)

Ideas?

Dale

:-)  :-) 

That pepper sauce is getting loud.  '_O

Re: [gentoo-user] Password questions, looking for opinions. cryptsetup question too.

[Dale]

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

:-)  :-) 

Re: [gentoo-user] Network throughput from main Gentoo rig to NAS box.

[Mark Knecht]

On Sat, Sep 23, 2023 at 5:05 AM Dale  wrote:

> If you need more info, let me know.  If you know the command, that might
> help too.  Just in case it is a command I'm not familiar with.
>
> Thanks.
>
> Dale
>
> :-)  :-)

You can use the iperf command to do simple raw speed testing.

For instance, on your server open a terminal through ssh and run

iperf -s

It should tell you the server is listening.

On your desktop machine run

iperf -c 192.168.86.119

(replace with the IP of your server)

It runs for 5-10 seconds and then reports what it sees
as throughput.

Remember to Ctrl-C the server side when you're done.

HTH,
Mark

Re: [gentoo-user] Password questions, looking for opinions. cryptsetup question too.

[Wols Lists]

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

Re: [gentoo-user] Password questions, looking for opinions. cryptsetup question too.

[Wols Lists]

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

Re: [gentoo-user] Re: How to move ext4 partition

[Håkon Alstadheim]

Den 22.09.2023 08:48, skrev Wols Lists:

On 20/09/2023 23:39, Grant Edwards wrote:

Assuming GParted is smart enough to do overlapping moves, is it smart
enough to only copy filesystem data and not copy "empty" sectors?
According to various forum posts, it is not: moving a partion copies
every sector. [That's certainly the obvious, safe thing to do.]


Seeing as it knows nothing about filesystems, and everything about 
partitions, it will treat the partition as an opaque blob and move it 
as a single object ...


The partition in question is 200GB, but only 7GB is used, so I think
backup/restore is the way to go...


You would think so :-)

I use ext4, and make heavy use of hard links. Last time I tried a 
straight copy (not backup/restore) I think the copied partition would 
have been three times the size of the original - that is if it hadn't 
run out of space first :-)


Just for completeness, you should check out the e2image command, though 
NOT for direct in-place overlapping move. Something like "e2image -ra 
$sourcevol $targetvol" has worked very well for me. That is obviously 
NOT for overlapping move, but for a backup it is quite fast. If you are 
moving to a bigger volume, I'd do resize as a separate step after the move.

Re: [gentoo-user] Password questions, looking for opinions. cryptsetup question too.

[Wols Lists]

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