search for: sha3

...s 10 is giving the error below. Can anyone advise a compiler option or code change to resolve this please. Thanks. Roderick Johnstone # make make all-recursive Making all in . /bin/bash ./update-version.sh . . Making all in src Making all in lib-test Making all in lib make all-am source='sha3.c' object='sha3.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ /bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I/export/home/exim_build_20190605/build_local/include -m64 -c -o sha3.lo sha3.c libtool: compile: cc -DHAVE_CONF...

...= 1, output = 0x839d8, olen = 20}, {method = 0x839d0 "sha1", input = 0x83908, ilen = 3, rounds = 1, output = 0x839f0, olen = 20}, {method = 0x839d0 "sha1", input = 0x83a08, ilen = 56, rounds = 1, output = 0x83a48, olen = 20}, {method = 0x83a60 "sha3-256", input = 0x838e8, ilen = 0, rounds = 1, output = 0x83a70, olen = 32}, {method = 0x83a60 "sha3-256", input = 0x83a98, ilen = 135, rounds = 1, output = 0x83b20, olen = 32}, {method = 0x83a60 "sha3-256", input = 0x83b48, ilen = 200, rounds = 1...

...1:35 AM, Chandler Carruth wrote: >> >>> Interestingly newer, supposedly "more secure" digest algorithms are also >>> very often significantly faster. I don't think we want any of the ones >>> mentioned here, I think we want one of the candidates is the SHA3 >>> competition which had truly stellar software implementation throughput. I'm >>> hoping to add support for such a digest algorithm to LLVM soon, as there >>> are many folks who want to consume this information: modules, merge >>> function pass, debug info,...

...t; On May 8, 2013, at 10:50 AM, Chandler Carruth <chandlerc at google.com> > wrote: > > >> >>> What are the SHA-3 variants that you think would suite these needs ? >> >> > I want to look at the implementation complexity. The winner (and the > official SHA3 algorithm), BMW and Skein are all worth looking at. > > > If your primary criterion is through-put on large, desktop-class CPUs, > Skein is likely to be the winner. Keccak (the official SHA3) is also > pretty fast on CPUs (and significantly better in hardware implementations, > n...

On 10/06/2019 14:40, Roderick Johnstone via dovecot wrote: > Compiling dovecot 2.2.36.1 with the native compiler on Solaris 10 is > giving the error below. ... > -m64 -c -o sha3.lo sha3.c > libtool: compile:? cc -DHAVE_CONFIG_H -I. -I../.. > -I/export/home/exim_build_20190605/build_local/include -m64 -c sha3.c > -KPIC -DPIC -o .libs/sha3.o > "sha3.h", line 49: warning: unnamed struct member ... Untested: try naming the union. My own builds (dovecot...

...Check out my Internet Draft: >> >> >> draft-moskowitz-small-crypto-00.txt > > Thanks for the tip, will have a look for into it. Keccak is a general hashing function.? It was the first? of the hashing 'sponge' functions, that many have followed.? It is the basis of SHA3 (at Keccak's greatest strength). Argon2 seems to be special-built for password hashing.? Thing is it is not supported on my CentOS7 system: # doveadm pw -l MD5 MD5-CRYPT SHA SHA1 SHA256 SHA512 SMD5 SSHA SSHA256 SSHA512 PLAIN CLEAR CLEARTEXT PLAIN-TRUNC CRAM-MD5 SCRAM-SHA-1 HMAC-MD5 DIGEST-...

On May 8, 2013, at 10:50 AM, Chandler Carruth <chandlerc at google.com> wrote: > > What are the SHA-3 variants that you think would suite these needs ? > > I want to look at the implementation complexity. The winner (and the official SHA3 algorithm), BMW and Skein are all worth looking at. If your primary criterion is through-put on large, desktop-class CPUs, Skein is likely to be the winner. Keccak (the official SHA3) is also pretty fast on CPUs (and significantly better in hardware implementations, not that it matters here), and...

...gt;>> >>>> draft-moskowitz-small-crypto-00.txt >>> Thanks for the tip, will have a look for into it. >> Keccak is a general hashing function.? It was the first? of the >> hashing 'sponge' functions, that many have followed.? It is the basis >> of SHA3 (at Keccak's greatest strength). >> >> Argon2 seems to be special-built for password hashing.? Thing is it is >> not supported on my CentOS7 system: >> >> # doveadm pw -l >> MD5 MD5-CRYPT SHA SHA1 SHA256 SHA512 SMD5 SSHA SSHA256 SSHA512 PLAIN >> CLEAR C...

...srp storeutl ts verify version x509 Message Digest commands (see the `dgst' command for more details) blake2b512 blake2s256 gost md4 md5 rmd160 sha1 sha224 sha256 sha3-224 sha3-256 sha3-384 sha3-512 sha384 sha512 sha512-224 sha512-256 shake128 shake256 sm3 Cipher commands (see the `enc' command for more details) aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb aes-256-...

On 5/8/2013 11:35 AM, Chandler Carruth wrote: > Interestingly newer, supposedly "more secure" digest algorithms are > also very often significantly faster. I don't think we want any of the > ones mentioned here, I think we want one of the candidates is the SHA3 > competition which had truly stellar software implementation > throughput. I'm hoping to add support for such a digest algorithm to > LLVM soon, as there are many folks who want to consume this > information: modules, merge function pass, debug info, and the linker. Nice, Is i...

...ariables: %{<hash algorithm>;rounds=<n>,truncate=<bits>,salt=s>:field} Hash algorithm is any of the supported ones, e.g. md5, sha1, sha256. Also "pkcs5" is supported using SHA256. For example: %{sha256:user} or %{md5;truncate=32:user}. + Added support for SHA3-256 and SHA3-512 hashes. + config: Support DNS wildcards in local_name, e.g. local_name *.example.com { .. } matches anything.example.com, but not multiple.anything.example.com. + config: Support multiple names in local_name, e.g. local_name "1.example.com 2.example.com" { .. }...

...ariables: %{<hash algorithm>;rounds=<n>,truncate=<bits>,salt=s>:field} Hash algorithm is any of the supported ones, e.g. md5, sha1, sha256. Also "pkcs5" is supported using SHA256. For example: %{sha256:user} or %{md5;truncate=32:user}. + Added support for SHA3-256 and SHA3-512 hashes. + config: Support DNS wildcards in local_name, e.g. local_name *.example.com { .. } matches anything.example.com, but not multiple.anything.example.com. + config: Support multiple names in local_name, e.g. local_name "1.example.com 2.example.com" { .. }...

...t; On 5/8/2013 11:35 AM, Chandler Carruth wrote: > >> Interestingly newer, supposedly "more secure" digest algorithms are also >> very often significantly faster. I don't think we want any of the ones >> mentioned here, I think we want one of the candidates is the SHA3 >> competition which had truly stellar software implementation throughput. I'm >> hoping to add support for such a digest algorithm to LLVM soon, as there >> are many folks who want to consume this information: modules, merge >> function pass, debug info, and the linker....

...gt;>> >>>> draft-moskowitz-small-crypto-00.txt >>> Thanks for the tip, will have a look for into it. >> Keccak is a general hashing function.? It was the first? of the >> hashing 'sponge' functions, that many have followed.? It is the basis >> of SHA3 (at Keccak's greatest strength). >> >> Argon2 seems to be special-built for password hashing.? Thing is it is >> not supported on my CentOS7 system: >> >> # doveadm pw -l >> MD5 MD5-CRYPT SHA SHA1 SHA256 SHA512 SMD5 SSHA SSHA256 SSHA512 PLAIN >> CLEAR C...

...lved by the LLVM backend. This means that Clang does not know exactly what will be enabled. It needs to know this to output the correct pre processor feature test macros. Consider this AArch64 march: -march=armv8.4-a+crypto+nosha2 The base arch is armv8.4-a, the crypto extension turns on AES/SHA2/SHA3/SM4. The nosha2 disables SHA2/SHA3 (since SHA3 is dependant on SHA2). Each of these features has an ACLE feature test macro, so Clang needs to know that nosha2 also disables SHA3. New Errors and Warnings ======================= Whether these are errors or warnings by default is up for debate. Thi...

...tl > ts                verify            version           x509 > > Message Digest commands (see the `dgst' command for more details) > blake2b512        blake2s256        gost              md4 > md5               rmd160            sha1              sha224 > sha256            sha3-224          sha3-256          sha3-384 > sha3-512          sha384            sha512            sha512-224 > sha512-256        shake128          shake256          sm3 > > Cipher commands (see the `enc' command for more details) > aes-128-cbc       aes-128-ecb       aes-192-cbc  ...

On 2/12/19 6:03 PM, Matthias Fechner via dovecot wrote: > Am 12.02.2019 um 17:05 schrieb Robert Moskowitz via dovecot: >> I have trying to find how to set the dovecot-sql.conf for using >> SHA256/512.? I am going to start clean with the stronger format, not >> migrate from the old MD5.? It seems all I need is: > you maybe would like to have a look to the hashing algo

...g --target=arm-arm-none-eabi -mcpu=cortex-a8 -mfpu=vfp4 -mfpu=auto -c /tmp/test.c clang-8: error: the clang compiler does not support '-mfpu=auto' Maybe I'm missing something. ACLE macros (Renato) =========== >> The base arch is armv8.4-a, the crypto extension turns on AES/SHA2/SHA3/SM4. The nosha2 disables SHA2/>SHA3 (since SHA3 is dependant on SHA2). Each of these features has an ACLE feature test macro, so Clang >needs to know that nosha2 also disables SHA3. >Is this complex logic done by GCC's front-end as well? I don't think so, you might be right there...

...ft-moskowitz-small-crypto-00.txt >>>>> Thanks for the tip, will have a look for into it. >>>> Keccak is a general hashing function.? It was the first? of the >>>> hashing 'sponge' functions, that many have followed.? It is the basis >>>> of SHA3 (at Keccak's greatest strength). >>>> >>>> Argon2 seems to be special-built for password hashing.? Thing is it is >>>> not supported on my CentOS7 system: >>>> >>>> # doveadm pw -l >>>> MD5 MD5-CRYPT SHA SHA1 SHA256 SHA512...

...has such a > limited window in which to generate one and limited degrees of freedom > to manipulate the colliding data. (Did you mean SHA-512 here?) Again, this can happen with the P-curves/SHA-256/384/512/ECDSA that is already supported. While we're daydreaming about this, what about SHA3-512? (note the "3") > Personally, I'm more interested in a post-quantum KEX than another of the > same species... I'm very interested in this too. They're not exclusive to each other, however. I haven't stayed on top of post-quantum crypto lately, but isn't...