Newsgroup: it.comp.sicurezza.crittografia
Titolo: [x-post&f/up] Le FAQ...

  [X.509 available]
Linux Reg. User: #263663 / Machine: #216144 (ArchLinux /Wombat)
On the Web: 
http://www.quagliata.eu.org
 - My GPG Key:0x5539D8E4
On ICQ: 48618109 - On Jabber: 
qu...@jabber.org/@jabber.linux.it

crittare e crittato, assieme alle varianti criptare e criptato sono senz'
altro corretti,
Seppur vero, il gruppo "pt" non č naturale nella lingua italiana. Esistendo
"cifrare" e "cifrato" (perfettamente italiani) non mi farei scrupoli ad
usare questi ultimi due.
Spero di averti dato almeno un piccolo aiuto.
Cristiano

 Cristiano
Piccolo? :)
Grazie.
Saluti,
Federico


 Qualche matematico che esponga meglio il concetto?
un gruppo è un insieme non vuoto dotato di un'operazione binaria che 
goda delle seguenti proprietà:
-l'insieme è chiuso,
-l'operazione è associativa,
-l'operazione possiede un elemento neutro (dentro l'insieme)
-ogni elemento non nullo ammette un elemento inverso.
ps. per scrupolo aggiungo che non sono (ancora) matematico.
sto studiando per esserlo. così per scaramanzia più che altro. :-)

 -l'insieme è chiuso,
in effetti manca "rispetto all'operazione" o qualcosa che esprima questo.
potrebbe, altrimenti, sembrare una nozione topologica o (forse anche) altro.

dissident wrote:

Piu` che "spiegato" (mi sono espresso male),  avrei dovuto dire 
"inserito"... La tua spiegazione si riferisce (giustamente) solo al 
concetto di gruppo, invece serve qualcosa che al limite lo accenni soltanto.
Tradotto. Come chiariresti quanto segue?
| Ottengo maggiore sicurezza cifrando più volte lo stesso testo in chiaro?
|
| Generalmente no. Cifrare un testo con lo stesso cifrario due volte,
| anche con due chiavi diverse, non sempre rende il tempo di “cracking”
| piu` lungo. Infatti in alcuni casi, non servirebbe trovare la chiave c1
| e la c2, ma solo la terza chiave “risultante” (che “vale” cioè come la
| decifrazione prima con c2 e poi con c1).
|
| Dato un cifrario C e un messaggio M, C(C(M,c1),c2) non e` quindi due
| volte piu` sicuro:
|
| * Se C e le chiavi non formano un gruppo, la doppia cifratura e` sicura
| almeno quanto C(M) (ma comporta piu` dispendio di risorse: due chiavi da
| memorizzare, piu` cicli di CPU); in pratica non esiste la terza chiave
| “risultante”.
| * Se non formano un gruppo solo raramente allora per alcuni casi puo’ la
| terza chiave puo’ non esistere.
| * Se formano un gruppo esiste la chiave c3, tale che
| C(M,c3)=C(C(M,c1),c2) per ogni c1, c2.
|
| Se (ottimisticamente parlando) la supercifratura portasse ad avere un
| crittogramma notevolmente piu` sicuro si dovrebbe combattere con la
| maggior dimensione del messaggio, potenza di calcolo, nonchè sicurezza
| richiesta per amministrare l’intero processo.
Inizialmente mi pareva abbastanza chiaro. Ma evidentemente non lo e` poi 
cosi` tanto. <g>
Saluti,
Federico
PS: E non è nemmeno detto che il ragionamento sia del tutto esatto!!!


 sto studiando per esserlo. così per scaramanzia più che altro. :-)
:D


 Piccolo? :)
Nemmeno piccolo!? Allora piccolissimo! :-)
Cristiano

 Cristiano


 preferibile in quanto standard?
La tabella sě, ma dire che l'AES č preferibile no (ovviamente secondo me).
Certamente non vedo motivi per cui non usare l'AES, ma il Serpent č una
roccia, finché qualcuno non lo cracca... :-)
Cristiano

 sto studiando per esserlo. così per scaramanzia più che altro. :-)
Mi raccomando: diventalo! :-)
Qui serve un matematico puro.
Cristiano

 Certo che applicare queste proprietà al ragionamento di Quaqo... :-)
