Newsgroup: it.comp.sicurezza.crittografia
Titolo: Codifica B64 e rapporto lunghezze

Qual è il rapporto tra la lunghezza 
di un array di byte e la lunghezza 
della sua rappresentazione B64?
Ad intuito dovrebbe essere 6/8 cioè
3/4. Ma poichè l'intuito mi tradisce
sempre, chiedo a voi del ng.
Grazie.
GianpieroP
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Ad intuito dovrebbe essere 6/8 cioč 3/4.
...e cosě č.
A parte un pelino di overhead, ma quello fa piů parte dei vari "armor"
usati da GPG e soci che nno del base64 "in sé" che non credo richieda
obbligatoriamente caratteri di fine riga o CRC di fine messaggio (come
invece gli armor di PGP richiedono).
- --
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 /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAkBYqMgACgkQaJiCLMjyUvtDOQCeKrOpubz1ZRNCpzhMX1G0QgFu
J5wAoKaXZzqURtQfTvTOG65IsSHGdPH0
=80gn
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
| > Ad intuito dovrebbe essere 6/8 cioč 3/4.
|
| ...e cosě č.
[cut]
Grazie per la preziosa conferma.
Sempre il discorso dell'hashing con sale ripetuto
(sembra una ricetta di cucina).
Oggi parlando con un collega sull'argomento,
mi ha consigliato di salvare il sale e l'hash
in campi blob del db. A me piace piů la
codifica b64 e salvare in un campo varchar
(ecco il motivo del calcolo della lunghezza).
Voi che ne pensate?
(potrebbe essere argomento OT, ma mi fido
molto della vostra opinione (speriamo che il
mio collega non legga quanto ho scritto!) )
GianpieroP in attesa di confronto... o
di espulsione dal ng
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
iQA/AwUBQFjecJ4sPKh9SaicEQKI1gCfVuodb8+uRAtwH3zi/cLdK2gHthUAoJ2B
07CQzML0+VJxuhrsjzwHxkxB
=v5pR
-----END PGP SIGNATURE-----

 (ecco il motivo del calcolo della lunghezza).
Concordo col tuo collega, perché sprecare il 33% dello spazio e in più
aver bisogno di CPU per convertire e de-convertire?
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 /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAkBY7/QACgkQaJiCLMjyUvsHlQCfTBoOnxy6KdLp0gwaI7Bdf/zq
pAsAoNAosR49sHjYQJ2svnMU9TSXI2h7
=tBIT
-----END PGP SIGNATURE-----

 ha scritto nel messaggio
news:c3ar4t$2594eu$1...@ID-187835.news.uni-berlin.de...
| Concordo col tuo collega, perché sprecare il 33% dello spazio e in
| più aver bisogno di CPU per convertire e de-convertire?
Allora io concordo con tutti e due per il problema dello spazio
occupato.
Tuttavia dissento da quello dell'efficienza computazionale:
ma non eri proprio tu che mi consigliavi l'algoritmo proposto da
"Schneier & Ferguson" che suggeriva di hashare più volte per
allungare il tempo di calcolo dell'hash ;-) ?
Cmq ho già scritto nel documento che useremo un campo blob,
e campo blob sia!
Ciao,
GianpieroP
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
iQA/AwUBQFn0254sPKh9SaicEQKtnACeOO4BhFMOPLfIICCkPwi8j9xZ84QAn3jH
UjWbLAKfR1Q+4HuGGMcddZMK
=G/Gk
-----END PGP SIGNATURE-----

 e campo blob sia!
;)
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 /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAkBaOiYACgkQaJiCLMjyUvvOlQCg0STNNMkVKeQ2fNSjv4d4jZLq
0d4AnA4TDVpi/IfN+LOPYPvqMw5QRTZg
=a1RN
-----END PGP SIGNATURE-----