phc-discussions - uint8_t vs. unsigned char for aliasing (was: hash encryption)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160324113059.GB8705@openwall.com>
Date: Thu, 24 Mar 2016 14:30:59 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: uint8_t vs. unsigned char for aliasing (was: hash encryption)

On Wed, Mar 23, 2016 at 09:18:41AM -0700, Andy Lutomirski wrote:
> Off-topic, but I recently learned the distressing fact that uint8_t is
> not specified as a "character" type and is therefore not special wrt
> aliasing :(

Yes, I recently learned this too, from Alexander Cherepanov:

https://twitter.com/ch3root/status/708748830540484608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110#c13

The current understanding appears to be that uint8_t is being treated as
special wrt aliasing in practice so far, but this isn't guaranteed by C
standards and thus might change in some compiler.

I still have plenty of uint8_t in yescrypt inherited from scrypt, and
this is why I use uint8_t in this code for now.  I'll consider changing
them all to "unsigned char" as a separate change for the entire tree.

Unfortunately, doing so will change the crypto_scrypt() prototype
compared to the scrypt tree... or maybe I should keep uint8_t just in
that one wrapper function, with casts to (unsigned char *) in calls to
deeper layer functions.

Alexander