|
|
#
?
Feb 16, 2015 13:29
|
|
|
|
| # ? Jun 7, 2024 03:53 |
|
|
ahmeni posted:what the gently caress are you going to do with $2300 worth of Bitcoin anyways hodl
|
|
#
?
Feb 16, 2015 13:46
|
|
|
why do people want to keep making IM encryption services that pass through their own servers when all most people want to encrypt IMs for is to be weirdos and share child porn or discuss hacking or w/e which means you're the one who's gonna get in trouble too
|
|
#
?
Feb 16, 2015 13:49
|
|
|
Jewel posted:why do people want to keep making IM encryption services that pass through their own servers when all most people want to encrypt IMs for is to be weirdos and share child porn or discuss hacking or w/e which means you're the one who's gonna get in trouble too the encryption isn't just for user security, it's for security of the provider and the provider's employees rrom insiders, crime organizations, and governments centralization is key to usability, thanks to nat, the practicalities of key exchanges, and the fact that key signing parties are basically dead as a concept be cool if apple exposed some way to authenticate your iMessage with somebody offline (I.e. A two word authenticator like signal/red phone/text secure use)
|
|
#
?
Feb 16, 2015 13:59
|
|
|
ofc when you're communicating via a server which is outside of your control then any perceived security goes out the window, no matter how encrypted your connection is (which is the point jewel was making). as cocoa said centralisation is a matter of usability, the most important point made being working around NAT. i guess its a toss-up between whether you want to make an actually secure messaging app which requires heaps of cjing or make a popular yet intrinsically insecure "secure" messaging app
|
|
#
?
Feb 16, 2015 14:28
|
|
|
i got my new CC today and was trying to think of the best way to dispose of my old CC. i mean, i could slice it up and then throw it in the trash but the bad guys could go through my trash and piece it back together!!! then it hit me:  i sent it to live with my posts
|
|
#
?
Feb 16, 2015 15:39
|
|
|
not a yospos approved toilet where is the shelf to preview your posting
|
|
#
?
Feb 16, 2015 15:43
|
|
|
its redacted, i didnt want to reveal what model the toilet was
|
|
#
?
Feb 16, 2015 15:49
|
|
|
cheese-cube posted:i got my new CC today and was trying to think of the best way to dispose of my old CC. i mean, i could slice it up and then throw it in the trash but the bad guys could go through my trash and piece it back together!!! I ripped my old one to pieces, extracted the chip, swaddled it in a paper towel, drizzled a but of cooking oil on it, and burned it
|
|
#
?
Feb 16, 2015 15:57
|
|
|
hope you don't have a septic tank, friend.
|
|
#
?
Feb 16, 2015 15:58
|
|
|
Cocoa Crispies posted:I ripped my old one to pieces, extracted the chip, swaddled it in a paper towel, drizzled a but of cooking oil on it, and burned it yeah see that sounds like a whole lotta effort. sure i guess someone could piece my card back together but i am safe in the knowledge that they had to wade through my poo poo to do so Parallel Paraplegic posted:hope you don't have a septic tank, friend. i live in a first world country so nope (j/k, i know tanks are still surprisingly prevalent).
|
|
#
?
Feb 16, 2015 15:59
|
|
|
cheese-cube posted:ofc when you're communicating via a server which is outside of your control then any perceived security goes out the window, no matter how encrypted your connection is (which is the point jewel was making). as cocoa said centralisation is a matter of usability, the most important point made being working around NAT. you can design protocols that can't be mitm'd by a server: s/mime, gpg the challenge then becomes transfer of identity in the form of key material, and that key material has to be big and entropic enough to both not be brute-force able and therefore not easy for humans to communicate the signal thing basically does some kind of key exchange (diffe-Hellman?) and uses some variables in that protocol to pick random words that should be visible on both ends, and be in feasible to mitm while keeping the same words
|
|
#
?
Feb 16, 2015 16:01
|
|
|
cheese-cube posted:yeah see that sounds like a whole lotta effort. sure i guess someone could piece my card back together but i am safe in the knowledge that they had to wade through my poo poo to do so Yeah but fire is inherently pleasing, more so than flushing a toilet
|
|
#
?
Feb 16, 2015 16:01
|
|
|
Cocoa Crispies posted:you can design protocols that can't be mitm'd by a server: s/mime, gpg unless I'm not properly undestanding things the secure connection is negotiated between the clients and the server, not eachother. if that is the case then how can you ensure full end-to-end security? edit: i mean, you cannot realistically expect that the negotiated key used to encrypt a session would not be snooped or mitm'ed by the server. it's really an argument of trust wherein the answer is always "if you don't control it, then no, unless you control it, then maybe". Cocoa Crispies posted:Yeah but fire is inherently pleasing, more so than flushing a toilet that is true, however i rent and am unwilling to run the risk of fire damage. alternate answer: why do i post if fire is more pleasing than flushing a toilet Pile Of Garbage fucked around with this message at 16:11 on Feb 16, 2015 |
|
#
?
Feb 16, 2015 16:07
|
|
|
 infosec superstar dan kaminski
