Thread: Problem handling file piped into STDIN

Hello guys,


I have to read a 16 byte file header that will be piped into my program.
Normally, I just read the header, process it and continue reading the rest of the file later on.


Problem is when the file I’m receiving is encrypted. In that case, I have to decrypt the header first, and then the rest of the file. Separating the information like this results in the incorrect decryption of the rest of the file though, as the previous bytes affect the decryption of the subsequent bytes.


I could modify my decryption code to try to account for this data split, but it would be messy and require a lot of work. A simpler solution -which is what I do with regular, encrypted files, not piped from the stdin- is to read and decrypt the header, and then reset the file offset to the start of the file and later read everything again.


I can’t do this with the stdin though. lseek returns -1 and errno is set to “Illegal Seek”. I can’t open and close the file either as I don’t have a file name for stdin, only a file descriptor. Playing around with the dup() functions has been unsuccessful as well, as the cloned descriptor shares its file offset with the original; meaning reading from it moves the offset in stdin and using lseek has the same result.


So my question, is there an established “proper” way to reset the file offset to the beginning of the stdin? If not, is there a “hack” to accomplish the same (needs to work in Linux and OSX).


Thank you.

Yes, you’re correct in your assumption. I’m reading the header to obtain the salt and calculate the ivector. And yes, I could copy the header, but I was trying not to. This code is already tested, debugged and cleaned, and I’m already at my function and line limit for this source file; so I was hoping to re-use the system I already have in place, with just the minor adjustment of moving the file offset.



Yet from your answer I gather this isn’t as simple as I thought.


Normally the header is never encrypted, so I wrote my whole code with this assumption. I wasn’t accounting for a doubly encrypted file -normal encryption with base64 on top, which doesn’t care about the header.
If can’t go the quick and dirty route I might as well delve deeper into my base64 decoder, which is what’s causing the problem. B64 needs a minimum of three bytes -if we want to avoid padding- so by reading 21 bytes -16 byte header gets expanded to 21 in base64- I should be able to split the workload without issues; but something is wrong there.


Oh well, thanks anyway. I might heed your advice if I get tired of hitting my head against the table; shuffling some code around will go a lot faster than hunting down an obscure “bug”.


Cheers.