![[HaBo]](/styles/default/logoklein.png){kind=small}
RC6 Referenz Implementation
- Themenstarter enkore
- Beginndatum
Kann beides sein, Hauptsache es liefert die richtigen Ergebnisse^^
Nunja, warum RC6?
Weil ich an einer Bibliothek arbeite namens CEXP ("CEXP 28398" wäre da ein Suchbegriff - oder http://28398.org/index.php?page_id=3&proj=2 ), die nunmal mehrere Algorithmen zur Verfügung stellt. Und weil ich da schon alles von SHA1-512, MD5, AES, TEA, XTEA, OTP und RC4 habe, dachte ich mir, dass RC5 und RC6 nicht schaden könnten. Naja kurz recherchiert, RC5 ist unsicher, RC6 soll deutlich sicherer sein, also nehmen wir den. Außerdem sind bekanntlich alle RCx's sehr sehr schnell und sicher...
EDIT:
http://en.wikipedia.org/wiki/RC6
Da steht die eigentliche Verschlüsselung... mit <<< und >>> ist wohl Rol und Ror gemeint?
Und S scheint mir die SBox zu sein...
Aber die Key Expansion fehlt da irgendwie... !?
Nunja, warum RC6?
Weil ich an einer Bibliothek arbeite namens CEXP ("CEXP 28398" wäre da ein Suchbegriff - oder http://28398.org/index.php?page_id=3&proj=2 ), die nunmal mehrere Algorithmen zur Verfügung stellt. Und weil ich da schon alles von SHA1-512, MD5, AES, TEA, XTEA, OTP und RC4 habe, dachte ich mir, dass RC5 und RC6 nicht schaden könnten. Naja kurz recherchiert, RC5 ist unsicher, RC6 soll deutlich sicherer sein, also nehmen wir den. Außerdem sind bekanntlich alle RCx's sehr sehr schnell und sicher...
EDIT:
http://en.wikipedia.org/wiki/RC6
Da steht die eigentliche Verschlüsselung... mit <<< und >>> ist wohl Rol und Ror gemeint?
Und S scheint mir die SBox zu sein...
Aber die Key Expansion fehlt da irgendwie... !?
Elderan
0
Hallo,
ja <<< ist rol.
Das Problem an RC6 ist, dass es patentiert ist. Ob man dieses Problemlos in eine Bib. einbauen darf, weiß ich nicht.
Außerdem sollte eine kryptographische Bib. nicht mit der Anzahl an Algorithmen protzen. Der User kann dann nicht entscheiden, welchen er verwenden soll und nimmt u.U. den falschen. Für fast alle Anwendungen ist eh AES zu empfehlen.
Ansonsten Sourceforge einfach mal nach RC6 bemühen:
http://sourceforge.net/projects/newaes2k/
http://sourceforge.net/projects/aeslib/
Oder Google nach 'RC6 reference implementation':
http://www.mirrors.wiretapped.net/security/cryptography/algorithms/rc6/:
Quelle: http://www.mirrors.wiretapped.net/security/cryptography/algorithms/rc6/rc6-unop.c
Aber du musst wie gesagt aufpassen:
ja <<< ist rol.
Das Problem an RC6 ist, dass es patentiert ist. Ob man dieses Problemlos in eine Bib. einbauen darf, weiß ich nicht.
Außerdem sollte eine kryptographische Bib. nicht mit der Anzahl an Algorithmen protzen. Der User kann dann nicht entscheiden, welchen er verwenden soll und nimmt u.U. den falschen. Für fast alle Anwendungen ist eh AES zu empfehlen.
Ansonsten Sourceforge einfach mal nach RC6 bemühen:
http://sourceforge.net/projects/newaes2k/
http://sourceforge.net/projects/aeslib/
Oder Google nach 'RC6 reference implementation':
http://www.mirrors.wiretapped.net/security/cryptography/algorithms/rc6/:
Code:
/* rc6 (TM)
* Unoptimized sample implementation of Ron Rivest's submission to the
* AES bakeoff.
*
* Salvo Salasio, 19 June 1998
*
* Intellectual property notes: The name of the algorithm (RC6) is
* trademarked; any property rights to the algorithm or the trademark
* should be discussed with discussed with the authors of the defining
* paper "The RC6(TM) Block Cipher": Ronald L. Rivest (MIT),
* M.J.B. Robshaw (RSA Labs), R. Sidney (RSA Labs), and Y.L. Yin (RSA Labs),
* distributed 18 June 1998 and available from the lead author's web site.
*
* This sample implementation is placed in the public domain by the author,
* Salvo Salasio. The ROTL and ROTR definitions were cribbed from RSA Labs'
* RC5 reference implementation.
*/
#include <stdio.h>
/* RC6 is parameterized for w-bit words, b bytes of key, and
* r rounds. The AES version of RC6 specifies b=16, 24, or 32;
* w=32; and r=20.
*/
#define w 32 /* word size in bits */
#define r 20 /* based on security estimates */
#define P32 0xB7E15163 /* Magic constants for key setup */
#define Q32 0x9E3779B9
/* derived constants */
#define bytes (w / 8) /* bytes per word */
#define c ((b + bytes - 1) / bytes) /* key in words, rounded up */
#define R24 (2 * r + 4)
#define lgw 5 /* log2(w) -- wussed out */
/* Rotations */
#define ROTL(x,y) (((x)<<(y&(w-1))) | ((x)>>(w-(y&(w-1)))))
#define ROTR(x,y) (((x)>>(y&(w-1))) | ((x)<<(w-(y&(w-1)))))
unsigned int S[R24 - 1]; /* Key schedule */
void rc6_key_setup(unsigned char *K, int b)
{
int i, j, s, v;
unsigned int L[(32 + bytes - 1) / bytes]; /* Big enough for max b */
unsigned int A, B;
L[c - 1] = 0;
for (i = b - 1; i >= 0; i--)
L[i / bytes] = (L[i / bytes] << 8) + K[i];
S[0] = P32;
for (i = 1; i <= 2 * r + 3; i++)
S[i] = S[i - 1] + Q32;
A = B = i = j = 0;
v = R24;
if (c > v) v = c;
v *= 3;
for (s = 1; s <= v; s++)
{
A = S[i] = ROTL(S[i] + A + B, 3);
B = L[j] = ROTL(L[j] + A + B, A + B);
i = (i + 1) % R24;
j = (j + 1) % c;
}
}
void rc6_block_encrypt(unsigned int *pt, unsigned int *ct)
{
unsigned int A, B, C, D, t, u, x;
int i, j;
A = pt[0];
B = pt[1];
C = pt[2];
D = pt[3];
B += S[0];
D += S[1];
for (i = 2; i <= 2 * r; i += 2)
{
t = ROTL(B * (2 * B + 1), lgw);
u = ROTL(D * (2 * D + 1), lgw);
A = ROTL(A ^ t, u) + S[i];
C = ROTL(C ^ u, t) + S[i + 1];
x = A;
A = B;
B = C;
C = D;
D = x;
}
A += S[2 * r + 2];
C += S[2 * r + 3];
ct[0] = A;
ct[1] = B;
ct[2] = C;
ct[3] = D;
}
void rc6_block_decrypt(unsigned int *ct, unsigned int *pt)
{
unsigned int A, B, C, D, t, u, x;
int i, j;
A = ct[0];
B = ct[1];
C = ct[2];
D = ct[3];
C -= S[2 * r + 3];
A -= S[2 * r + 2];
for (i = 2 * r; i >= 2; i -= 2)
{
x = D;
D = C;
C = B;
B = A;
A = x;
u = ROTL(D * (2 * D + 1), lgw);
t = ROTL(B * (2 * B + 1), lgw);
C = ROTR(C - S[i + 1], t) ^ u;
A = ROTR(A - S[i], u) ^ t;
}
D -= S[1];
B -= S[0];
pt[0] = A;
pt[1] = B;
pt[2] = C;
pt[3] = D;
}
struct test_struct
{
int keylen;
unsigned char key[32];
unsigned int pt[4];
unsigned int ct[4];
} tests[] =
{
{ 16, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
{0x00000000, 0x00000000, 0x00000000, 0x00000000},
{0x36a5c38f, 0x78f7b156, 0x4edf29c1, 0x1ea44898},
},
{ 16, {0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef,
0x01, 0x12, 0x23, 0x34, 0x45, 0x56, 0x67, 0x78},
{0x35241302, 0x79685746, 0xbdac9b8a, 0xf1e0dfce},
{0x2f194e52, 0x23c61547, 0x36f6511f, 0x183fa47e},
},
{ 24, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
{0x00000000, 0x00000000, 0x00000000, 0x00000000},
{0xcb1bd66c, 0x38300b19, 0x163f8a4e, 0x82ae9086},
},
{ 24, {0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef,
0x01, 0x12, 0x23, 0x34, 0x45, 0x56, 0x67, 0x78,
0x89, 0x9a, 0xab, 0xbc, 0xcd, 0xde, 0xef, 0xf0},
{0x35241302, 0x79685746, 0xbdac9b8a, 0xf1e0dfce},
{0xd0298368, 0x0405e519, 0x2ae9521e, 0xd49152f9},
},
{ 32, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
{0x00000000, 0x00000000, 0x00000000, 0x00000000},
{0x05bd5f8f, 0xa85fd110, 0xda3ffa93, 0xc27e856e},
},
{ 32, {0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef,
0x01, 0x12, 0x23, 0x34, 0x45, 0x56, 0x67, 0x78,
0x89, 0x9a, 0xab, 0xbc, 0xcd, 0xde, 0xef, 0xf0,
0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe},
{0x35241302, 0x79685746, 0xbdac9b8a, 0xf1e0dfce},
{0x161824c8, 0x89e4d7f0, 0xa116ad20, 0x485d4e67},
},
{ 0,
}
};
int
main()
{
unsigned int ct[4], pt[4];
int i;
struct test_struct *p;
for (p = tests, i = 1; p->keylen; p++, i++)
{
rc6_key_setup(p->key, p->keylen);
rc6_block_encrypt(p->pt, ct);
printf("Test %d: %08x %08x %08x %08x\n",
i, ct[0], ct[1], ct[2], ct[3]);
printf("Should be: %08x %08x %08x %08x\n",
p->ct[0], p->ct[1], p->ct[2], p->ct[3]);
rc6_block_decrypt(ct, pt);
printf("Plain: %08x %08x %08x %08x\n",
pt[0], pt[1], pt[2], pt[3]);
printf("Should be: %08x %08x %08x %08x\n\n",
p->pt[0], p->pt[1], p->pt[2], p->pt[3]);
}
return 0;
}Aber du musst wie gesagt aufpassen:
Persönlich würde ich RC6 draußen lassen, nur sichere Algorithmen einbauen die man noch verwenden sollte und evt. an sonstigen Funktionen erweitern, z.B. Strom Chiffre Modi einbauen etc.
Hmm ja, vielleicht frage ich die auch einfach mal wie das in meinem speziellen Falle ist.
Klar, man sollte nicht sagen "Schaut her, ich habe 21 verschiedene Algorithmen!!", ich denke aber, dass eine gewisse Auswahl vorhanden sein sollte. Und mit den verschiedenen SHA Varianten sah es so für mich aus, dass SHA1 leicht zu übersetzten war, und SHA384 und SHA512 bis auf die Initialize und Finalize-Funktionen sowieso den gleichen Code haben. Und SHA256 war auch nicht so schwer. Ich denke bei SHA ist es sinnvoll zwischen Geschwindigkeit (SHA1) und Sicherheit (SHA512) einigermaßen frei wählen zu können. Und sowas wie MD5 gehört, obwohl es unsicher ist, doch immernoch in jede Library rein.
Ich hatte aber sowieso vor, eine Art Guide zu schreiben, wo die Einsatzbereiche und die Vor- und Nachteile der einzelnen Algorithmen genau erläutert werden, und ebenfalls für bestimmte Zwecke bestimmte Algorithmen empfohlen werden.
Natülich hast du recht, AES/RIJNDAEL ist nunmal einer der sichersten, schnellsten und vielfältigsten Algorithmen überhaupt. Aber manchmal ist sowas wie RC4 oder XTEA eher gewünscht - denn XTEA ist auch sehr sicher und wohl in Geschwindigkeit kaum zu toppen...
Werde mir auf jeden Fall die von dir angehängte Implementation anschauen...
Da meine Bibliothek aber auch ein Pluginsystem hat, könnte ich ja auch ein Plugin mit den Rechtshinweisen schreiben... (Ja klingt crazy, eine Kryptolib mit Pluginsystem, ist aber vll. ganz nützlich (*wenn* man den Plugins vertraut, versteht sich...)
Ich weiss, dass klingt komisch, wenn ein 14 jähriger Schüler aus Niedersachsen, der in der 8. Klasse eine 4------ in Mathe hatte, meint, dass es einfach ist, SHA1-512 von C nach FreeBasic zu portieren. Ich bin mir dessen auch bewusst, aber übersetzten von Quelltexten liegt mir, und dass, obwohl ich gar kein C/C++ schreiben kann, sondern nur lesen...
EDIT:
BOAR
http://www.mirrors.wiretapped.net/security/cryptography/algorithms/
Klar, man sollte nicht sagen "Schaut her, ich habe 21 verschiedene Algorithmen!!", ich denke aber, dass eine gewisse Auswahl vorhanden sein sollte. Und mit den verschiedenen SHA Varianten sah es so für mich aus, dass SHA1 leicht zu übersetzten war, und SHA384 und SHA512 bis auf die Initialize und Finalize-Funktionen sowieso den gleichen Code haben. Und SHA256 war auch nicht so schwer. Ich denke bei SHA ist es sinnvoll zwischen Geschwindigkeit (SHA1) und Sicherheit (SHA512) einigermaßen frei wählen zu können. Und sowas wie MD5 gehört, obwohl es unsicher ist, doch immernoch in jede Library rein.
Ich hatte aber sowieso vor, eine Art Guide zu schreiben, wo die Einsatzbereiche und die Vor- und Nachteile der einzelnen Algorithmen genau erläutert werden, und ebenfalls für bestimmte Zwecke bestimmte Algorithmen empfohlen werden.
Natülich hast du recht, AES/RIJNDAEL ist nunmal einer der sichersten, schnellsten und vielfältigsten Algorithmen überhaupt. Aber manchmal ist sowas wie RC4 oder XTEA eher gewünscht - denn XTEA ist auch sehr sicher und wohl in Geschwindigkeit kaum zu toppen...
Werde mir auf jeden Fall die von dir angehängte Implementation anschauen...
Da meine Bibliothek aber auch ein Pluginsystem hat, könnte ich ja auch ein Plugin mit den Rechtshinweisen schreiben... (Ja klingt crazy, eine Kryptolib mit Pluginsystem, ist aber vll. ganz nützlich (*wenn* man den Plugins vertraut, versteht sich...)
Ich weiss, dass klingt komisch, wenn ein 14 jähriger Schüler aus Niedersachsen, der in der 8. Klasse eine 4------ in Mathe hatte, meint, dass es einfach ist, SHA1-512 von C nach FreeBasic zu portieren. Ich bin mir dessen auch bewusst, aber übersetzten von Quelltexten liegt mir, und dass, obwohl ich gar kein C/C++ schreiben kann, sondern nur lesen...
EDIT:
BOAR
http://www.mirrors.wiretapped.net/security/cryptography/algorithms/
Elderan
0
Hallo,
naja von RC4 würde ich unbedingt abraten, einmal weil es die allgemeinen Nachteile von Stromchiffren hat (Key kann nur einmal genutzt werden) und weil der Umgang mit RC4 gar nicht so leicht ist (ersten Bytes müssen verworfen werden etc.). Das muss man alles in der Lib. dann erwähnen.
Aber wozu muss TEA oder XTEA enthalten sein? Persönlich finde ich XTEA relativ cool, da es schön schlank ist, in einer kryptographischen Library muss es aber eigentlich nicht sein. Ebenso gehört da TEA nicht rein, wenn schon XTEA vorhanden ist.
Und XTEA ist von der Performance her schlechter als AES, da es einmal 64 Runden und nur 64 Bit Blöcke bearbeitet, also 128 Runden pro 128 Bit Block. AES kommt dort mit 10 Runden aus.
Ein Benchmark ergab das mein Rechner für AES 3187 Clocks für AES und 4953 Clocks für XTEA für die selbe Datenmenge benötigte (10 Mio. bzw. 20 Mio. mal bei XTEA die encrypt() Routine aufgerufen). Also ist AES rund 1,55 mal schneller als XTEA.
Kannst ja einfach mal selber testen.
Deswegen sollte man XTEA auch nicht für Anwendungen einsetzen, sofern es sich nicht vermeiden lässt oder andere Gründe dafür sprechen.
Achja, und warum ist dort eine One-Time-Pad Implementierung enthalten?
naja von RC4 würde ich unbedingt abraten, einmal weil es die allgemeinen Nachteile von Stromchiffren hat (Key kann nur einmal genutzt werden) und weil der Umgang mit RC4 gar nicht so leicht ist (ersten Bytes müssen verworfen werden etc.). Das muss man alles in der Lib. dann erwähnen.
Aber wozu muss TEA oder XTEA enthalten sein? Persönlich finde ich XTEA relativ cool, da es schön schlank ist, in einer kryptographischen Library muss es aber eigentlich nicht sein. Ebenso gehört da TEA nicht rein, wenn schon XTEA vorhanden ist.
Und XTEA ist von der Performance her schlechter als AES, da es einmal 64 Runden und nur 64 Bit Blöcke bearbeitet, also 128 Runden pro 128 Bit Block. AES kommt dort mit 10 Runden aus.
Ein Benchmark ergab das mein Rechner für AES 3187 Clocks für AES und 4953 Clocks für XTEA für die selbe Datenmenge benötigte (10 Mio. bzw. 20 Mio. mal bei XTEA die encrypt() Routine aufgerufen). Also ist AES rund 1,55 mal schneller als XTEA.
Kannst ja einfach mal selber testen.
Deswegen sollte man XTEA auch nicht für Anwendungen einsetzen, sofern es sich nicht vermeiden lässt oder andere Gründe dafür sprechen.
Achja, und warum ist dort eine One-Time-Pad Implementierung enthalten?
Naja, ich schreibe die Lib eben nicht für die Krypto-Geeks, sondern eher für den Durchschnittsprogrammierer...
Ich denke XTEA hat z.B. gegenüber RIJNDAEL den Vorteil, dass es relativ wenig Speicher braucht.
Klar RC4 ist nicht so einfach zu nutzten, aber richtig benutzt ist er eben doch noch zu etwas zu gebrauchen. Und wenn man nur Daten gegen DAUs und nicht gegen "echte" Hacker schützen will, reicht RC4 alle male...
Nunja OTP habe ich eingebaut, weil es nunmal die simpelste Verschlüsselung überhaupt ist. Klar wirklich brauchbar ist es nicht, aber ich dachte mir, dass es auch nicht schadet...
Ich denke XTEA hat z.B. gegenüber RIJNDAEL den Vorteil, dass es relativ wenig Speicher braucht.
Klar RC4 ist nicht so einfach zu nutzten, aber richtig benutzt ist er eben doch noch zu etwas zu gebrauchen. Und wenn man nur Daten gegen DAUs und nicht gegen "echte" Hacker schützen will, reicht RC4 alle male...
Nunja OTP habe ich eingebaut, weil es nunmal die simpelste Verschlüsselung überhaupt ist. Klar wirklich brauchbar ist es nicht, aber ich dachte mir, dass es auch nicht schadet...
Elderan
0
Hallo,
Auch finde ich es für Anfänger wichtig, diesen möglichst einfache Klassen zur Hand zu geben. Evt. eine Klasse, womit man leicht Strings verschlüsseln kann o.ä.
Natürlich ist selbst die speicher-arme AES Variante etwas speicher lastiger als XTEA, aber ob ich nun 16 Byte oder evt. 256 Byte Speicherbedarf habe, how cares? Wenn man nun einen Algo. sucht für einen z.B. RFID Chip, dann okay, dann spielt der Speicherbedarf u.U. eine Rolle.
Aber für den normalen Computer? Was sind dort 256 Byte mehr? Allein wenn ein Programm geladen wird, wird meistens schon zig Kilobyte an Speicher gebraucht.
Was aber relevant ist, ist die Performance. Und dort würde ich klar einen 50% schnelleren Algorithmus vorziehen. Mal davon abgesehen, dass AES mehr Sicherheit bietet als XTEA und man AES auch z.B. in Stromchiffren-Modi betreiben kann, was bei XTEA aufgrund der 64 Bit Blockbreite schwieriger wird.
Wenn man schon von Speicherbedarf redet: Durch mehr und teils unsinnge Algorithmen (OTP, TEA wenn XTEA schon drin ist), bläht sich die Library auf => mehr Speicherbedarf.
Ich hab mal den Benchmark angehängt. Für Windows muss man das gettimeofday() entsprechend mit clock() realisieren.
Persönlich sollte eine Crypto Lib nicht nur Algorithmen enthalten, sondern auch praktiche Anwendungen diese zu nutzen. Ich möchte eine Möglichkeit haben Algorithmen in OFB, CFB oder CTR Mode zu betreiben, leichte String Verschlüsselung, gerne sichere Protokolle (SSL) etc.
Eine Ansammlung von möglichst vielen Algorithmen hilft nicht wirklich. Wobei, für C/C++ geht nichts an Crypto++ vorbei (warum die aber z.B. Skipjack drin haben, ist mir ein Rätsel).
Gerade dann sollte man sich meines Erachtens auf sehr wenige Algorithmen beschränken. Lieber weniger Algorithmen, dafür diese dann richtig, z.B. mit Optimierungen in Assembler o.ä.
Auch finde ich es für Anfänger wichtig, diesen möglichst einfache Klassen zur Hand zu geben. Evt. eine Klasse, womit man leicht Strings verschlüsseln kann o.ä.
Naja wirklich viel Speicher braucht AES auch nicht, je nachdem auf was man es optimiert (Performance oder Speicherbedarf).
Natürlich ist selbst die speicher-arme AES Variante etwas speicher lastiger als XTEA, aber ob ich nun 16 Byte oder evt. 256 Byte Speicherbedarf habe, how cares? Wenn man nun einen Algo. sucht für einen z.B. RFID Chip, dann okay, dann spielt der Speicherbedarf u.U. eine Rolle.
Aber für den normalen Computer? Was sind dort 256 Byte mehr? Allein wenn ein Programm geladen wird, wird meistens schon zig Kilobyte an Speicher gebraucht.
Was aber relevant ist, ist die Performance. Und dort würde ich klar einen 50% schnelleren Algorithmus vorziehen. Mal davon abgesehen, dass AES mehr Sicherheit bietet als XTEA und man AES auch z.B. in Stromchiffren-Modi betreiben kann, was bei XTEA aufgrund der 64 Bit Blockbreite schwieriger wird.
Wenn man schon von Speicherbedarf redet: Durch mehr und teils unsinnge Algorithmen (OTP, TEA wenn XTEA schon drin ist), bläht sich die Library auf => mehr Speicherbedarf.
Wenn meine Library schon AES anbietet, wieso sollte ich dann RC4 wählen? Und wenn ich den Fehler begehe, was garaniert vor allem bei Anfänger geschieht, zwei mal den gleichen Key zu verwenden, dann ist RC4 auf einmal gar nicht mehr so sicher.
Ich hab mal den Benchmark angehängt. Für Windows muss man das gettimeofday() entsprechend mit clock() realisieren.
Persönlich sollte eine Crypto Lib nicht nur Algorithmen enthalten, sondern auch praktiche Anwendungen diese zu nutzen. Ich möchte eine Möglichkeit haben Algorithmen in OFB, CFB oder CTR Mode zu betreiben, leichte String Verschlüsselung, gerne sichere Protokolle (SSL) etc.
Eine Ansammlung von möglichst vielen Algorithmen hilft nicht wirklich. Wobei, für C/C++ geht nichts an Crypto++ vorbei (warum die aber z.B. Skipjack drin haben, ist mir ein Rätsel).