|
|
#
?
Feb 16, 2015 16:11
|
|
|
cheese-cube posted:unless I'm not properly undestanding things the secure connection is negotiated between the clients and the server, not eachother. if that is the case then how can you ensure full end-to-end security? It's possible to have end-to-end encryption where the server is a dumb intermediary that only knows whether two people are communicating, and can't find out the content of the messages. Encryption is easy. The hard part, which no-one has really tackled adequately, is the problem of authentication. Having an encrypted connection doesn't help much if you're on a direct line to the NSA instead of to the person you thought you were talking to. e: it's totally possibly for two parties to exchange keys without an intermediary being able to sniff them. it's been possible since the 70's. the hard part, as I said, is making sure that the person you're exchanging keys with is actually the person you want to talk to. Jabor fucked around with this message at 16:15 on Feb 16, 2015 |
|
#
?
Feb 16, 2015 16:12
|
|
|
OSI bean dip posted:
 it's uncanny
|
|
#
?
Feb 16, 2015 16:13
|
|
|
Jabor posted:It's possible to have end-to-end encryption where the server is a dumb intermediary that only knows whether two people are communicating, and can't find out the content of the messages. Encryption is easy. i agree that you can perform secure key exchange between two parties when said parties are communicating directly. however my issue lies with the usage of an intermediary to perform a key exchange or whatnot. you can never be 100% sure that said server is performing MITM without your knowledge. sure you can do this securely but you can never fully trust the intermediary. edit: in retrospect i guess im almost engaging in fishmech style semanticism, you can never trust the platform etc. you're still right secure key exchange with minimal exposure to the intermediary can be performed. Pile Of Garbage fucked around with this message at 16:22 on Feb 16, 2015 |
|
#
?
Feb 16, 2015 16:20
|
|
|
cheese-cube posted:i agree that you can perform secure key exchange between two parties when said parties are communicating directly. however my issue lies with the usage of an intermediary to perform a key exchange or whatnot. you can never be 100% sure that said server is performing MITM without your knowledge. sure you can do this securely but you can never fully trust the intermediary. You do realize that every single key exchange over the internet happens through dozens if not hundreds of intermediaries, right?
|
|
#
?
Feb 16, 2015 16:24
|
|
|
cheese-cube posted:i agree that you can perform secure key exchange between two parties when said parties are communicating directly. however my issue lies with the usage of an intermediary to perform a key exchange or whatnot. you can never be 100% sure that said server is performing MITM without your knowledge. sure you can do this securely but you can never fully trust the intermediary. you guys are both saying the same thing in different words. a server MITM'ing something is basically equivalent, technologically, to you being connected to the NSA instead of your friend, and both are solved by authentication.
|
|
#
?
Feb 16, 2015 16:25
|
|
|
how do you authenticate without the NSA mitm your authentication?
|
|
#
?
Feb 16, 2015 16:29
|
|
|
Shaggar posted:how do you authenticate without the NSA mitm your authentication? that's the whole reason authentication is so hard, there aren't really particularly good ways of doing that since the web of trust wound up being a big dumb nerd circlejerk and certificate authorities have all been compromised.
|
|
#
?
Feb 16, 2015 16:31
|
|
|
cheese-cube posted:i agree that you can perform secure key exchange between two parties when said parties are communicating directly. however my issue lies with the usage of an intermediary to perform a key exchange or whatnot. you can never be 100% sure that said server is performing MITM without your knowledge. sure you can do this securely but you can never fully trust the intermediary. with the right constructs you absolutely can Shaggar posted:how do you authenticate without the NSA mitm your authentication? irl or over voice (c.f. signal) where the effort to fake both parties saying different authentication words to each other would probably outweigh the benefit
|
|
#
?
Feb 16, 2015 16:33
|
|
|
Jabor posted:You do realize that every single key exchange over the internet happens through dozens if not hundreds of intermediaries, right? yeah that's what i meant in my edit, i'm just conflating things between a direct intermediary and transparent intermediaries which are always there regardless of whatever service you use. Parallel Paraplegic posted:you guys are both saying the same thing in different words. a server MITM'ing something is basically equivalent, technologically, to you being connected to the NSA instead of your friend, and both are solved by authentication. i guess the point i was trying to make is that if you are using a secure messaging service directly between you and your mate then i they'll have to black-bag your mate to get at the deets. ofc if you are using a "secure" messaging service which for usability negotiates all connections via their server then all that needs to happen is a nat. security letter being sent. this is of course a purely hyperbolic example and not meant to represent the majority of users. i was really just trying to make a distinction that apps cannot offer both security and usability as they're contraindicated (for now, i guess). it all really comes down to who you're trying to secure yourself against i guess 
|
|
#
?
Feb 16, 2015 16:34
|
|
|
mitm doesnt just mean changing the contents of the messages but being able to intercept them doing it irl or over phone does not get you out of these problems
|
|
#
?
Feb 16, 2015 16:34
|
|
|
cheese-cube posted:i guess the point i was trying to make is that if you are using a secure messaging service directly between you and your mate then i they'll have to black-bag your mate to get at the deets. ofc if you are using a "secure" messaging service which for usability negotiates all connections via their server then all that needs to happen is a nat. security letter being sent. this is of course a purely hyperbolic example and not meant to represent the majority of users. Well yeah, because literally no-one has a direct connection to anyone else. They literally do not exist unless you're a large enough entity to put fibre in the ground yourself - and even then, odds are that someone's got a tap on your lines anyway. The whole point if encryption is to solve the "I don't have a secure, direct connection" problem.
|
|
#
?
Feb 16, 2015 16:39
|
|
|
MORE CURLY FRIES posted:mitm doesnt just mean changing the contents of the messages but being able to intercept them i think that's where a lot of confusion comes from. MITM means exactly what it says: you are the guy in the middle. you can see the traffic but you don't necessarily have to do anything. people often conflate MITM with the attack vectors made capable by MITM, e.g. replay-attacks, cookie stealing etc. often times you can gain far more by simply sitting there, logging and forwarding.
|
|
#
?
Feb 16, 2015 16:43
|
|
|
 "hockey publisher" are a signal/redphone "authentication string" that are generated from a bunch of different keys in the ZRTP and SRTP protocols packet capturing the entire conversation is easy, but being able to decrypt it isn't being able to replace packets in the stream will most likely change the authentication string, and if the participants in the call know what each other sound like (the audio quality is decent enough) being able to replace the authentication string in real time as both parties read it back to each other makes it infeasible you might be able to make a case that the NSA or any of the other big rich countries' equivalents could do it, but if you had them as an enemy, you'd know
