02:05 <DocScrutinizer05> apropos server... how's your new one? living up to expectations?

02:14 <DocScrutinizer05> hmmm 181-171-244-190.fibertel.com.ar is bruteforcing my server

02:51 <whitequark> kyak: huh, I was really wrong, it seems https://crypto.stackexchange.com/questions/3952/is-it-possible-to-obtain-aes-128-key-from-a-known-ciphertext-plaintext-pair

03:22 <azkay> Ended up getting a (blurry) trinket anyway; i.imgur.com/Cms2udy.jpg

03:59 <wpwrak> DocScrutinizer05: server is working fine so far. i'm just missing some bits of config info from the old one before i can properly set it up. seems they forgot to complete the setup :(

04:00 <DocScrutinizer05> who forgot to setup? hetzner?

04:00 <wpwrak> DocScrutinizer05: (181-171-244-190.fibertel.com.ar) that doens't look like me :)

04:00 <wpwrak> no, amhosting

04:00 <DocScrutinizer05> no, that's not you

04:00 <DocScrutinizer05> :-)

04:01 <DocScrutinizer05> Hetzner vServers have the advantage that moving the VM to another working iron should be a matter of less than 5 seconds

04:01 <wpwrak> whitequark: that sounds a lot more in line with what i expected :)

04:02 <whitequark> yeah, I'm not sure where I got that

04:03 <wpwrak> DocScrutinizer05: yup, the big feature of VMs :)

04:05 <whitequark> well, the VMs which can do online migration, which is not all of them

04:06 <whitequark> but yeah. online migration is very neat.

04:08 <DocScrutinizer05> I bet Hetzner using something commercial grade decent for their company virtualization solution

04:09 <DocScrutinizer05> and for sure you/they can start those snapshots you can do now, on any other iron

04:09 <DocScrutinizer05> also only takes a minute

04:10 <DocScrutinizer05> heck, it took less than 10 minutes (prolly even <5) from *ordering* that server to ready-for-login

04:11 <DocScrutinizer05> another 2 minutes for restore of a on-site "tape" backup

04:11 <DocScrutinizer05> done

04:12 <DocScrutinizer05> (if only there was a decent generic server migration restore script)

04:13 <DocScrutinizer05> all those nasty little files in /etc that are actaully iron-specific

04:14 <DocScrutinizer05> "iron", like IP addr etc pp

04:15 <DocScrutinizer05> I wish somebody had written a script to exclude them from getting overwritten during restore

04:21 <whitequark> DocScrutinizer05: commercial grade?

04:21 <whitequark> hah

04:21 <whitequark> can you do `dmesg | grep -i xen` ?

04:22 <DocScrutinizer05> in a VM?

04:22 <whitequark> yes

04:23 <DocScrutinizer05> would be surprised to find anything like that

04:23 <whitequark> try it

04:23 <whitequark> you may be surprised

04:23 <DocScrutinizer05> no, I'm not. Zilch

04:24 <whitequark> ah

04:24 <whitequark> it's KVM

04:24 <whitequark> not Xen

04:24 <DocScrutinizer05> afaik Hetzner using vmware

04:24 <DocScrutinizer05> the enterbrise solution

04:25 <whitequark> does kvm also not grep in dmesg?

04:25 <whitequark> hmm, might be vmware, yeah. been a while since i cared about that host

04:28 <DocScrutinizer05> vsphere or similar stuff prolly

04:39 <kyak> whitequark: yep, i've already read it yesterday.. There is one interesting thing though. It turns out that when knowing plaintext and being able to modify ciphertext, it is possible to inject arbitrary data into every second block of ciphertext

04:40 <kyak> this has nothing to do with what i originally asked, but just an interesting fact that i came across while reading

04:40 <kyak> i'm talking about AES-CBC

04:40 <kyak> and i also understand larsc's comment regarding pinguin :)

04:41 <kyak> it also turns out that IV doesn't really matter

04:41 <kyak> if you don't know IV, but know the key, you will loose just the first block

