2016-04-18 00:42 archang has joined #qi-hardware 2016-04-18 00:53 xiangfu has joined #qi-hardware 2016-04-18 00:53 fengling has joined #qi-hardware 2016-04-18 01:00 archang has quit [Remote host closed the connection] 2016-04-18 01:03 archang has joined #qi-hardware 2016-04-18 01:13 fengling has quit [Ping timeout: 240 seconds] 2016-04-18 01:14 archang has quit [Ping timeout: 276 seconds] 2016-04-18 01:16 fengling has joined #qi-hardware 2016-04-18 02:57 kristianpaul has joined #qi-hardware 2016-04-18 03:15 DocScrutinizer05 has quit [Disconnected by services] 2016-04-18 03:15 DocScrutinizer05 has joined #qi-hardware 2016-04-18 05:17 sandeepkr has joined #qi-hardware 2016-04-18 05:18 planasb_ has quit [] 2016-04-18 05:42 rjeffries has quit [Ping timeout: 264 seconds] 2016-04-18 06:31 sb0 has joined #qi-hardware 2016-04-18 06:59 jwhitmore has quit [Ping timeout: 276 seconds] 2016-04-18 08:43 pcercuei has joined #qi-hardware 2016-04-18 09:07 wej has joined #qi-hardware 2016-04-18 09:08 xiangfu has quit [Ping timeout: 250 seconds] 2016-04-18 09:13 jwhitmore has joined #qi-hardware 2016-04-18 09:19 lars_ has joined #qi-hardware 2016-04-18 09:30 jwhitmore has quit [Read error: Connection timed out] 2016-04-18 09:46 jwhitmore has joined #qi-hardware 2016-04-18 10:16 pcercuei has quit [Quit: brb] 2016-04-18 10:23 pcercuei has joined #qi-hardware 2016-04-18 10:33 fengling has quit [Ping timeout: 240 seconds] 2016-04-18 11:04 kanzure_ has joined #qi-hardware 2016-04-18 11:05 wpwrak_ has joined #qi-hardware 2016-04-18 11:05 wpwrak has quit [Disconnected by services] 2016-04-18 11:06 kanzure has quit [Ping timeout: 260 seconds] 2016-04-18 11:19 sandeepkr has quit [Ping timeout: 244 seconds] 2016-04-18 11:31 sandeepkr has joined #qi-hardware 2016-04-18 11:37 TIL gerber and gcode are both RS274 2016-04-18 11:44 fengling has joined #qi-hardware 2016-04-18 11:48 fengling has quit [Ping timeout: 240 seconds] 2016-04-18 11:56 MistahDarcy has quit [Ping timeout: 260 seconds] 2016-04-18 12:30 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? 2016-04-18 12:35 xiangfu has joined #qi-hardware 2016-04-18 12:37 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 2016-04-18 12:40 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 2016-04-18 12:40 wpwrak_ is now known as wpwrak 2016-04-18 13:01 kyak: yes it does 2016-04-18 13:01 knowing ciphertext and plaintext generally speaking gives you some sort of key 2016-04-18 13:01 what AES mode is it? 2016-04-18 13:06 xiangfu has quit [Ping timeout: 244 seconds] 2016-04-18 13:20 hmm, is it salted? 2016-04-18 13:22 yes. and also what is the KDF. 2016-04-18 13:25 kanzure_ is now known as kanzure 2016-04-18 13:25 kanzure has quit [Changing host] 2016-04-18 13:25 kanzure has joined #qi-hardware 2016-04-18 13:34 hoping for an incompetent implementation ? :) well, it may be worth a try ... 2016-04-18 13:46 sb0 has quit [Quit: Leaving] 2016-04-18 13:46 fengling has joined #qi-hardware 2016-04-18 13:47 sb0 has joined #qi-hardware 2016-04-18 13:50 hmm? 2016-04-18 13:51 fengling has quit [Ping timeout: 240 seconds] 2016-04-18 13:51 aah, well. Too tired to really wrap my head around asym crypt 2016-04-18 13:51 if AES is even asym 2016-04-18 13:53 DocScrutinizer05: what 2016-04-18 13:53 AES is symmetric 2016-04-18 13:53 thought as much 2016-04-18 13:53 wpwrak: if KDF is sha256(password), which is surprisingly common, then recovery is trivial 2016-04-18 13:54 so you try first byte with all 2^256 possible keys 2016-04-18 13:54 because for every file, the actual encryption key is the same 2016-04-18 13:54 no, just xor plaintext and ciphertext 2016-04-18 13:54 this gives you the key for the first block 2016-04-18 13:54 hehe 2016-04-18 13:54 if it's AES-ECB, then you just xor all other ciphertext blocks 2016-04-18 13:54 if it's AES-CTR, then you need to do some manipulation to spin a counter in the key 2016-04-18 13:55 if it's AES-CBC, you need to unmix the IV and then mix the another one back 2016-04-18 13:55 similar for CFB and OFB 2016-04-18 13:56 so really the key here is the KDF 2016-04-18 13:57 if they used a KDF with a large stretch factor *and* a salt unique for each file, then you are screwed 2016-04-18 13:58 yup, that's what I thought 2016-04-18 13:58 salt would make seemingly similar text be different in encrypted form 2016-04-18 13:58 "fortunately", most people writing crypto suck really badly at it 2016-04-18 13:58 you still see ECB mode used in the wild 2016-04-18 14:04 and we all know ECB is bad because you can see the penguin 2016-04-18 14:20 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 2016-04-18 14:28 rjeffries has joined #qi-hardware 2016-04-18 15:07 jwhitmore has quit [Ping timeout: 244 seconds] 2016-04-18 15:13 ,oO(???) 2016-04-18 15:20 this image was also used to show the xor problem of ECB 2016-04-18 15:21 sb0 has quit [Quit: Leaving] 2016-04-18 15:36 sb0 has joined #qi-hardware 2016-04-18 15:37 whitequark: thanks! that's way beyond my comprehension, but at least i have something to think about now :) 2016-04-18 15:38 that question is quite practical. I'd like to store encrypted files in cloud, which is owned by not me 2016-04-18 15:39 so i was thinking about how to encrypt individual files 2016-04-18 15:39 having a separate encrypted image or "volume" seems like too much of a hassle 2016-04-18 15:41 but being able to recover key by simply xor'ing.. that's scary 2016-04-18 15:42 salt it 2016-04-18 15:42 yeah 2016-04-18 15:42 and don't use anything with AES 2016-04-18 15:42 generally speaking, bare AES is too hard to get right to easily ascertain whether a particular implementation contains glaring holes 2016-04-18 15:45 if not AES, then what? 2016-04-18 15:45 xsalsa20poly1305 2016-04-18 15:46 wait, what? that's my password! 2016-04-18 15:46 AES-GCM also works if implemented correctly (but there were some high-profile failures, IIRC) 2016-04-18 15:48 fengling has joined #qi-hardware 2016-04-18 15:52 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) 2016-04-18 15:52 (though that could also be implemented on top of a simpler read N + check at EOF implementation) 2016-04-18 15:53 fengling has quit [Ping timeout: 240 seconds] 2016-04-18 15:55 https://nacl.cr.yp.to/stream.html 2016-04-18 15:55 literally crypto_stream 2016-04-18 15:56 note that 'validation', by which you mean 'authentication', has to be done separately 2016-04-18 15:56 you can calculate a checksum using any strong hash in any way you would like, and then use crypto_auth 2016-04-18 15:58 (link) oh wow. doesn't get any more obvious, does it ? :) thanks ! 2016-04-18 16:00 hmm, but no, that isn't actually what i was looking for 2016-04-18 16:00 how so? 2016-04-18 16:01 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. 2016-04-18 16:02 no, you cannot be compatible with crypto_box. 2016-04-18 16:02 second, these functions just give me the encryption/decryption part of crypto_box but don't let me start at arbitrary positions 2016-04-18 16:03 why not ? 2016-04-18 16:03 crypto_box is an authenticated encryption primitive 2016-04-18 16:03 as for arbitrary positions, sure you can 2016-04-18 16:03 use the _xorstream version, then junk X bytes to start at position X 2016-04-18 16:04 but then i still have to store these X bytes 2016-04-18 16:04 no 2016-04-18 16:04 they're generated on the fly 2016-04-18 16:04 _xorstream is basically a wrapper around a CSPRNG 2016-04-18 16:05 hmm, where is _xorstream ? all i see is _stream_xor 2016-04-18 16:05 and that one doesn't expose the "on the fly" part 2016-04-18 16:05 yeah, _stream_xor 2016-04-18 16:05 of course, inside it exists 2016-04-18 16:05 ah 2016-04-18 16:06 why can't you use crypto_box, anyway? 2016-04-18 16:06 derive the nonce from the stream position 2016-04-18 16:06 done 2016-04-18 16:06 i don't want to have to keep everything in memory 2016-04-18 16:07 and the box format is nice in half my use cases, so i don't want to tweak that 2016-04-18 16:07 so if i'm on a pc, i just use crypto_box. on anelok, i use the streaming variant 2016-04-18 16:07 well, one thing you shouldn't do is make your own primitives 2016-04-18 16:08 that's why i'm looking for an existing implementation :) 2016-04-18 16:08 so again 2016-04-18 16:08 why can't you use crypto_box? 2016-04-18 16:08 make many small messages (< messy. and i the ideal read size may be very small 2016-04-18 16:10 (plus, the ideal read size may vary) 2016-04-18 16:10 well, if you want random authenticated reads, that's what you get 2016-04-18 16:11 opening the box of _stream_xor and saving/restoring state should be fine 2016-04-18 16:11 so if you can use that and a separate authentication step, it should be doable 2016-04-18 16:12 yes, i basically need, at the "bottom": open(), read(), dup() (to copy the current generator and hash state), check_hash_at_eof() 2016-04-18 16:12 read() would be an unauthenticated read 2016-04-18 16:13 the authenticated read is then read(state), state2 = dup(state), while (read(state2)); check_hash_at_eof(state2); 2016-04-18 16:16 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. 2016-04-18 16:23 sb0 has quit [Quit: Leaving] 2016-04-18 16:46 pcercuei has quit [Quit: leaving] 2016-04-18 17:13 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? 2016-04-18 17:18 Guest24524 is now known as pigeons 2016-04-18 17:21 jwhitmore has joined #qi-hardware 2016-04-18 17:22 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. 2016-04-18 17:23 so the real question seems to be "which cloud-compatible encryption tools use AES (or better) correctly" 2016-04-18 17:24 and that would imply the question "what sort of cloud interface are we talking about ?" :) 2016-04-18 17:27 but it's me who will be encrypting :) 2016-04-18 17:27 i will encrypt files and put them on e.g. dropbox 2016-04-18 17:30 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 ? 2016-04-18 17:30 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 2016-04-18 17:31 yeah, that's basically what i need. I read that gpg does the job, but i now want to know details :) 2016-04-18 17:32 jwhitmore has quit [Ping timeout: 252 seconds] 2016-04-18 17:37 yes, the salt / IV should be attached to your file. else, you'd have to rememember it "offline", too. hardly convenient. 2016-04-18 17:52 a salt IV can safe lives 2016-04-18 18:15 jwhitmore has joined #qi-hardware 2016-04-18 18:28 yeah, and expert use NaCl :) 2016-04-18 18:29 hmm. server still down :( how hard can it be to set up a new box to distribution defaults and copy over the old disk ? 2016-04-18 18:29 pcercuei has joined #qi-hardware 2016-04-18 18:30 i guess soon at least i won't have to worry anymore about losing mails when is bring up a dodgy configuration ... 2016-04-18 18:53 fengling has joined #qi-hardware 2016-04-18 18:58 fengling has quit [Ping timeout: 240 seconds] 2016-04-18 19:04 jwhitmore has quit [Ping timeout: 250 seconds] 2016-04-18 19:11 sandeepkr has quit [Ping timeout: 246 seconds] 2016-04-18 19:45 MistahDarcy has joined #qi-hardware 2016-04-18 19:45 MistahDarcy has joined #qi-hardware 2016-04-18 19:56 jwhitmore has joined #qi-hardware 2016-04-18 20:22 jwhitmore has quit [Ping timeout: 240 seconds] 2016-04-18 20:55 fengling has joined #qi-hardware 2016-04-18 21:00 fengling has quit [Ping timeout: 240 seconds] 2016-04-18 21:03 jwhitmore has joined #qi-hardware 2016-04-18 21:16 pcercuei has quit [Ping timeout: 268 seconds] 2016-04-18 21:34 MistahDarcy has quit [Ping timeout: 240 seconds] 2016-04-18 21:38 jwhitmore has quit [Ping timeout: 240 seconds] 2016-04-18 21:43 MistahDarcy has joined #qi-hardware 2016-04-18 21:48 MistahDarcy has quit [Ping timeout: 252 seconds] 2016-04-18 21:51 MistahDarcy has joined #qi-hardware 2016-04-18 21:57 MistahDarcy has quit [Ping timeout: 252 seconds] 2016-04-18 22:58 fengling has joined #qi-hardware 2016-04-18 23:03 fengling has quit [Ping timeout: 240 seconds] 2016-04-18 23:25 arossdotme has quit [Ping timeout: 276 seconds] 2016-04-18 23:30 arossdotme has joined #qi-hardware