<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tis 2 apr. 2024 23:15McDair via cryptography <<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>> skrev:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Allow me to provide the broader context:<br>
<br>
> > In code, I found 'Encrypt' and 'Decrypt' clearer counterparts than<br>
> > 'Hash' and 'FindPreImage' or something like that. Especially for<br>
> > subroutines.<br>
> > Also 'Encryption' is a general term wrt cryptography/cryptology.<br>
<br>
<br>
<br>
The reasons why I used this terminology was mainly from a code development point of view, however enthusiastically conveyed outside of this scope.<br>
<br>
It is fair to say it might be confusing within the scope of a cryptographic hash function, although applicable in a broader sense.<br>
<br>
<br>
To clarify:<br>
<br>
As mentioned before, encryption in its most general meaning is about protecting secrets. In this context it is not function-type specific.<br>
<br>
<br>
Here is an example:<br>
<br>
Let's say you manage a web application's login credentials, and want to make sure your users' actual passwords will not be exposed in case your server/database gets compromised.<br>
<br>
You will be thinking of ways to *encrypt* this data, render it unreadable for an attacker. At this point it is function agnostic.<br>
<br>
It is perfectly fine to ultimately choose to use a cryptographic hash function to this end.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This type of thinking lead to the Adobe password sudoku</div><div dir="auto"><br></div><div dir="auto"><a href="https://www.csoonline.com/article/540070/network-security-adobe-confirms-stolen-passwords-were-encrypted-not-hashed.html">https://www.csoonline.com/article/540070/network-security-adobe-confirms-stolen-passwords-were-encrypted-not-hashed.html</a></div><div dir="auto"><br></div><div dir="auto"><a href="https://arstechnica.com/information-technology/2013/11/how-an-epic-blunder-by-adobe-could-strengthen-hand-of-password-crackers/">https://arstechnica.com/information-technology/2013/11/how-an-epic-blunder-by-adobe-could-strengthen-hand-of-password-crackers/</a></div><div dir="auto"><br></div><div dir="auto">Using encryption is simply *not acceptable* for passwords due to frequent password reuse in the real world, because encryption implies a key can decrypt it and it can lead the authentication system designer down the entirely wrong path. </div><div dir="auto"><br></div><div dir="auto">Usually deterministic symmetric encryption is fine in many usecases (most disk encryption like Bitlocker, and other stuff that doesn't involve network protocols), but it's extremely unacceptable for passwords, and it's made worse by using ECB mode with a short block cipher function and thus making *fractions* of passwords recognizable when they are reused. </div><div dir="auto"><br></div><div dir="auto">The infosec community learned this in the 90's, encryption for passwords has been deprecated for multiple decades. </div><div dir="auto"><br></div><div dir="auto">We use "cryptography" as the general term, we do *not* use "encryption" as a general term. </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>