phc-discussions - Re: [PHC] Is somebody working on a ANSI-C (or non C++11) implementation of Argon2 / Considerations with respect to memory allocation and fragmentation.

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] [day] [month] [year] [list]

Message-ID: <CALW8-7KAWHazc2DRHSdCLNrSRsVbaVV6uVDY37hhnuV1pYMpSw@mail.gmail.com>
Date: Mon, 7 Sep 2015 19:15:18 +0200
From: Dmitry Khovratovich <khovratovich@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Is somebody working on a ANSI-C (or non C++11)
 implementation of Argon2 / Considerations with respect to memory allocation
 and fragmentation.

We are not working on the pure C implementation yet, but we plan to in the
near future. Other participants are welcome to contribute, of course.

Regarding the memory partitioning, in order to work with such structure the
reference implementation must be changed in a few places where actual
memory offsets are computed (currently it is 4-5 lines of code). Such a
patch is easy to write.

On Mon, Sep 7, 2015 at 3:32 PM, <bjoern.haase@...ducta.endress.com> wrote:

> Hello,
>
> we are considering to use the PHC winner argon2 in our application. I have
> seen some remarks on the list and the argon2 homepage concerning a plain
> ANSI C port. In our setting using of such a port might be preferential.
> Namely, the current implementation of ARGON2 seems to rely not only on C++
> but C++11 which might make the code even less portable than conventional
> C++.
>
> Could you give me the information wether somebody is actually working on a
> C port? Since our company has decided to separate crypto stuff from our
> main applications and we decided to provide the crypto implementations
> under CC0 as open source, we might be joining efforts.
>
> Also if I see correctly, the large memory array used by argon2 for hashing
> will currently be allocated in one single chunk which might turn out to be
> difficult in systems where malloc has to deal with a lot of memory
> fragmentation. I'd like to raise the question whether it would be helpful
> to have a setting where the memory chunks are allocated not in one huge
> contigeous area but rather smaller entities of, say 1 Mbytes each. I.e. one
> would have the blocks of 1 kByte size, "chunks" of say 1 Mbyte and the
> whole state of say 256 MByte?
>
> Best regards | Mit freundlichen Grüßen
>
> Björn Haase
>
> ____________________________________________________________________________
> E+H Conducta GmbH + Co. KG | Dieselstr. 24 | 70839 Gerlingen | Germany
>
>
>
> _________________________________________________________________________
>
> Endress+Hauser Conducta GmbH+Co.KG
> Amtsgericht Stuttgart HRA 201908
> Sitz der Gesellschaft: Gerlingen
> Persönlich haftende Gesellschafterin:
> Endress+Hauser Conducta
> Verwaltungsgesellschaft mbH
> Sitz der Gesellschaft: Gerlingen
> Amtsgericht Stuttgart HRA 201929
> Geschäftsführer: Dr. Manfred Jagiella
> __________________________________________________________________________
>
> Disclaimer:
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you receive
> this in error, please contact the sender and delete the material from any
> computer.
>
> __________________________________________________________________________
>
> http://www.conducta.endress.com/
>



-- 
Best regards,
Dmitry Khovratovich

Content of type "text/html" skipped