E` appunto questo il problema che non riesco a risolvere. :)
Davo per scontato la conoscenza del significato di "gruppo" in 
matematica da parte del "lettore"...
Ma la spiegazione si basa su un ragionamento in parte matematico, quindi...


 roccia, finché qualcuno non lo cracca... :-)
Anche AES lo è finché non lo si cracca 0=)
E questo XSL ancora non sa bene nesusno quanto e come funzioni eheh ;-)
Battute a parte, io eviterei la tabella, imho porta solo a confusione e
a una "gara di esponenti".
Forse direi che uno qualsiasi dei finalisti AES va bene, il resto è a
gusto personale e che Schneier consiglia "non puoi essere licenziato per
aver comprato IBM" ;-)
...capisco perfettamente il punto di vista di Cristiano, ma in una FAQ
deve esserci anche una A "univoca" oltre a una Q, per quanto questa A
sia "sminuente e riduttiva".
Un punto di una FAQ serve, imho, per chi non ha voglia di approfondire,
serve sopratutto come "primo abbozzo" di risposta. Ovviamente nessuna
rispsota è MAI psosibile a nesusna domanda se la domanda stessa non è
ben specificata nel dettaglio, e una domanda in una FAQ non può che
essere stra-generica, no? 0=)
Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkHfInMACgkQaJiCLMjyUvuZrQCgoXwKKZ4/Z0wCIlIBaju5tEny
NugAnjTRPupQyiiWPz5ADSbO+HlNelap
=VEVi
-----END PGP SIGNATURE-----

 Ma la spiegazione si basa su un ragionamento in parte matematico, quindi...
Ma il nocciolo di tutta la questione č davvero corretto?
Voglio dire "probabilmente no" mi pare eccessivo, credo che epr un
algoritmo serio valga il "probabilmente sě".
Esistono molte piů "permutazioni" casuali di 128 bit in 128 bit che non
le 2^128 possibili chiavi da 128 bit, no?
(vero č, comunque, che perfino in fase "finale" di standardizzaizone AES
si č deciso di *NON* aumentare i round di Rijndael, perché altrimenti
diventava qualcosa di diverso "e non abbastanza studiato", quindi forse
anceh i "grandi" vogliono confermarci che non sembre č bene aumentarli;
o forse semplicemente il margine gli pareva "sufficiente" e non volevano
"rallentare" lo standard, mah)
Io forse cambierei tutto il discorso e direi: oggi 128 bit sono
sufficenti a garantirsi che il cifrario quello NON č l'anello debole.
Quindi piuttosto che farvi seghe mentali ad applicare 1000 algoritmi a
catena andate al sodo ed analizzate il RESTO DEL SISTEMA =P
(da edulcorare, ovviamente, da edulcorare... ^^)
  Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkHfIXwACgkQaJiCLMjyUvt4xwCfdBJzj87DsIDFDjS0A2uyGMpe
BEYAn05BIHOmzbHCkwLI9CELDi8PqI31
=LoqF
-----END PGP SIGNATURE-----

 catena andate al sodo ed analizzate il RESTO DEL SISTEMA =P
Esattamente quello che volevo spiegare io... L'aggiunta del discorso dei 
vari casi mi sembrava interessante se ben fatta (apposta chiedevo aiuto).
Ma si puo' sempre tagliare e scrivere qualcosa sulla falsa riga della 
tua risposta che ho appena citato. :)


 Qui serve un matematico puro.
Ci tengo pure io. :-)

 ho chiesto sono perchè sto preparando un esame, non per far le scale :-))
Ok. Io aspetto qui. :P
In bocca al lupo per l'esame!!!


 "rallentare" lo standard, mah)
credo sia una questione di performance. il bando lo richiedeva.

> C(M,c3)=C(C(M,c1),c2) per ogni c1, c2.
Cifrare più volte un messaggio con la stessa chiave asimmetrica è evidente
che non porta alcun vantaggio in quanto ottieni sempre un numero dello
stesso gruppo ciclico modulo N (N dipende dal sistema di cifratura) e un
numero è sempre un numero, uno vale l'altro.
Se le due chiavi asimmetriche sono diverse ma appertengono sempre allo
stesso gruppo credo che il concetto sia lo stesso.
Cristiano

 In bocca al lupo per l'esame!!!
il `crepi!' è d'obbligo.

 Cristiano
Saluti,
Federico


 sicurezza, anzi al limite può anche diminuirla.
Io comunque nella fAQ eviterei tutti i "tecnicismi" (peraltro
interessantissimi, almeno per me =P) in cui stiamo finendo, una FAQ deve
essere a un "livello" motlo più base.
Propongo una frase del tipo: "dato che cifrare due volte rischia
addirittura di diminuire la sicurezza anziché aumentarla, è bene
scegliere un buon algoritmi e usare solo quello".
In questo modo non si danno "probabilità" né al fatto che possa
aumentarla né al fatto che psosa diminuirla, semplicemente "tout-court"
si consiglia di non farlo.
Che ne dite?
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkHhCkcACgkQaJiCLMjyUvtAywCgtqHQxRq7bXGvDiXbunrQagAg
2aEAnj8kqdMz0YicNh+efJ3phwcCeGgT
=t/K+
-----END PGP SIGNATURE-----

 credo sia una questione di performance. il bando lo richiedeva.
Sì ma aggiungere un paio di round non la cambiava in modo "drastico",
eppure non l'hanno fatto comunque. (e alla fine la "forza in più" di
Serpent è proprio "un paio di round", no?)
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkHhCaQACgkQaJiCLMjyUvt/BQCfWB/LLR840eh15GB/6q3rlbLC
gSAAoKpP1BtbquyusUpYpDwlbD/wG2Pu
=1Wf2
-----END PGP SIGNATURE-----

 Che ne dite?
Probabilmente hai ragione. Voto a favore.
(Ma vorrei comunque continuare la discussione, magari in un nuovo thread).


 di c1 e c2, la terza chiave puo' non esistere."
Ma non credo che sia applicabile ai comuni block cipher.
Se proprio vuoi metterlo, io scriverei:
"Se C, c1 e c2 formano un gruppo, per alcune combinazioni di c1 e c2 la
terza chiave, occasionalmente, potrebbe non esistere.".
Cristiano

 terza chiave, occasionalmente, potrebbe non esistere.".
scusate la pedanteria, ma per definizione, se formano un gruppo la terza 
chiave esiste. se non formano un gruppo, potrebbe esistere in qualche 
(forutito) caso.


Nessuna pedanteria; hai, invece, fatto bene a dirlo.
Io stavo soltanto riscrivendo la frase di quaqo in un modo che a me sembrava
più chiaro, non è che la stessi confermando.
Cristiano