[?] Algoritmo di criptazione serio
Nicola Pietralunga
Ho la necessità di inserire in una mia applicazione una serie di dati
criptati come si deve.
Tralasciando tutti i metodi più o meno empirici e di efficacia non provata,
mi sarei orientato sull'algoritmo BlowFish (in quanto non soggetto a
royalty) con chiave da 128 bit o, mal che vada, sul DES o Triple-DES con
chiave a 56 bit.
Premesso questo, chiedo a voi amici la risposta a uno dei punti seguenti a
scelta:
1) Esiste qualcuno che ha una routine VB che implementa uno di questi
algoritmi o eventualmente un altro algoritmo ma di efficacia paragonabile?
2) Avete qualche DLL che funzioni con chiamate da VB6 (io ne ho una che
riesco ad usare ma è scritta in VB5 e mi costringerebbe a distribuire anche
i runtime di VB5)?
3) A qualcuno interessa l'argomento tanto da aiutarmi con un paio di
librerie che posseggo? Queste librerie sono scritte in C e la chiamata è
documentata per il C; io dovrei trovare il modo di adattarla al VB.
Grazie a tutti,
<--< Nik >-->
Per rispondermi in E-Mail togliere "deleteme" dall'indirizzo.
To reply me by E-Mail remove "deleteme" from my address.
Roal Zanazzi
7i8ist$i0p$3...@fe2.cs.interbusiness.it...
> Ho la necessità di inserire in una mia applicazione una serie di dati
> criptati come si deve.
> Tralasciando tutti i metodi più o meno empirici e di efficacia non
provata,
> mi sarei orientato sull'algoritmo BlowFish (in quanto non soggetto a
> royalty) con chiave da 128 bit o, mal che vada, sul DES o Triple-DES con
> chiave a 56 bit.
> algoritmi o eventualmente un altro algoritmo ma di efficacia paragonabile?
per Delphi (Delphi Super Page: http://www.programmers.net/mirrors/DSP/) c'e'
del materiale con il codice per l'algoritmo BlowFish (usa la funzione di
ricerca del sito) e forse anche DES o altro.
> 3) A qualcuno interessa l'argomento tanto da aiutarmi con un paio di
> librerie che posseggo? Queste librerie sono scritte in C e la chiamata è
> documentata per il C; io dovrei trovare il modo di adattarla al VB.
>
Potrebbe essere interessante (poi si puo' mettere sul Sito Comune).
Prova a postare le dichiarazioni in C.
--
Roal Zanazzi
z...@iol.it
Davide Greco
>criptati come si deve.
>Tralasciando tutti i metodi più o meno empirici e di efficacia non provata,
criptazione fatturazione in nero ?
criptazione formula chimica per riprodurre la coca cola ?
scherzi a parte...
io sono dell'idea che qualsiasi cosa debba essere nascosta è sempre meglio
"farsela in casa" (nel senso di nasconderla con qualche complicatissima
chiave di caratteri ascii....). Il motivo è presto detto.. se l'intelligenza
umana supera quella artificiale allora per trovare la chiave di accesso
serve un cervello umano e non un PC. Questo vuol dire che nessun algoritmo
dovrà mai essere in grado di de-criptare ciò che nascondi.... o quanto meno
dovrà essere così complesso da scoraggiare chicchessia a studiarne il
codice. Detto questo prova a capire dove ho scritto la frase "ciao sono qui"
in questa stringa
_¦ï¢ªÅ_-áƒÇÌíÏ÷Üýÿ¶_¥íøî¦_Úá_Û+++ÏãÈÍ¿¦-Îi¦
soprattutto (sempre che tu ne abbia voglia) prova a trovare un nesso logico
in questi caratteri o un legame algebrico nel codice ascii sapendo a priori
la frase da cercare.... inutile soffermarmi sul fatto che se tu non sapessi
la frase da cercare ci impiegheresti chissà quanto tempo a capire cosa c'è
nascosto in quella trentina di caratteri. Adesso moltiplica questa stringa
per 200 (cioè 30x200=6000 caratteri) e fatti una bella risata pensando a
quanto diventerà scemo colui che un giorno deciderà di decifrare 6000
caratteri quando invece hai scritto solo "ciao sono qui"
ciao
Davide
(colui che le pensa tutte solo per il piacere schizofrenico di pensarle)
>mi sarei orientato sull'algoritmo BlowFish (in quanto non soggetto a
>royalty) con chiave da 128 bit o, mal che vada, sul DES o Triple-DES con
>chiave a 56 bit.
>Premesso questo, chiedo a voi amici la risposta a uno dei punti seguenti a
>scelta:
>1) Esiste qualcuno che ha una routine VB che implementa uno di questi
>algoritmi o eventualmente un altro algoritmo ma di efficacia paragonabile?
>2) Avete qualche DLL che funzioni con chiamate da VB6 (io ne ho una che
>riesco ad usare ma è scritta in VB5 e mi costringerebbe a distribuire anche
>i runtime di VB5)?
>3) A qualcuno interessa l'argomento tanto da aiutarmi con un paio di
>librerie che posseggo? Queste librerie sono scritte in C e la chiamata è
>documentata per il C; io dovrei trovare il modo di adattarla al VB.
>
Flavio Ronco
> >Ho la necessità di inserire in una mia applicazione una serie di dati
> >criptati come si deve.
>
> >Tralasciando tutti i metodi più o meno empirici e di efficacia non provata,
> io sono dell'idea che qualsiasi cosa debba essere nascosta è sempre meglio
> "farsela in casa" (nel senso di nasconderla con qualche complicatissima
> chiave di caratteri ascii....). Il motivo è presto detto.. se l'intelligenza
> umana supera quella artificiale allora per trovare la chiave di accesso
> serve un cervello umano e non un PC. Questo vuol dire che nessun algoritmo
> dovrà mai essere in grado di de-criptare ciò che nascondi.... o quanto meno
> dovrà essere così complesso da scoraggiare chicchessia a studiarne il
> codice.
In questo sono d'accordo, anche io mi sono arrangiato, quando mi è servito, con
un dubbio, però.
Tu dici:
> Detto questo prova a capire dove ho scritto la frase "ciao sono qui"
> in questa stringa
>
> _¦ï¢ªÅ_-áƒÇÌíÏ÷Üýÿ¶_¥íøî¦_Úá_Û+++ÏãÈÍ¿¦-Îi¦
>
> soprattutto (sempre che tu ne abbia voglia) prova a trovare un nesso logico
> in questi caratteri o un legame algebrico nel codice ascii sapendo a priori
> la frase da cercare.... inutile soffermarmi sul fatto che se tu non sapessi
> la frase da cercare ci impiegheresti chissà quanto tempo a capire cosa c'è
> nascosto in quella trentina di caratteri.
Questo vale se il malandrino nonpossiede il software che ha generato la stringa,
poiché se ha la possibilità di far generare stringe e vederne il risultato, un
semplice complemento XOR con una chiave, diventa subito visibile...
Io credo di aver avuto una buona idea, ma se la svelo...:-))
Flavio Ronco
--
f.ronco@*NonMiServeNiente*flashnet.it
http:\\www.geocities.com\Paris\3461\
-------------------------------------------------------------
"Che pubblico in gamba! Se ci dite dove lavorate,
domani mattina se abbiamo tempo vi veniamo a vedere"
[Paolo Rossi]
Nicola Pietralunga
>Davide Greco ha scritto:
>> io sono dell'idea che qualsiasi cosa debba essere nascosta č sempre
meglio
>> "farsela in casa" (nel senso di nasconderla con qualche complicatissima
Mi spiace, Flavio e Davide, non sono d'accordo con voi. :-)
Io non so molto di attacchi a testi cifrati, perň penso che sia abbastanza
semplice decrittare testi protetti con algoritmi che non abbiano una solida
base matematica.
La mia opinione in questo campo non vale nulla, perň me la sono fatta
leggendo alcuni testi di chi con la crittografia ci vive.
Inoltre, un sistema crittografico diventa tanto piů debole quanto piů
l'attaccante ha a disposizione diversi testi cifrati con il medesimo metodo.
Quindi se un qualunque metodo di criptazione puň andare relativamente bene
per cifrare UN testo, cifrarne tanti con lo stesso metodo č molto piů
pericoloso.
Credo che qualunque algoritmo di criptazione "fatto in casa" reggerebbe ben
poco contro un esperto di criptanalisi (la criptanalisi č la tecnica che si
occupa di studiare come rompere i sistemi di cifratura ed č fondamentale per
lo sviluppo di sistemi di criptazione sicuri; infatti un sistema viene
reputato tanto piů sicuro quanto piů tempo resiste alle tecniche
criptanalitiche).
Vi rimando per eventuali approfondimenti alle completissime FAQ della RSA
http://www.rsa.com/rsalabs/faq/
Ciao,
Nicola Pietralunga
Da: Roal Zanazzi <z...@iol.it>
Newsgroup: it.comp.lang.visual-basic
Data: mercoledì 26 maggio 1999 17.21
Oggetto: R: [?] Algoritmo di criptazione serio
>> 3) A qualcuno interessa l'argomento tanto da aiutarmi con un paio di
>> librerie che posseggo? Queste librerie sono scritte in C e la chiamata è
>> documentata per il C; io dovrei trovare il modo di adattarla al VB.
>>
>Potrebbe essere interessante (poi si puo' mettere sul Sito Comune).
>Prova a postare le dichiarazioni in C.
Grazie della disponibilità.
Seguono le API per il criptaggio con gli algoritmi DES e IDEA, oltre alle
API del sistema di Hashing MD5 (per la firma digitale).
Io non mi ci sono messo dietro perchè di C e Borland C, in particolare, non
so niente.
Se riesci a cavarne fuori qualcosa mi saresti di grande aiuto. Qualunque
cosa riesca ad ottenere lo posterò sul sito comune.
Ciao,
<--< Nik >-->
Per rispondermi in E-Mail togliere "deleteme" dall'indirizzo.
To reply me by E-Mail remove "deleteme" from my address.
--------------------------------------------------------------
API DES
-------
int FAR PASCAL des_key_sched(des_cblock FAR *key,
des_key_schedule FAR *sched)
key FAR pointer to a 64 bit key. a `des_cblock' is simply an 8-byte
unsigned character array so you can just pass the address of an 8
byte array as this parameter.
sched FAR pointer to an address of a des_key_schedule structure that the
function will fill in with the DES key schedule information that
you will need to pass to the encryption/decryption function.
You need to call this function before you use the des_ecb_encrypt
function to operate on your data. It performs some initial
operations on your key, presumably to make the operation of the
cipher faster.
Always returns zero.
int FAR PASCAL des_ecb_encrypt(des_cblock FAR *input,
des_cblock FAR *output,
des_key_schedule FAR *ks,
int encrypt)
input FAR pointer to an 8 byte block to be encrypted/decrypted
output FAR pointer to an 8 byte block to hold the results of the
encryption/decryption
ks FAR pointer to the des_key_schedule structure that you were given
by the des_key_sched() function (above)
encrypt 1 (TRUE) if you encrypting, 0 (FALSE) if you are decrypting
Example
-------
To encrypt an 8 byte block, you may have a program fragment like this:
void encrypt_block(BYTE *block,BYTE *key)
{
des_key_schedule ks;
des_key_sched(&key,&ks);
des_ecb_encrypt(&block,&block,1);
}
The function prototypes in des.h should ensure that you don't have to
explicitly cast the arguments.
Comments
--------
The DLL was compiled with Borland C++ v3.1 with optimizations set to
`fastest', using the 286 instruction set option. You can probably get quite
a speed increase using the 386 instruction set.
-----------------------------------------------------------
API IDEA
--------
VOID FAR PASCAL ExpandUserKey(LPWORD userKey,LPWORD key)
userKey FAR pointer to 16 byte IDEA key
key FAR pointer to 104 byte buffer that is to hold the expanded key
This function expands the 128 bit IDEA key to its internal 832 bit
form. All other API functions require this 832 bit key, so you must
call ExpandUserKey before anything else. You'll probably need to
typecast your arguments to LPWORD to shut your compiler up.
VOID FAR PASCAL InvertIdeaKey(LPWORD key,LPWORD invKey)
key FAR pointer to full 832 bit encryption key
invKey FAR pointer to an 832 bit buffer to receive the decryption key
InvertIdeaKey takes the 832 bit encryption key given to you by
ExpandUserKey and gives you an 832 bit decryption key.
VOID FAR PASCAL Idea(LPWORD dataIn,LPWORD dataOut,LPWORD key)
dataIn FAR pointer to an 8 byte buffer to encrypt/decrypt
dataOut FAR pointer to an 8 byte buffer to receive the results of the
encryption/decryption
key FAR pointer to the full 832 bit encryption/decryption key
This is the core encrypt/decrypt function. Encryption is acheived
by using the key derived from ExpandUser key. Decryption is
acheived by using the key given to you by InvertIdeaKey
Comments
--------
The DLL was compiled with Borland C++ v3.1 with optimizations set to
`fastest', using the 286 instruction set option. If you want a performance
increase, compile with the 386 instruction set.
----------------------------------------------------------
API MD5
-------
There are two ways to compute a hash. The first is totally automatic and
requires you to call only one function. The other is more general and
requires you to manually call the initialisation, update and termination
functions.
VOID FAR PASCAL MD5(LPBYTE data,int bytes,LPBYTE hash)
data FAR pointer to the information to hash
bytes number of bytes pointed to by `data'. Must be <=32767.
hash FAR pointer to a a buffer to receive the 128 bit (16 byte) hash
This function is the simplest way to interface to MD5, but relies
on there being less than 32K of data to hash. Not so good for
hashing files, but fine for hashing down a passphrase to get a
cryptographic key.
VOID FAR PASCAL MD5Init(VOID)
Initialise the internal MD5 variables. You must call this before
using MD5Update() or MD5Final().
VOID FAR PASCAL MD5(Update(LPBYTE inBuf,WORD inLen)
inBuf FAR pointer to buffer containing information to add to current hash
inLen Number of bytes in `inBuf'. Note inLen must be <=64K
This function updates the current hash with the contents of inBuf.
If you are hashing a file then it is likely that you will call this
many times as you read in data.
VOID FAR PASCAL MD5Final(VOID)
Finishes off the hashing. You must call this when you are finished
calling MD5Update().
VOID FAR PASCAL MD5GetHash(LPBYTE hash)
hash FAR pointer to a 16 byte buffer that is to receive the hash
After completing a hash operation that will have typically
consisted of a call to MD5Init, many calls to MD5Update and then a
single call to MD5Final, this function returns you the actual 16
byte hash.
Comments
--------
MD5.DLL was compiled using Borland C++ v3.1 with optimizations set to
`fastest'. The API interface was designed to shield the user from exposure
to the internal MD5_CTX structure.
Nicola Pietralunga
Nicola Pietralunga
Nicola Pietralunga
Davide Greco
anzi.. proprio se crei la cifratura con un algoritmo matematico questo è
tanto più decifrabile proprio perchè chi se ne occupa è ferrato in materia.
Prova a dire ad un computer di analizzare la sequenza 91 7 23 44 4 65 78 1
e vedi come ti va in palla con miliardi di calcoli che poi non servono
nulla... infatti basta il solo 23 ma questo ovviamente al Computer non
glielo diciamo.
Piuttosto avevo anche considerato quella roba di avere più testi da
decifrare per capire il meccanismo. Beh mi son detto che l'utente folle
avrebbe dovuto acquistare almeno 30 o 40 volte il mio software dandomi nomi
sempre differenti e a ben guardarla sta cosa mi sta pure bene :-))
però ti invito a riflettere su stringhe di 6000 caratteri che sono valide
per nomi lunghi 20-25 caratteri. Servirebbero migliaia e forse milioni di
testi da decifrare per giungere alla soluzione.
boh... io mi arrangio con mezzi quasi fraudolenti e se becco il tipo
smanettone che compra 40 volte per carpire il segreto mi sta bene :-)))
ciao Davide
>Credo che qualunque algoritmo di criptazione "fatto in casa" reggerebbe ben
>poco contro un esperto di criptanalisi (la criptanalisi è la tecnica che si
>occupa di studiare come rompere i sistemi di cifratura ed è fondamentale
per
>lo sviluppo di sistemi di criptazione sicuri; infatti un sistema viene
>reputato tanto più sicuro quanto più tempo resiste alle tecniche
>criptanalitiche).
>Vi rimando per eventuali approfondimenti alle completissime FAQ della RSA
>http://www.rsa.com/rsalabs/faq/
non mancherò di leggermi ste FAQ....
Nicola Pietralunga
Nicola Pietralunga
stramaledetto outlook ogni volta che ci provava aggiungeva un messaggio.
Flavio Ronco
> Prova a dire ad un computer di analizzare la sequenza 91 7 23 44 4 65 78 1
> e vedi come ti va in palla con miliardi di calcoli che poi non servono
> nulla... infatti basta il solo 23 ma questo ovviamente al Computer non
> glielo diciamo.
Sono d'accordo con te su alcuni punti, ma tu consideri solo il caso della
registrazione di un software. Invece, laddove mi è possibile specificare una
password, far girare il programma e confrontare il risultato con altri ottenuti
variando il contenuto e la password, posso arrivare per confronto alla
decrittazione. Certo, se il mio algoritmo è un algoritmo con i controfiocchi
posso rendere la cosa piuttosto difficile. Ma solo un bravo criptoanalista può
dirmi se il mio algoritmo è valido, dopo aver tentato di decrittarlo. Inoltre,
devo considerare quanto valgono i dati che cripto: in certi casi può valere la
pena qualche anno-uomo di lavoro...
>
> Piuttosto avevo anche considerato quella roba di avere più testi da
> decifrare per capire il meccanismo. Beh mi son detto che l'utente folle
> avrebbe dovuto acquistare almeno 30 o 40 volte il mio software dandomi nomi
> sempre differenti e a ben guardarla sta cosa mi sta pure bene :-))
> però ti invito a riflettere su stringhe di 6000 caratteri che sono valide
> per nomi lunghi 20-25 caratteri. Servirebbero migliaia e forse milioni di
> testi da decifrare per giungere alla soluzione.
Beh, se devi criptare un file di 10 Mega, tipo un Database o delle immagini, a
che dimensione arrivi? E, ripeto, considera che il tuo algoritmo usato in questo
modo, dà la possibilità al cracker di ottenere tutti gli output che vuole.
Naturalmente farà dei tentativi mirati, guarderà cosa cambia criptando una
stringa di uno, dieci, cento diecimila caratteri, magari tutti chr$(0) o tutte A
o tutte sequenze di ABCDEFG. Controllerà la differenza che passa fra la
criptazione di "A" e di "B", e di "ABC" e BCD", e via dicendo...
Io ho elaborato un mio algoritmo, che ritengo abbastanza complesso, e ti devo
dire che ogni espediente che mi veniva in mente, aveva una qualche possibilità
di essere scoperto con la logica del confronto. Così sono arrivato a d una
conclusione più o meno simile alla tua: incasinare il più possibile. Il che
significa non rendere matematicamente sicura la decrittazione, ma (cercare di)
renderla economicamente sconveniente. E non è la stessa cosa...
Ciao
Davide Greco
>registrazione di un software. Invece, laddove mi è possibile specificare
una
>password, far girare il programma e confrontare il risultato con altri
ottenuti
>variando il contenuto e la password, posso arrivare per confronto alla
>decrittazione. Certo, se il mio algoritmo è un algoritmo con i
controfiocchi
>posso rendere la cosa piuttosto difficile. Ma solo un bravo criptoanalista
può
>dirmi se il mio algoritmo è valido, dopo aver tentato di decrittarlo.
Inoltre,
>devo considerare quanto valgono i dati che cripto: in certi casi può valere
la
>pena qualche anno-uomo di lavoro...
beh si potrebbe studiare un algoritmo indiavolato che assegna una chiave di
lettura ogni qual volta si fa un tentativo
>Beh, se devi criptare un file di 10 Mega, tipo un Database o delle
immagini, a
>che dimensione arrivi? E, ripeto, considera che il tuo algoritmo usato in
questo
>modo, dà la possibilità al cracker di ottenere tutti gli output che vuole.
>Naturalmente farà dei tentativi mirati, guarderà cosa cambia criptando una
>stringa di uno, dieci, cento diecimila caratteri, magari tutti chr$(0) o
tutte A
>o tutte sequenze di ABCDEFG. Controllerà la differenza che passa fra la
>criptazione di "A" e di "B", e di "ABC" e BCD", e via dicendo...
beh in quell'esempio si doveva decriptare solo una stringa di 20
caratteri..... quindi espandere il tutto a 6k non era poi così male. Sempre
in quell'esempio i caratteri superflui creati ad hoc per scoraggiare il
decriptante sono assolutamente Random..... quindi se inserisci A una prima
volta e poi ancora una seconda volta troverai due stringhe di 6000 caratteri
con ovviamente tante lettere ripetute di qua e di la. Mettiamo anche il caso
che il 133° carattere sia sempre lo stesso e quindi che si ritenga possa
essere la nostra A... beh questo è un errore. Si può sempre randommizare la
posizione della stringa all'interno dei 6000 caratteri.
Insomma non credo basti un anno.
>Io ho elaborato un mio algoritmo, che ritengo abbastanza complesso, e ti
devo
>dire che ogni espediente che mi veniva in mente, aveva una qualche
possibilità
>di essere scoperto con la logica del confronto. Così sono arrivato a d una
>conclusione più o meno simile alla tua: incasinare il più possibile. Il che
>significa non rendere matematicamente sicura la decrittazione, ma (cercare
di)
>renderla economicamente sconveniente. E non è la stessa cosa...
magari se trovo un lasso di tempo da qui a quando me ne starà in barca a
pescare realizzo un programmino che crea algoritmi incasinati per
decriptare.... posso garantirti che già visivamente si ottengono buoni
risultati
ciao
Davide Greco
Nicola Pietralunga
(tipo blowfish) che garantisce un tempo di decrittazione non inferiore a
qualche migliaio di anni anche con i computer più potenti disponibili
attualmente, invece di stare ad inventarsi algoritmi che, finchè non
testati, non si sanno valutare sotto il profilo della inattaccabilità da
parte della criptanalisi.
Non so se mi sono spiegato. Mi stavo sconfondendo anch'io intanto che lo
scrivevo...
Ciao,
<--< Nik >-->
Per rispondermi in E-Mail togliere "deleteme" dall'indirizzo.
To reply me by E-Mail remove "deleteme" from my address.
Davide Greco ha scritto nel messaggio <7j311k$7mh$1...@nslave1.tin.it>...
Roal Zanazzi
> >> 3) A qualcuno interessa l'argomento tanto da aiutarmi con un paio di
> >> librerie che posseggo? Queste librerie sono scritte in C e la chiamata
> >> documentata per il C; io dovrei trovare il modo di adattarla al VB.
> >>
> >Potrebbe essere interessante (poi si puo' mettere sul Sito Comune).
> >Prova a postare le dichiarazioni in C.
>
> API del sistema di Hashing MD5 (per la firma digitale).
non
> so niente.
>
Avresti dovuto postare il file .H, che dovrebbe contenere anche le
dichiarazioni delle strutture e dei tipi...
Comunque, vediamo di iniziare da qui.
Ipotizzo che la DLL sia compilata a 32bit, quindi tutti gli int del C sono
Long di VB.
Non ho avuto molta cura nella traduzione dei parametri (d'altra parte in VB
non c'e' l'equivalente del costrutto typedef del C).
Segue un tentativo di traduzione.
--
Roal Zanazzi
z...@iol.it
' --------------------------------------------------------------
' API DES
' -------
Type des_key_schedule
' ??? la dichiarazione del record dovrebbe essere in un file .H
End Type
' int FAR PASCAL des_key_sched(des_cblock FAR *key, des_key_schedule FAR
*sched)
Declare Function des_key_sched Lib "des.dll" (ByRef key() As Byte, _
ByRef sched As des_key_schedule) As Long
' int FAR PASCAL des_ecb_encrypt(des_cblock FAR *input,
' des_cblock FAR *output,
' des_key_schedule FAR *ks,
' int encrypt)
Declare Function des_ecb_encrypt Lib "des.dll" (ByRef inputt() As Byte, _
ByRef output() As Byte, _
ByRef ks As des_key_schedule, _
encrypt As Long) As Long
'NB l'ultimo parametro (encrypt) potrebbe essere anche definito di tipo
Boolean.
' Example
' -------
' To encrypt an 8 byte block, you may have a program fragment like this:
'
' void encrypt_block(BYTE *block,BYTE *key)
' {
' des_key_schedule ks;
'
' des_key_sched(&key,&ks);
' des_ecb_encrypt(&block,&block,1);
' }
'
Sub encrypt_block(block() As Byte, key() As Byte)
Dim ks As des_key_schedule
Call des_key_sched(key, ks)
Call des_ecb_encrypt(block, block, 1)
End Sub
'> -----------------------------------------------------------
'> API IDEA
'> --------
'>
'> VOID FAR PASCAL ExpandUserKey(LPWORD userKey,LPWORD key)
'> userKey FAR pointer to 16 byte IDEA key
'> key FAR pointer to 104 byte buffer that is to hold the expanded key
Declare Sub ExpandUserKey Lib "idea.dll" (userKey() As Byte, ByRef key() As
Byte)
'> VOID FAR PASCAL InvertIdeaKey(LPWORD key,LPWORD invKey)
'> key FAR pointer to full 832 bit encryption key
'> invKey FAR pointer to an 832 bit buffer to receive the decryption key
Declare Sub InvertIdeaKey Lib "idea.dll" (key() As Byte, ByRef invKey() As
Byte)
'> VOID FAR PASCAL Idea(LPWORD dataIn,LPWORD dataOut,LPWORD key)
'> dataIn FAR pointer to an 8 byte buffer to encrypt/decrypt
'> dataOut FAR pointer to an 8 byte buffer to receive the results of the
'> encryption/decryption
'> key FAR pointer to the full 832 bit encryption/decryption key
'>
Declare Sub Idea Lib "idea.dll" (dataIn() As Byte, ByRef dataOut() As Byte,
key() As Byte)
'> ----------------------------------------------------------
'> API MD5
'> -------
'>
'> VOID FAR PASCAL MD5(LPBYTE data,int bytes,LPBYTE hash)
'> data FAR pointer to the information to hash
'> bytes number of bytes pointed to by `data'. Must be <=32767.
'> hash FAR pointer to a a buffer to receive the 128 bit (16 byte) hash
Declare Sub MD5 Lib "md5.dll" (data() As Byte, bytes As Integer, ByRef
hash() As Byte)
'> VOID FAR PASCAL MD5Init(VOID)
Declare Sub MD5Init Lib "md5.dll" ()
'> VOID FAR PASCAL MD5Update(LPBYTE inBuf,WORD inLen)
'> inBuf FAR pointer to buffer containing information to add to current
hash
'> inLen Number of bytes in `inBuf'. Note inLen must be <=64K
Declare Sub MD5Update Lib "md5.dll" (inBuf() As Byte, inLen As Integer)
'> VOID FAR PASCAL MD5Final(VOID)
Declare Sub MD5Final Lib "md5.dll" ()
'> VOID FAR PASCAL MD5GetHash(LPBYTE hash)
'> hash FAR pointer to a 16 byte buffer that is to receive the hash
Declare Sub MD5GetHash Lib "md5.dll" (ByRef hash() As Byte)
Davide Greco
però ad occhio e croce direi che se qualcuno ha inventato sto sistema avrà
inventato anche un contro-blowfish...
ciao
Davide
Roal Zanazzi
> non conosco blowfish...
> però ad occhio e croce direi che se qualcuno ha inventato sto sistema avrà
> inventato anche un contro-blowfish...
>
Qualsiasi (e dico qualsiasi) algoritmo di crypting ideato finora e'
attaccabile.
Il problema e': quanto tempo ci vuole per decriptarlo?
E qui sta la forza di un algoritmo di crypting:
NON l'impossibilita' assoluta di fregarlo,
MA la maggiore difficolta' computazionale necessaria per fregarlo.
E' questo il motivo per cui si usano chiavi di crypting sempre piu' lunghe
(128bits, ad esempio), semplicemente perche' piu' lunghe sono piu' aumentano
esponenzialmente le probabilita', e quindi i tentativi necessari per
l'attacco brute-force.
--
Roal Zanazzi
z...@iol.it