crypto visibility

crypto visibility

[Daniel Cegiełka]

[-- Attachment #1: Type: text/plain, Size: 314 bytes --]

Hi,
Can we make these functions visible? They are very useful.

src/crypt/crypt_md5.c:
void md5_init()
void md5_sum()
void md5_update()

src/crypt/crypt_sha256.c:
void sha256_init()
void sha256_sum()
void sha256_update()

src/crypt/crypt_sha512.c:
void sha512_init()
void sha512_sum()
void sha512_update()

Daniel

[-- Attachment #2: Type: text/html, Size: 573 bytes --]

Re: crypto visibility

[Szabolcs Nagy]

* Daniel Cegie??ka <daniel.cegielka@gmail.com> [2015-01-14 09:51:37 +0100]:
> Can we make these functions visible? They are very useful.
> 

it makes sense if you can convince other libc vendors
to provide them with the same api (otherwise it would
cause portability problems)

note that the current implementation in musl is optimized
for size and maintainability (the performance does not really
matter for crypt unless it is used for bruteforcing passwds
but an attacker would use a custom implementation anyway)
performance may matter more for other applications

> src/crypt/crypt_md5.c:
> void md5_init()
> void md5_sum()
> void md5_update()
> 
> src/crypt/crypt_sha256.c:
> void sha256_init()
> void sha256_sum()
> void sha256_update()
> 
> src/crypt/crypt_sha512.c:
> void sha512_init()
> void sha512_sum()
> void sha512_update()
> 
> Daniel

Re: crypto visibility

[Rich Felker]

On Wed, Jan 14, 2015 at 09:51:37AM +0100, Daniel Cegiełka wrote:
> Hi,
> Can we make these functions visible? They are very useful.
> 
> src/crypt/crypt_md5.c:
> void md5_init()
> void md5_sum()
> void md5_update()
> 
> src/crypt/crypt_sha256.c:
> void sha256_init()
> void sha256_sum()
> void sha256_update()
> 
> src/crypt/crypt_sha512.c:
> void sha512_init()
> void sha512_sum()
> void sha512_update()

In short, no, at least not without a lot of other things happening. To
do so would be to recreating one of the big things musl was designed
to get away from: random nonstandard interfaces with no documented
interface contract and behavior determined by whatever the existing
implementation(s) happened to do. Note that making these interfaces
public would also involve making the size and possibly representation
of the state structure a public API/ABI too.

If the code is good and you want to use it, the best way is copy and
paste. That way you avoid depending on any assumptions about an
interface contract because the code is all under your control. If you
think there would be interest in standardizing these functions, you
can pursue that with other implementations. It should involve properly
documenting the behavior including corner cases and reaching an
agreement.

Alternatively copies could just be put in a non-libc library like
libhash or something; this probably makes a lot of sense, as there's
nothing system-specific about how they're implemented.

Rich

Re: crypto visibility

[Daniel Cegiełka]

2015-01-14 23:22 GMT+01:00 Rich Felker <dalias@libc.org>:
> On Wed, Jan 14, 2015 at 09:51:37AM +0100, Daniel Cegiełka wrote:
>> Hi,
>> Can we make these functions visible? They are very useful.
>>

>
> In short, no, at least not without a lot of other things happening. To
> do so would be to recreating one of the big things musl was designed
> to get away from: random nonstandard interfaces with no documented
> interface contract and behavior determined by whatever the existing
> implementation(s) happened to do. Note that making these interfaces
> public would also involve making the size and possibly representation
> of the state structure a public API/ABI too.

ok, I understand the reasons. Func's crypto API is totally different
per implementation and it is terrible, eg three times is added
SHA512's code to OpenSSH: crypt(), libc SHA512 and.. from
libressl/openssl.

btw. I have had some success in porting ssh code from OpenBSD CVS repo
to musl... but _without_ openssl :)

# file scp/scp sftp/sftp sftp-server/sftp-server ssh/ssh ssh-agent/ssh-agent s>
scp/scp:                 ELF 64-bit LSB executable, x86-64, version 1,
statically linked, stripped
sftp/sftp:               ELF 64-bit LSB executable, x86-64, version 1,
statically linked, stripped
sftp-server/sftp-server: ELF 64-bit LSB executable, x86-64, version 1,
statically linked, stripped
ssh/ssh:                 ELF 64-bit LSB executable, x86-64, version 1,
statically linked, stripped
ssh-agent/ssh-agent:     ELF 64-bit LSB executable, x86-64, version 1,
statically linked, stripped
ssh-keyscan/ssh-keyscan: ELF 64-bit LSB executable, x86-64, version 1,
statically linked, stripped

# ls -lh scp/scp sftp/sftp sftp-server/sftp-server ssh/ssh ssh-agent/ssh-agent>
-rwxr-xr-x    1 root     root        89.8k Jan 14 19:07 scp/scp
-rwxr-xr-x    1 root     root       131.2k Jan 14 19:07 sftp-server/sftp-server
-rwxr-xr-x    1 root     root       146.7k Jan 14 19:07 sftp/sftp
-rwxr-xr-x    1 root     root       336.9k Jan 14 19:07 ssh-agent/ssh-agent
-rwxr-xr-x    1 root     root       482.1k Jan 14 19:07 ssh-keyscan/ssh-keyscan
-rwxr-xr-x    1 root     root       616.8k Jan 14 19:07 ssh/ssh

tiring work... I think it is better to write ssh client for tinyssh
from scratch.

Daniel

> Rich