Linguaggio di implementazione per crypto

Question

Linguaggio di implementazione per crypto

#1 da (13 voti)

2

Ho intenzione di implementare un piccolo strumento di crittografia lib /. La regola "non implementare la crittografia da solo" non si applica qui, poiché questo sistema crittografico è nuovo e non ancora implementato. ;) Quindi il primo passo è la scelta del linguaggio di implementazione. E la mia domanda qui è, se ci sono motivi per preferire uno rispetto all'altro.

Dato che deve essere efficiente, sono solidale con C o C ++. E con C o C ++ dovrebbe essere facile creare collegamenti per altri linguaggi come Java o Python, più tardi.

Quindi, se sei d'accordo con me, che C o C ++ è bello per questo scopo, concentrati su C vs. C ++.

C potrebbe essere un po 'più semplice e la mancanza di cose come gli oggetti potrebbe aiutare a evitare bug critici. D'altra parte, C ++ potrebbe offrire la possibilità di fare alcune cose in un modo più semplice. Come l'uso del dispositivo casuale C ++ 11 per i numeri casuali crittograficamente sicuri (ad esempio da / dev / urandom). O gestione delle eccezioni, ecc.

Ci sono probabilmente più punti. Ma forse la scelta non è così importante?!

Quali sono i tuoi pensieri?

cryptography programming

posta firefexx 02.02.2014 - 20:11

fonte

1 risposta

Leggi altre domande sui tag cryptography programming

Se Yahoo può essere hackerato, come possiamo proteggere i nostri piccoli siti web? [chiuso] Telnet e vpn - protetti o meno

score 13 · Accepted Answer

La scelta del linguaggio di programmazione per la crittografia dipende da molti parametri, inclusi (ma non limitati a) i seguenti:

Se l'obiettivo è sostenere la ricerca (ad esempio per provare le varianti), la lingua dovrebbe essere quella che è maggiormente controllata da chiunque effettuerà la ricerca. Ad esempio, le persone che vogliono "investigare su crypto" e sentirsi a proprio agio con Python useranno Python.
Se l'obiettivo è quello di servire da strumento pedagogico, ad es. per un'implementazione di riferimento di un nuovo algoritmo, dovrebbe essere preferito un linguaggio diffuso con semantica chiara. I crittografi hanno usato a lungo C per quel lavoro, ma, probabilmente, Java o C # sarebbero state scelte migliori in quanto avevano meno "angoli bui".
Se l'obiettivo è l'efficienza, l'architettura di destinazione è di fondamentale importanza; per esempio, molte piattaforme embedded supportano solo (un sottoinsieme di) C, e qualsiasi implementazione dovrà essere implementata più o meno direttamente in C (la traduzione automatica da altre lingue è possibile ma richiede lavoro). Se hai la scelta, poi le lingue compilate (ad es. C) e le lingue con i compilatori efficaci JIT (ad es. Java , C #) sono appropriati.
Se l'obiettivo è massimo di efficienza e si desidera eseguire il minor numero possibile di cicli di clock, sarà necessario un po 'di assemblaggio. Questo in pratica non importa, al di fuori dei microbenchmark (nella maggior parte delle applicazioni pratiche, la larghezza di banda della memoria e della memoria sono il collo di bottiglia, non la crittografia), ma è un esercizio divertente.
La maggior parte degli algoritmi crittografici elabora elementi segreti (ad esempio le chiavi) e potrebbe essere vulnerabile agli attacchi side-channel . Prevenire tali attacchi richiede una conoscenza approfondita di tutta la gestione arcana della memoria cache, della previsione di salto e di altri dettagli sottili. Le implementazioni che sono robuste contro tali attacchi sono terribilmente difficili da costruire, ma il problema diventa più facile (non facile, solo più facile) con un linguaggio di livello inferiore. Quindi, assembly o C (con C, devi ancora capire cosa sta succedendo a livello di assembly). Probabilmente, se conosci abbastanza per implementare un'implementazione crittografica senza canali laterali, sai già che ...
Se sei stanco della vita, usa C ++.

Personalmente, ho implementato algoritmi crittografici per vari obiettivi, tra cui ricerca, pedagogia ed efficiente codice a livello di produzione (attualmente implementato sul campo) in C, Java, C #, Forth, una dozzina di dialetti di montaggio e pochi altri le lingue. Nessuna di queste lingue era "migliore" delle altre in un modo assoluto; è tutta una questione di contesto.