A public key signature may be even safer. See e.g. our stand-alone (no dll required) version using ECC https://synopse.info/files/html/Synopse%20mORMot%20Framework%20SAD%201.18.html#TITL_187 Anyone may replace an executable and compute the SHA-1 (or SHA-256/512). But only the one knowing your secret key would be able to sign an executable, and let the executable verify it with the associated public key. And ECSDA validation will take place against the SHA-256 hash of the executable.
Please don't compare a file download to a complex cvs. I would argue that in your example good collision resistance is necessary - and there we have a problem with SHA1. Collision attacks on SHA1 were demonstrated already. And those will perform much better in the next years. So if you implementing an update mechanism today, you wont use file verification or transmission protocols of the last decade. Because it's one thing to update a broken software over a secure update mechanism. It's a whole lot harder to securely update the insecure update mechanism itself!
Ludwig Behm The example in the post was intended to be basic - and I do mention why I do not stick to file size, CRC or MD5 just to check basic validity of what I expect in the stream. It is also intended to be an in-house example - if you get the attacks you mention inside your walls then you have a totally different problem. SHA1 is still fast and short - and better that file size comparison. In the example I also just use the database client - probably not the best transport out in the wild. System.Hash does contain SHA2 and others - so very trivial to change - or add more complex algorithms. It all depends on the needs and not over-engineering/complicating - I will probably also in 2020 still use 0s and 1s, asm - and maybe a ROT13 cipher :D
I fear such blog postings will give many developers a false feeling of best practices. And no you explicitly wrote that you still can use CRC/MD5 if you use software from the last century. Just imagine the usual developer wants an updater, googles 'delphi secure updater' and follows your example, because you wrote that you could implement stuff like this!
Ludwig Behm I do still have faith that people do some thinking on their own - even in these political times. But you got a point that someone could confuse the use of the term SHA1 with "secure updater" - whereas my post is only about easy validating the stream - would we have had this conversation if I had just compared file sizes? And I guess even if we all use software from the last century as soon as we turn on our Windows machines - I do pledge that people keep their tools updated. I will add a disclaimer in the post - to cover your concerns - thanks.
Attila Kovacs Good unit name :) I hope it is clear that these are basic steps, improvement is suggested and I do mention I have done this for many years using a "launcher" aka outside as you suggest. Also in the post I do warn about the rename/delete - but I do hope people are able to improve on the basics.
why do we still use sha1 in 2017?
ReplyDeleteLudwig Behm Why not? en.wikipedia.org - SHA-1 - Wikipedia
ReplyDeleteA public key signature may be even safer. See e.g. our stand-alone (no dll required) version using ECC https://synopse.info/files/html/Synopse%20mORMot%20Framework%20SAD%201.18.html#TITL_187 Anyone may replace an executable and compute the SHA-1 (or SHA-256/512). But only the one knowing your secret key would be able to sign an executable, and let the executable verify it with the associated public key. And ECSDA validation will take place against the SHA-256 hash of the executable.
ReplyDeletePlease don't compare a file download to a complex cvs.
ReplyDeleteI would argue that in your example good collision resistance is necessary - and there we have a problem with SHA1. Collision attacks on SHA1 were demonstrated already. And those will perform much better in the next years.
So if you implementing an update mechanism today, you wont use file verification or transmission protocols of the last decade. Because it's one thing to update a broken software over a secure update mechanism. It's a whole lot harder to securely update the insecure update mechanism itself!
Ludwig Behm The example in the post was intended to be basic - and I do mention why I do not stick to file size, CRC or MD5 just to check basic validity of what I expect in the stream. It is also intended to be an in-house example - if you get the attacks you mention inside your walls then you have a totally different problem. SHA1 is still fast and short - and better that file size comparison. In the example I also just use the database client - probably not the best transport out in the wild. System.Hash does contain SHA2 and others - so very trivial to change - or add more complex algorithms. It all depends on the needs and not over-engineering/complicating - I will probably also in 2020 still use 0s and 1s, asm - and maybe a ROT13 cipher :D
ReplyDeleteI fear such blog postings will give many developers a false feeling of best practices.
ReplyDeleteAnd no you explicitly wrote that you still can use CRC/MD5 if you use software from the last century.
Just imagine the usual developer wants an updater, googles 'delphi secure updater' and follows your example, because you wrote that you could implement stuff like this!
Ludwig Behm I do still have faith that people do some thinking on their own - even in these political times. But you got a point that someone could confuse the use of the term SHA1 with "secure updater" - whereas my post is only about easy validating the stream - would we have had this conversation if I had just compared file sizes? And I guess even if we all use software from the last century as soon as we turn on our Windows machines - I do pledge that people keep their tools updated. I will add a disclaimer in the post - to cover your concerns - thanks.
ReplyDeleteThe article discusses a simple data integrity check and for that purpose SHA1 is perfectly fine.
ReplyDeleteOndrej Kelle thanks, that was the intention. :)
ReplyDeleteAttila Kovacs Good unit name :) I hope it is clear that these are basic steps, improvement is suggested and I do mention I have done this for many years using a "launcher" aka outside as you suggest. Also in the post I do warn about the rename/delete - but I do hope people are able to improve on the basics.
ReplyDelete