AES: Why is it a good practice to use only the first 16 bytes of a hash for encryption? I'd like to encrypt Text with AES/CTR and a password defined by the user in java. I already checked the internet (and stackoverflow) for answers. The most used version is to hash the user password with sha1 and take only the first 16 bytes.

But I don't think this can be a good practice.


sha1 is weak 
taking only the first 16 bytes makes the hash also weak
and rise the chance for a collision (even with sha-256)


Is this really the best practice? Why? How can I do things better?

Some links to the articles I mentioned:


https://stackoverflow.com/questions/3451670/java-aes-and-using-my-own-key
https://howtodoinjava.com/security/java-aes-encryption-example/
https://blog.axxg.de/java-aes-verschluesselung-mit-beispiel/
Why is it a good practice to use only the first 16 bytes of a hash for encryption?


As you noted, it isn't. 

But, the problem is not with the "16 bytes" part of the statement, or the concern for collisions. The problem is with the "hash" part.

16 bytes

As stated in one of the links you shared, AES only uses key sizes of 128, 192, and 256 bits (or 16, 24, and 32 bytes, respectively). So the key must be one of these sizes, because AES simply does not support other key sizes.

Trying to use a larger key could have a variety of possible outcomes depending on what the implementation chooses to do. It might raise an exception, or continue silently while only using the first N bits of the supplied key.

Hashing a password to use as an encryption key

Using a hash function such as MD5, SHA1, SHA2, SHA3, blake2, etc, would all be bad practice. The first two are obvious: MD5 and SHA1 are known to be weak in general. 

But even using a strong cryptographic hash like SHA3 or blake2 would also be bad, because they were not designed to solve the problem of deriving a key from a password. Use of a cryptographic hash function is involved in this process, but it is not the entirety of it.

Good practice would be to use a dedicated key derivation function such as Argon2 that was designed to solve this problem. If your library doesn't support Argon2 but supports scrypt, bcrypt or PBKDF2, any of these three is also a reasonable choice.

Why/How

A normal hash function is designed to be fast and require little space.

A hash function designed for use on passwords is quite the opposite: it is a slow function that requires lots of memory access, in an attempt to try and optimize the function towards what a consumer CPU is good at, and minimize the potential for optimization with special hardware. Specialized hardware is usable by an attacker, but a legitimate user is limited to a commodity CPU; The goal is to try and use a function that cannot take advantage of special hardware to the extent possible.

Details about the hows and whys of password hashing are listed in this paper and quoted below (with minor modifications, e.g. removing citations and modified formatting):


  Cryptographic  Security: The  scheme  should be  cryptographically secure and  as  such possess the  following  properties:  
  
  
  1) Preimage  resistance
  2) Second preimage resistance
  3) collision resistance. 
  
  
  In addition it should avoid other cryptographic weaknesses such as those present in (some)Merkle-Damgård constructions(e.g. length extension attacks, partial message collisions, etc)
  
  Defense against lookup table /TMTOAttacks: 
  
  
  The  scheme  should aim to make TMTO attacks that allow for precomputed lookup table generation, such as Rainbow Tables, infeasible
  
  
  Defense  against CPU-optimized 'crackers':
  
  
  The  scheme  should  be ‘CPU-hard’, that is, it should require significant amounts of CPU processing in a  manner that cannot be optimized away through either software or hardware. As such, cracking-optimized  (multi-core)  CPU  software  implementations (eg. written in assembly, testing  multiple input  sets  in parallel) should offer  only  minimal  speed-up  improvements  compared  to  those  intended  for validation (“slower for attackers, faster for defenders”).
  
  
  Defense against hardware-optimized 'crackers':
  
  
  The scheme  should be 'memory-hard', that is, it should significant amounts  of  RAM  capacity  in  a manner  that  cannot  be  optimized  away  through  eg. TMTO attacks. As such cracking-optimized ASIC, FPGA and GPU implementations should offer only minimal speed up improvements (eg. in terms of time-area product) compared  to  those  intended  for  validation. As  noted  by  Aumasson one of  the  main  scheme  design  challenges  is  ensuring  minimized  efficiency  on GPUs,  FPGAs  and  ASICs  (in  order  to  minimize  benefits  of  cracking-optimized  implementations)  and  maximized  efficiency  on  general-purpose CPUs (in order to maintain regular use efficiency).
  
  
  Defense  against  side-channel  attacks:
  
  
  Depending  on  the  use-case  (eg. for key derivation or authentication to a device seeking to protect against modification  by  the  device owner)  side-channel  attacks  might  be  a  relevant  avenue  of  attack.  Password  hashing  schemes  should  aim  to  offer  side-channel resilience. With regards to password hashing  scheme  security  we  will  focus on  security  versus  the cache-timing type  of  side-channel  attacks  given the existence of such attacks against the commonly used scrypt scheme. The  second category of side-channel  attacks  we  will take  into consideration are so-called Garbage Collector Attacks (GCAs). GCAs have been discussed in  literature as an instance of a 'memory leak' attack relevant to password hashing scheme security. GCAs consist of a scenario where an attacker has access to a target machine's internal memory either after termination of the hashing scheme or at some point where the password itself is still present in memory (the so-called WeakGCA variant)...