Salsa20 C headers-only library

[GlowingOne]

Source:

hxxps://cr.yp.to/snuffle.html

usage:

#include "ecrypt-synch.h"

int main(){
ECRYPT_ctx ctx;
   unsigned char plaintext[1024] = "Test";
   unsigned char receiver[1024];
    u8 key[ECRYPT_MAXKEYSIZE / 8],  IV[ECRYPT_MAXIVSIZE/8],  ciphertext[1024], * result;
    memset(key, 0, ECRYPT_MAXKEYSIZE / 8);
    memset(key, 0, ECRYPT_MAXIVSIZE / 8);
    ECRYPT_init();
    ECRYPT_keysetup(&ctx, key, ECRYPT_MAXKEYSIZE, ECRYPT_MAXIVSIZE);
    ECRYPT_ivsetup(&ctx, IV);
    ECRYPT_encrypt_blocks(&ctx, plaintext, ciphertext, 16);
    ECRYPT_ivsetup(&ctx, IV);
    ECRYPT_decrypt_blocks(&ctx, ciphertext, receiver, 16);
    return 0;
}

Remarks:

calling "ECRYPT_encrypt_bytes" should be done when encrypting fixed-length messages. For encrypting chunks, use the ECRYPT_encrypt_blocks macro, like in the example, because ECRYPT_encrypt_bytes can be called only once for key. Since the code is well-documented, i suggest to read "ecrypt-sync.h" for further informations.

Download:

hxxps://anonfiles.com/36H0f310pe/salsa20_rar

 

[dyadka0220]

на гите есть реальзации по приятнее, не очень мне нравится идея структуры использовать.
каждый дрочит так как хочет

 

[5ven]

cr.yp.to первоисточник алгоритма, зачем ТС засунул merged-код в .cpp и отредактировал его непонятно

оригинал

static const char sigma[16] = "expand 32-byte k";
static const char tau[16] = "expand 16-byte k";

ТС

static const char sigma[17] = "expand 32-byte k";
static const char tau[17] = "expand 16-byte k";

 

[dyadka0220]

cr.yp.to первоисточник алгоритма, зачем ТС засунул merged-код в .cpp и отредактировал его непонятно

оригинал

static const char sigma[16] = "expand 32-byte k";
static const char tau[16] = "expand 16-byte k";

ТС

static const char sigma[17] = "expand 32-byte k";
static const char tau[17] = "expand 16-byte k";

затем что \0

 

[DildoFagins]

cr.yp.to первоисточник алгоритма, зачем ТС засунул merged-код в .cpp и отредактировал его непонятно

Сишечка скорее всего просто отрежет \0 с конца строки и не будет возмущаться, а в плюсах это скорее всего ошибка компиляции будет.

 

[5ven]

затем что \0

И что это дает?)

 

[dyadka0220]

И что это дает?)

сообщением выше

 

[5ven]

Это замечательно, но смысл таких действий все равно остался загадкой.

Делать патчи в крипту опасное занятие, вдруг код делает sizeof() и лишний байт все сломает или сделает дыру? Тесты помогут выявить ошибку, но большинство рансомварщиков про это не думают и делают похожий самопал без тестов который аверу на руку при создании декрипторов.

 

[dyadka0220]

Это замечательно, но смысл таких действий все равно остался загадкой.

Делать патчи в крипту опасное занятие, вдруг код делает sizeof() и лишний байт все сломает или сделает дыру? Тесты помогут выявить ошибку, но большинство рансомварщиков про это не думают и делают похожий самопал без тестов который аверу на руку при создании декрипторов.

Ну иди и по RFC реализовывай сам себе крипту, чё бухтишь то

 

[5ven]

Ну иди и по RFC реализовывай сам себе крипту, чё бухтишь то

Я что-то не так сказал? Я советую реализовывать самостоятельно крипту по RFC?

 

[DildoFagins]

Делать патчи в крипту опасное занятие, вдруг код делает sizeof() и лишний байт все сломает или сделает дыру? Тесты помогут выявить ошибку, но большинство рансомварщиков про это не думают и делают похожий самопал без тестов который аверу на руку при создании декрипторов.

О хоспаде, в данном конкретном случае это вообще не важно, сигма и тау используется для расширения ключа, и оттуда берется ровно 16 байт, не больше, не меньше. Можешь кстати забить эти байтовые массивы рандомными 16тью байтами и от этого криптостойкость алгоритма не должна поменяться.

static const char sigma[16] = "expand 32-byte k";
static const char tau[16] = "expand 16-byte k";

void ECRYPT_keysetup(ECRYPT_ctx *x,const u8 *k,u32 kbits,u32 ivbits)
{
int i;
static const char *constants;

x->input[1] = U8TO32_LITTLE(k + 0);
x->input[2] = U8TO32_LITTLE(k + 4);
x->input[3] = U8TO32_LITTLE(k + 8);
x->input[4] = U8TO32_LITTLE(k + 12);
if (kbits == 256) { /* recommended */
k += 16;
constants = sigma;
} else { /* kbits == 128 */
constants = tau;
}
x->input[11] = U8TO32_LITTLE(k + 0);
x->input[12] = U8TO32_LITTLE(k + 4);
x->input[13] = U8TO32_LITTLE(k + 8);
x->input[14] = U8TO32_LITTLE(k + 12);
x->input[0] = U8TO32_LITTLE(constants + 0);
x->input[5] = U8TO32_LITTLE(constants + 4);
x->input[10] = U8TO32_LITTLE(constants + 8);
x->input[15] = U8TO32_LITTLE(constants + 12);
}

 

[GlowingOne]

на гите есть реальзации по приятнее, не очень мне нравится идея структуры использовать.
каждый дрочит так как хочет

Я не доверяю реализациям github, потому что они написаны кем угодно и не протестированы. Эти фрагменты кода являются оригинальной реализацией людей, создавших Salsa20, и есть также тесты скорости этих кодов на исходной странице, на которую я ссылался. Коды Github обычно ужасно медленные. На этой странице есть контрольные показатели для этих реализаций, а также другие реализации для любого вида архитектуры. Кроме того, библиотека действительно проста в использовании, даже проще, чем cryptoapi, что ужасно.