04:42 <kyak> and this first block is sometimes filled with random data, so that the IV doesn't matter anyway

04:42 <kyak> the main purpose of IV is to make the same plaintext look different every time you encrypt it (wasn't obvious for me)

04:43 <kyak> so "salt it!" doesn't help with encryption by itself

04:43 <kyak> it just makes pinguins go away :)

04:50 <wpwrak> kyak: hmm, i wonder how these modes you're talking about work, if they really have the properties you describe

04:52 <wpwrak> one common pattern works as follows: you use the crypto algo to produce a "one-time pad", a unique bitstring. then you xor the plaintext with the OPT. that is you cyphertext.

04:52 <wpwrak> to reverse, you generate the same OPT, and XOR again.

04:53 <wpwrak> even if your algorithm works completely differently, you can always express it in such a way

04:56 <wpwrak> now, the interesting bit is thus how you generate that OTP. a common design pattern there would be a function that does some variation of hash(key, "salt", position) or hash(key, "salt", last_state)

04:58 <DocScrutinizer05> wpwrak: is your mail working again?

04:58 <wpwrak> only gmail

04:58 <whitequark> kyak: yes, malleability

04:59 <whitequark> that's why you need authenticated encryption

04:59 <whitequark> and why you need to authenticate *after* encrypting

05:04 <wpwrak> ideally, you'd ensure key integrity right at the start, e.g., by including an (unencrypted) good hash (CRC or such, something efficient) of the key :)

05:05 <wpwrak> works best of keys come from a relatively small vocabulary, e.g., human-readable words, not random bits or hashed passphrases :)

05:06 <wpwrak> (this sort of things has actually been done ;-)

05:15 <kyak> wpwrak: yes, the key word is malleability as whitequark pointed out.. http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/

05:16 <kyak> there is a picture in the article in the wiki as well that explains how AES-CBC decryptions works and how this attack becomes possible

05:20 <kyak> DocScrutinizer05: the pinguin: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_.28ECB.29

05:23 <wpwrak> hmm, i was hoping for whitequark to jump up and shout. but maybe he got a stroke instead :) just to be clear: the CRC stuff i described above would be rather horrible, for it would allow you to brute-force the password much more efficiently than by trying to decrypt the data and checking the integrity of the decrypted message

05:24 <wpwrak> likewise, it's a bad idea to have an unencrypted checksum of the plaintext

07:34 <wpwrak> DocScrutinizer05: evil sysadmin idea of the day: for /etc file, create some FUSE config file processor that you mount on /etc very early during boot. then let that one make substitutions. e.g., /etc/hostname -> <$HOST$> /etc/hosts 127.0.0.1 <$HOST$>.<$DOMAIN$> localhost etc.

07:34 <wpwrak> then all you need is /evil-sysadmin.conf

07:54 <wpwrak> hmm, debugging TLS in postfix sucks. it has a nice logging option .. that seems to be far too familiar with the works of schroedinger

08:02 <whitequark> wpwrak: I was afk

09:19 <wpwrak> DocScrutinizer05: bonus idea, for the evil sysadmin: make file names that expand as well. e.g., /etc/foo/<$HOST$>.conf

09:21 <wpwrak> access to /etc/foo/bar.conf would first try /etc/foo/bar.conf, then scan /etc/foo/ for expandable names and look for a match, then try /etc, etc. if it expands a dirname, add the remaining path and try again

09:22 <wpwrak> probably should allow climbing above the first expansion, though that may mess a bit with the user's head :)

14:29 <wpwrak> grrr. ssmtp proudly supports "AuthMethod" to set the SMTP authentication method. the server offers PLAIN and LOGIN. ssmtp always chooses LOGIN, no matter what i try.

14:30 <wpwrak> turns out it doesn't support PLAIN at all. plus, it doesn't check that AuthMethod has any value it actually supports. very funny :(

22:44 <wpwrak> new server is processing mail :) so far, everything looks healthy

23:30 <MistahDarcy> NanoNote 2, where are you?