| 00:42.13 | *** join/#qi-hardware archang (~archang@111.198.29.53) |
| 00:53.37 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 00:53.56 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 01:03.31 | *** join/#qi-hardware archang (~archang@111.198.29.53) |
| 01:16.04 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 02:57.39 | *** join/#qi-hardware kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 03:15.40 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 05:17.08 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 06:31.42 | *** join/#qi-hardware sb0 (~lekernel@123202036228.ctinets.com) |
| 08:43.39 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 09:07.56 | *** join/#qi-hardware wej (~j@2a00:1768:2001:7:1::3e) |
| 09:13.06 | *** join/#qi-hardware jwhitmore (~jwhitmore@91.123.229.11) |
| 09:19.20 | *** join/#qi-hardware lars_ (~lars@eisbaer.ursus-maritimus.org) |
| 09:46.29 | *** join/#qi-hardware jwhitmore (~jwhitmore@91.123.229.11) |
| 10:23.06 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 11:04.57 | *** join/#qi-hardware kanzure_ (~kanzure@bryan.fairlystable.org) |
| 11:05.37 | *** join/#qi-hardware wpwrak_ (~werner@102-185-231-201.fibertel.com.ar) |
| 11:31.43 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 11:37.51 | whitequark | TIL gerber and gcode are both RS274 |
| 11:44.09 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 12:30.18 | kyak | i have two files both encrypted with the same key (AES-256). I also have a plain-text version of one of the files. Does it help me recover another file? |
| 12:35.14 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 12:37.44 | wpwrak_ | as long as the encrypted version of the 3rd file is identical to the encrypted version of the file for which you have the unencrypted version, too, then yes, it helps a lot |
| 12:40.13 | wpwrak_ | in all other cases, probably not in any way you'd consider significant. see also: https://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Known_attacks |
| 13:01.11 | whitequark | kyak: yes it does |
| 13:01.37 | whitequark | knowing ciphertext and plaintext generally speaking gives you some sort of key |
| 13:01.40 | whitequark | what AES mode is it? |
| 13:20.55 | DocScrutinizer05 | hmm, is it salted? |
| 13:22.12 | whitequark | yes. and also what is the KDF. |
| 13:25.26 | *** join/#qi-hardware kanzure (~kanzure@unaffiliated/kanzure) |
| 13:34.48 | wpwrak | hoping for an incompetent implementation ? :) well, it may be worth a try ... |
| 13:46.16 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 13:47.06 | *** join/#qi-hardware sb0 (~lekernel@123202036228.ctinets.com) |
| 13:50.21 | DocScrutinizer05 | hmm? |
| 13:51.21 | DocScrutinizer05 | aah, well. Too tired to really wrap my head around asym crypt |
| 13:51.34 | DocScrutinizer05 | if AES is even asym |
| 13:53.13 | whitequark | DocScrutinizer05: what |
| 13:53.18 | whitequark | AES is symmetric |
| 13:53.42 | DocScrutinizer05 | thought as much |
| 13:53.59 | whitequark | wpwrak: if KDF is sha256(password), which is surprisingly common, then recovery is trivial |
| 13:54.07 | DocScrutinizer05 | so you try first byte with all 2^256 possible keys |
| 13:54.08 | whitequark | because for every file, the actual encryption key is the same |
| 13:54.17 | whitequark | no, just xor plaintext and ciphertext |
| 13:54.24 | whitequark | this gives you the key for the first block |
| 13:54.30 | DocScrutinizer05 | hehe |
| 13:54.36 | whitequark | if it's AES-ECB, then you just xor all other ciphertext blocks |
| 13:54.48 | whitequark | if it's AES-CTR, then you need to do some manipulation to spin a counter in the key |
| 13:55.26 | whitequark | if it's AES-CBC, you need to unmix the IV and then mix the another one back |
| 13:55.59 | whitequark | similar for CFB and OFB |
| 13:56.38 | whitequark | so really the key here is the KDF |
| 13:57.37 | whitequark | if they used a KDF with a large stretch factor *and* a salt unique for each file, then you are screwed |
| 13:58.02 | DocScrutinizer05 | yup, that's what I thought |
| 13:58.48 | DocScrutinizer05 | salt would make seemingly similar text be different in encrypted form |
| 13:58.48 | whitequark | "fortunately", most people writing crypto suck really badly at it |
| 13:58.59 | whitequark | you still see ECB mode used in the wild |
| 14:04.03 | larsc | and we all know ECB is bad because you can see the penguin |
| 14:20.40 | wpwrak | or the girl. grmbl, no where is the original from this one ? i think i saw it first in some ccc presentation. http://www.turbocrypt.com/vpics/9a8f098c615a425eab6d17c804dd67ae/allpics/original_and_encrypted_image.jpg |
| 14:28.13 | *** join/#qi-hardware rjeffries (~rjeffries@pool-74-106-217-43.snloca.dsl-w.verizon.net) |
| 15:13.04 | DocScrutinizer05 | ,oO(???) |
| 15:20.08 | wpwrak | this image was also used to show the xor problem of ECB |
| 15:36.31 | *** join/#qi-hardware sb0 (~lekernel@123202036228.ctinets.com) |
| 15:37.43 | kyak | whitequark: thanks! that's way beyond my comprehension, but at least i have something to think about now :) |
| 15:38.46 | kyak | that question is quite practical. I'd like to store encrypted files in cloud, which is owned by not me |
| 15:39.13 | kyak | so i was thinking about how to encrypt individual files |
| 15:39.48 | kyak | having a separate encrypted image or "volume" seems like too much of a hassle |
| 15:41.39 | kyak | but being able to recover key by simply xor'ing.. that's scary |
| 15:42.04 | larsc | salt it |
| 15:42.27 | whitequark | yeah |
| 15:42.32 | whitequark | and don't use anything with AES |
| 15:42.59 | whitequark | generally speaking, bare AES is too hard to get right to easily ascertain whether a particular implementation contains glaring holes |
| 15:45.32 | kyak | if not AES, then what? |
| 15:45.51 | whitequark | xsalsa20poly1305 |
| 15:46.11 | kyak | wait, what? that's my password! |
| 15:46.19 | whitequark | AES-GCM also works if implemented correctly (but there were some high-profile failures, IIRC) |
| 15:48.49 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 15:52.04 | wpwrak | whitequark: btw, you wouldn't happen to know of a stream version of crypto_box ? i.e., instead of working on the whole message, be able to extract N bytes at a time ? (plus validation, i.e., after a read to position X, have an optional read plus decrypting and hashing to the end, to ensure that the chunk just delivered is correct) |
| 15:52.56 | wpwrak | (though that could also be implemented on top of a simpler read N + check at EOF implementation) |
| 15:55.14 | whitequark | https://nacl.cr.yp.to/stream.html |
| 15:55.21 | whitequark | literally crypto_stream |
| 15:56.12 | whitequark | note that 'validation', by which you mean 'authentication', has to be done separately |
| 15:56.57 | whitequark | you can calculate a checksum using any strong hash in any way you would like, and then use crypto_auth |
| 15:58.46 | wpwrak | (link) oh wow. doesn't get any more obvious, does it ? :) thanks ! |
| 16:00.15 | wpwrak | hmm, but no, that isn't actually what i was looking for |
| 16:00.47 | whitequark | how so? |
| 16:01.01 | wpwrak | first, i want to be compatible with crypto_box. alas, the usual implementations don't export some of the building blocks. so it would be nice to be able to redoing that. |
| 16:02.46 | whitequark | no, you cannot be compatible with crypto_box. |
| 16:02.59 | wpwrak | second, these functions just give me the encryption/decryption part of crypto_box but don't let me start at arbitrary positions |
| 16:03.06 | wpwrak | why not ? |
| 16:03.13 | whitequark | crypto_box is an authenticated encryption primitive |
| 16:03.40 | whitequark | as for arbitrary positions, sure you can |
| 16:03.52 | whitequark | use the _xorstream version, then junk X bytes to start at position X |
| 16:04.07 | wpwrak | but then i still have to store these X bytes |
| 16:04.10 | whitequark | no |
| 16:04.15 | whitequark | they're generated on the fly |
| 16:04.51 | whitequark | _xorstream is basically a wrapper around a CSPRNG |
| 16:05.16 | wpwrak | hmm, where is _xorstream ? all i see is _stream_xor |
| 16:05.30 | wpwrak | and that one doesn't expose the "on the fly" part |
| 16:05.32 | whitequark | yeah, _stream_xor |
| 16:05.35 | wpwrak | of course, inside it exists |
| 16:05.48 | whitequark | ah |
| 16:06.07 | whitequark | why can't you use crypto_box, anyway? |
| 16:06.13 | whitequark | derive the nonce from the stream position |
| 16:06.14 | whitequark | done |
| 16:06.41 | wpwrak | i don't want to have to keep everything in memory |
| 16:07.12 | wpwrak | and the box format is nice in half my use cases, so i don't want to tweak that |
| 16:07.44 | wpwrak | so if i'm on a pc, i just use crypto_box. on anelok, i use the streaming variant |
| 16:07.51 | whitequark | well, one thing you shouldn't do is make your own primitives |
| 16:08.09 | wpwrak | that's why i'm looking for an existing implementation :) |
| 16:08.15 | whitequark | so again |
| 16:08.19 | whitequark | why can't you use crypto_box? |
| 16:08.40 | whitequark | make many small messages (<<memory size) |
| 16:09.08 | wpwrak | messy. and i the ideal read size may be very small |
| 16:10.28 | wpwrak | (plus, the ideal read size may vary) |
| 16:10.51 | whitequark | well, if you want random authenticated reads, that's what you get |
| 16:11.11 | whitequark | opening the box of _stream_xor and saving/restoring state should be fine |
| 16:11.24 | whitequark | so if you can use that and a separate authentication step, it should be doable |
| 16:12.37 | wpwrak | yes, i basically need, at the "bottom": open(), read(), dup() (to copy the current generator and hash state), check_hash_at_eof() |
| 16:12.50 | wpwrak | read() would be an unauthenticated read |
| 16:13.55 | wpwrak | the authenticated read is then read(state), state2 = dup(state), while (read(state2)); check_hash_at_eof(state2); |
| 16:16.33 | wpwrak | the idea is to let anelok store small blobs in addition to passwords. for example, private keys. they're small enough that encryption/etc. is fast, but easily big enough that it hurts on the memory size. |
| 17:13.21 | kyak | whitequark: it says here https://en.wikipedia.org/wiki/Known-plaintext_attack that "Modern ciphers such as Advanced Encryption Standard are not currently known to be susceptible to known-plaintext attacks.". So it not as simple as just xor'ing? |
| 17:21.36 | *** join/#qi-hardware jwhitmore (~jwhitmore@109.79.194.242) |
| 17:22.24 | wpwrak | kyak: this refers to AES as a building block. AES itself isn't vulnerable. however, if you use the AES building block improperly, then you may create a vulnerability. |
| 17:23.35 | wpwrak | so the real question seems to be "which cloud-compatible encryption tools use AES (or better) correctly" |
| 17:24.04 | wpwrak | and that would imply the question "what sort of cloud interface are we talking about ?" :) |
| 17:27.35 | kyak | but it's me who will be encrypting :) |
| 17:27.48 | kyak | i will encrypt files and put them on e.g. dropbox |
| 17:30.23 | wpwrak | okay, so all you need is a standalone encryption tool that takes a file and a key, and produces a properly encrypted file, or vice versa ? |
| 17:30.36 | kyak | regarding salt.. i understood that both gpg and openssl salt automatically. This somehow adds with my key (a password). But where is the salt being saved? In the encrypted file? I should probably go and read about how symmetric encryption works |
| 17:31.09 | kyak | yeah, that's basically what i need. I read that gpg does the job, but i now want to know details :) |
| 17:37.35 | wpwrak | yes, the salt / IV should be attached to your file. else, you'd have to rememember it "offline", too. hardly convenient. |
| 17:52.38 | larsc | a salt IV can safe lives |
| 18:15.13 | *** join/#qi-hardware jwhitmore (~jwhitmore@109.79.194.242) |
| 18:28.45 | wpwrak | yeah, and expert use NaCl :) |
| 18:29.39 | wpwrak | hmm. server still down :( how hard can it be to set up a new box to distribution defaults and copy over the old disk ? |
| 18:29.57 | *** join/#qi-hardware pcercuei (~pcercuei@2a03:a680:2020:ff1d:56e4:bdff:fe5f:1f4e) |
| 18:30.31 | wpwrak | i guess soon at least i won't have to worry anymore about losing mails when is bring up a dodgy configuration ... |
| 18:53.27 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 19:45.15 | *** join/#qi-hardware MistahDarcy (~crash@66-169-224-12.dhcp.gvrb.ca.charter.com) |
| 19:45.16 | *** join/#qi-hardware MistahDarcy (~crash@fsf/member/MistahDarcy) |
| 19:56.38 | *** join/#qi-hardware jwhitmore (~jwhitmore@109.79.194.242) |
| 20:55.59 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 21:03.25 | *** join/#qi-hardware jwhitmore (~jwhitmore@109.79.194.242) |
| 21:43.42 | *** join/#qi-hardware MistahDarcy (~crash@fsf/member/MistahDarcy) |
| 21:51.29 | *** join/#qi-hardware MistahDarcy (~crash@fsf/member/MistahDarcy) |
| 22:58.48 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 23:30.37 | *** join/#qi-hardware arossdotme (~zxy@host-78-151-194-102.as13285.net) |
