thefloweringash has quit [Ping timeout: 260 seconds]
enick_676 has quit [Ping timeout: 268 seconds]
alj[m] has quit [Ping timeout: 244 seconds]
ncm[m] has quit [Ping timeout: 244 seconds]
colemickens has quit [Ping timeout: 244 seconds]
sab7iryudpgf6[m] has quit [Ping timeout: 244 seconds]
Ox4A6F has quit [Ping timeout: 244 seconds]
hypokeimenon[m] has quit [Ping timeout: 244 seconds]
jakeisnt[m] has quit [Ping timeout: 244 seconds]
superherointj[m] has quit [Ping timeout: 246 seconds]
smrtak[m] has quit [Ping timeout: 244 seconds]
danielrf[m] has quit [Ping timeout: 244 seconds]
philipp[m] has quit [Ping timeout: 244 seconds]
Yakulu[m] has quit [Ping timeout: 268 seconds]
Irenes[m] has joined #spectrum
hiroshi[m] has joined #spectrum
smrtak[m] has joined #spectrum
superherointj[m] has joined #spectrum
hypokeimenon[m] has joined #spectrum
jakeisnt[m] has joined #spectrum
jpds has quit [Remote host closed the connection]
Ox4A6F has joined #spectrum
ncm[m] has joined #spectrum
jpds has joined #spectrum
enick_676 has joined #spectrum
alj[m] has joined #spectrum
sab7iryudpgf6[m] has joined #spectrum
colemickens has joined #spectrum
jpo has quit [Ping timeout: 256 seconds]
thefloweringash has joined #spectrum
Yakulu[m] has joined #spectrum
philipp[m] has joined #spectrum
danielrf[m] has joined #spectrum
multi has quit [Quit: meep..?]
multi has joined #spectrum
jpo has joined #spectrum
hooway_ has joined #spectrum
hooway has quit [Read error: Connection reset by peer]
tilpner has quit [Quit: tilpner]
tilpner has joined #spectrum
hooway_ has quit [Quit: Gone fishing.]
hooway has joined #spectrum
pinkieval has quit [Ping timeout: 246 seconds]
<pie_>
jpo: any recommended literature for data diodes? is asymmetric crypto + shuttling a usb drive back and forth a reasonable solution? are there better solutions?
<pie_>
two problems come to mind off the top of my head: 1) "usb drive firmware backdoors " or something 2) writing unauthorized stuff back into empty space (though the latter might be ok as long as you can make sure that the entire drive is encrypted and only the target machine can decrypt it?)
<MichaelRaskin>
pie_: what is the relative trust level of the systems?
<MichaelRaskin>
I.e., is reader system corrupting an FS to mount an attack on the FS implementation on the writer system a problem you care about?
<pie_>
i probably dont understand but that should be irrelevant because any time it touches the writer it should see a completely "empty"/scrambled disk
<pie_>
?
<pie_>
the reader system should be able to run 0days safely
<MichaelRaskin>
How this should is enforced
<pie_>
MichaelRaskin: if you mean the disc scrambling, asymmetric crypto?
<zgrep>
Clearly you should print out your asymmetrically encrypted data as QR codes, and then scan it with a webcam.
<pie_>
the writer system should not have a reader key
<pie_>
zgrep: :P
<ehmry>
just burn the writer afterwards, for some degree of "burn"
<pie_>
??? xd
<MichaelRaskin>
What if reader maliciously replaces the scrambled stuff with an almost valid but dangerous to handle corrupted filesystem
<pie_>
MichaelRaskin: yeah i dont get it. the writer shouldnt be able to see anything intelligible?
<pie_>
or hm do you mean if it puts something intelligible on there with raw access and the writer tries to understand it
<MichaelRaskin>
Yes
<pie_>
i guess an intermediate umb crubber might be necessary, or "just" turn off automatic partition reading for a port or something?
<pie_>
*an intermediate scrubber might be necessary
<ehmry>
I think it would be safest to avoid a filesystem and some sort of archive format
<ehmry>
*use an archive format
<MichaelRaskin>
Well, the question is what level of broken one even considers
<pie_>
ehmry: i think youre making the same misunderstanding i had in the beginning. it shouldnt matter if there is an inner filesystem because the reader should be able to do whatever and be fine
<pie_>
ehmry: the problem is if the reader writes a malicious filesystem to the raw disk
<pie_>
by inner filesystem i mean something scrambled with asymmetric crypto so the writer cant read it
<zgrep>
It seems the problem is that a USB drive has too much computer in it to be simply a data-carrying device.
<MichaelRaskin>
Print/scan is actually asymmetric enough to have a chance at being a diod
<MichaelRaskin>
I am not sure you want QR and not DMTX, though
<pie_>
MichaelRaskin: yeah but muh bandwidth :/
<zgrep>
How do rewritable CDs work? Would it be possible to write to a rewritable CD without having to read it?
<zgrep>
Or a tape drive of some kind.
<pie_>
zgrep: i thought of CDs but at the point that its writable that kind of defeats the point no?
<pie_>
also it doesnt matter, if it can store data it can have a filesystem written to it
<pie_>
unless it can be put in some read only mode thats actually enforceable
<MichaelRaskin>
pie_: hmmmm, I wonder if you could run UDP over Ethernet with a couple of wires broken
<pie_>
MichaelRaskin: that sounds too easy
<pie_>
and i imagine network hardware has too much negotiation stuff to make it properly unidirectional
<MichaelRaskin>
Might need an old enough network card, yeah
<MichaelRaskin>
Because at some point it was really it, there is a TX pair and RC pair and well
<zgrep>
pie_: My assumptions are: reader trusts writer's data, reader and writer are safe from external manipulation, and they can both publish a public key somewhere. In that case, asymmetric encryption with writer's private key + reader's public key takes care of making sure that the data is safe to handle, and the problem becomes finding a one-way data transmission mechanism.
<MichaelRaskin>
So you needed separate cross-wired cables for computer-to-computer
<zgrep>
Wikipedia says that a fiber-optic cable with only transmit at one end and only receive at the other works quite nicely. :P
<pie_>
zgrep: that sounds reasonable. though technically its sufficient for the reader to have the privkey and the writer the pubkey. and yeah i guess the one way data transmission mechanism is really the problem here, because if you can do that you dont have to worry about the whole filesystem mess
<pie_>
oh
<pie_>
mm i need more money :P
<pie_>
are you suuuure it cant renegotiate the other direction? :P
<pie_>
like is that an actual physical limitation
<pie_>
ofc i didnt think to check wikipedia
<zgrep>
pie_: It's sufficient only if nobody else can see the public key.
<zgrep>
In which case symmetric encryption is also perfectly valid.
<MichaelRaskin>
I would assume that if the other side does not havelight emitter, negotiations are going to be a bit one-sided
<pie_>
zgrep: ok i guess im conflating the asymmetric crypto for data and link layer. if the link layer is already unidirectional you dont even need the crypto
<pie_>
adding crypto at that point just protects data in transit
<pie_>
/ at rest
<zgrep>
Ah. If you also trust the transit, then yes.
<pie_>
MichaelRaskin: haha
<zgrep>
But this does mean you completely trust the writer to not give you anything evil.
<pie_>
i dont follow? why is getting evil from the writer a problem here
<zgrep>
That depends on the use-case. :P
<pie_>
my use case is piping malicious stuff from the internet to a safe network and not letting stuff back out
<zgrep>
Hmm. I guess I was just concerned that it doesn't actually do anything to keep the safe network... safe. It does, however, prevent any data from leaking back out.
<zgrep>
It's up to the reader to not blindly trust the data, if the data came from the internet. :P
<zgrep>
I don't think there's a way around that, though.
<pie_>
im saying it shouldnt matter if it cant get any data back out? - well assuming you dont need to get some sort of trusted output from it
<pie_>
which im assuming, that the reader should be completely untrusted and free to do whatever it can