|
|
#
?
Feb 16, 2015 16:47
|
|
|
Cocoa Crispies posted:irl or over voice (c.f. signal) where the effort to fake both parties saying different authentication words to each other would probably outweigh the benefit Isn't there an NSA program that was exposed to do exactly this (fake one of the code words)?
|
|
#
?
Feb 16, 2015 16:49
|
|
|
cheese-cube posted:i live in a first world country so nope (j/k, i know tanks are still surprisingly prevalent).
|
|
#
?
Feb 16, 2015 16:52
|
|
|
Volmarias posted:Isn't there an NSA program that was exposed to do exactly this (fake one of the code words)? [citation needed] but maybe, i mean, we know we can't trust the four-octet gpg key checksums anymore because GPUs are fast
|
|
#
?
Feb 16, 2015 16:55
|
|
|
is it possible to hijack an onion domain by generating the domain name again? it doesnt seem like it would be that hard tbh
|
|
#
?
Feb 16, 2015 17:06
|
|
|
Maximum Leader posted:is it possible to hijack an onion domain by generating the domain name again? it doesnt seem like it would be that hard tbh the domain name is derived from key material, so if you can generate a key that derives to the same domain name, you can impersonate them so set your GPUs to "facebookcorewwwi.onion" and also trick a cert cartel member into signing an https cert for it (in this case it's facebook's regular EV cert, with a bunch of alt names includion a handful of onion addresses) in this case the length of the thing and the human-readability of it ("facebook core www infrastructure") probably makes it harder to fake than something like "silkroad6ownowfk.onion"
|
|
#
?
Feb 16, 2015 17:17
|
|
|
lol if ur not doing all voice comm over landlines and antique military surplus voice scramblers with preloaded codeplugs shared beforehand
|
|
#
?
Feb 16, 2015 17:42
|
|
|
atomicthumbs posted:lol if ur not doing all voice comm over landlines and antique military surplus voice scramblers with preloaded codeplugs shared beforehand best infosec: never have anyone to communicate with
|
|
#
?
Feb 16, 2015 17:55
|
|
|
are we going to encounter a reverse cyberpunk future where leet hackers are using modems with clipper chips because the government has forgotten how to decrypt them due to all knowledge being lost within the bureaucratic matrices of the master computer? i pray i live that long so that i may die laffing
|
|
#
?
Feb 16, 2015 18:03
|
|
|
Cocoa Crispies posted:[citation needed] but maybe, i mean, we know we can't trust the four-octet gpg key checksums anymore because GPUs are fast to be fair to ZRTP, short authentication strings are only used during the first key exchange. successive conversations use a sequence of keys derived from the original master key of course a MitM can force a ZRTP security issue, invalidating the cached keys and forcing alice and bob to repeat the SAS exchange
|
|
#
?
Feb 16, 2015 18:06
|
|
|
cheese-cube posted:bureaucratic matrices of the master computer mods
|
|
#
?
Feb 16, 2015 18:07
|
|
|
atomicthumbs posted:lol if ur not doing all voice comm over landlines and antique military surplus voice scramblers with preloaded codeplugs shared beforehand China's Most Secret Weapon: The Messenger Pigeon
|
|
#
?
Feb 16, 2015 18:10
|
|
|
|
| # ? Jun 7, 2024 03:53 |
|
|
cheese-cube posted:i got my new CC today and was trying to think of the best way to dispose of my old CC. i mean, i could slice it up and then throw it in the trash but the bad guys could go through my trash and piece it back together!!! enjoy having to snake your drains i guess
|
|
#
?
Feb 16, 2015 18:52
|
|
