last day (15 days later) » 

16:52
-1
A: Client side signing of a file(.exe,.dll,.jar..) using CA issued certificate and signtool

Jonathan GrayI like Stephane's answer but I'm not satisfied with the fact that it's not exactly feasible in practice without writing your own code. So I have a couple of possible alternatives to suggest: 1) Find a completely open source signing tool and modify it to accept a hash as input as opposed to calcu...

No. Please, don't suggest to people they start tinkering with crypto code, especially for a one-off project. It's the road to unmaintained, unmaintainable and vulnerable operation. I'm not saying it can't be done (in fact, I've checked my own code signing tools to see if I could modify them in such a way) but for production work, just don't.
@Stephane It doesn't seem to me like this would only be used for a one-off project, and I'm not suggesting that people start tinkering with their own crypto code. The risks associated with doing these tasks are artificial anyways, since there really is no way to get it wrong. Basically because of the rigorous testing on the certificate done by Windows itself, if you can get one of these methods to work at all, it should be working properly. It's not even like I'm suggesting for someone to generate their own certificate. This would use an existing cert with existing crypto implementations.
You can mess that up in a large number of way: since you're not checking the code, just the hash, you need to have a high confidence on where that hash comes from (that's just an example).
@Stephane That example is invalid; It is outside of the context of the question.
Not unless that is a one-off project (in which case you can't make assumption of how it'll be used).
16:52
@Stephane The question was whether the hash could be sent to the server as opposed to the file itself. We have to assume that anything related to the security of the hash is outside of the scope of the question.
No, we can't. That's what I^'ve been telling you all along: writing the code is simple. Building and maintaining a secure product around that change isn't. What makes it hard isn't the hash-signing code, it's the way it's transfered (securely) wbetween two system, it's the side effect such a change will have on the code signing code base, it's the fact that all of that has to be taken into account
If you want an analogy, here is one: it's like changing a screw on a satellite. Changing the screw is simple. Doing so in a space suit in micro-gravity is much harder and getting someone in position to do that requires millions of dollars and thousand of workers.
If it's for a single deployment instance, it doesn't make economic sense to do it right. In fact, the only way to do it at all is cutting so many corners and ignoring so many future issues than no same project manager would approve it
if it's for multiple instances (i.e. a project), then things are different: it can be done, it can be done securely (if you have the right people and enough resources) and it would actually make sense (since that is a problem that a LOT of people are confronted with)
But it's not a project that should be debated here: this isn't the place for that and it would be too long a discussion.
I'm sorry, I'm just not convinced of any negative consequences here. I'm more convinced at this point that you're arguing simply in order to be right. In this case, I actually think that the benefits outweigh the pitfalls you're trying to point out in your arguments.
Microsoft's own signtool hasn't changed in years. Within the amount of time that it is likely to change again, I'm sure one would get more than enough accomplished with the tool to make it worth it, and statistically also worth it in terms of security pitfalls.
... Potential security pitfalls
I'm afraid that I'll have to call you up on your experience here: do you have any experience in project management ? In particular in the security area ? I'm asking because you sound like someone who doe not gasp the complexity (and costs) associated with such a project.
(sorry... it's time for me to go. I'll check your answer tomorrow)
They have an existing implementation that relies on the entire file being sent to the server. They have developers that could probably even handle the task. What does it matter what my project management skills are? I'm an independent freelancer. I have plenty of my own project management skills.
(and again, sorry for asking what your experience is. Please believe me when i say it is a honest question and I'm not attempting to "bully you" out of the conversation)
17:08
I've been developing my own projects for about 15 years, mostly in web dev (with a healthy interest in information security). I've never worked in a team but I definitely know what it's like to be a developer. Having a single machine dedicated to signing files would be absolutely amazing without having to actually transfer an entire file to the machine itself. It just seems logically like a good idea.

  last day (15 days later) »