Abbiamo già parlato in un altro articolo dell'architettura della crittografia nel linguaggio Java.
Oggi proponiamo un esempio di come poter ottenere un Message Digest da un  testo in chiaro.



import java.io.UnsupportedEncodingException;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.logging.Level;
import java.util.logging.Logger;

public class Main {

    public static void main(String[] args) {

        try {
            byte[] testoChiaro = "This is a test!".getBytes("UTF8");
            MessageDigest md = MessageDigest.getInstance("MD5");
            //visualizzo il provider utilizzato
            System.out.println("Provider:\n"+md.getProvider().getInfo());
            //cifro il messaggio
            md.update(testoChiaro);
            System.out.println("Message Digest:\n" + new String(md.digest(), "UTF8"));
        } catch (NoSuchAlgorithmException ex) {
            Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
        } catch (UnsupportedEncodingException ex) {
            Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
        }

    }
}

JCA-Java Criptography Architecture

Abbiamo già parlato di crittografia per quanto riguarda il linguaggio Java.
Ora parleremo di JCA, il framework di base per la crittografia, è costruito intorno alla J2SA(Java 2 Security Architecture).
Si basa sui principi della Criptography Service Provider Architecture:

• indipendenza dell'implementazione(Algorithm indipendences)
• interoperabilità
• estendibilità

L'indipendenza dell'implementazione o Algorithm indipendences utilizza classi astratte di tipo "engines" che dichiarono le funzionalità di un dato tipo di algoritmo crittografico, impiega poi classi "provider" che implementano un certo insieme di funzionalità crittografiche per un Criptographic Service Provider(CSP).

In genere un'applicazione crittografica può richiedere genericamente un'implementazione di un dato algoritmo senza curarsi di quale provider lo fornisca, infatti una volta installati possono coesistere uno o più CSP anche di differenti produttori, il provider di default si chiama SUN ed è integrato nel JDK.
In Pratica:

• Engine class: definiscea crypto service in an absract class senza implementazione
• Service provider interface: provvede ad una crypto interface dell'applicazione via "engine"

Cryptographic service provider: ogni classe "engine" ha una corrispondente SPI che definisce esattamente un crypto method implementato da CSP. 

Principali engine class:

• KEY: defisce le funzionalità condivise da chivi "opache"
• KEY SPEC:definisce una chiave di tipo trasparente
• KeyFactory:prende una chiave di tipo KEY "opaca" o "trasparente"
• KeyPairGenerator:genera una coppia di chiavi assimentriche
• AlgorithmParameters: gestisce i parametri di un algoritmo
• AlgorithmParametersGenerator:genera i set di parametri di un algoritmo
• MessageDigest:calcola l'hash di dati specifici
• SecureRandom:genera numeri causali o pseudo casuali
• Signature:appone e verifica la firma digitale
• CertificateFactory:crea e revoca certificati di chiavi pubbliche
• KeyStore:crea e gestisce un database(Keystore) di chiavi e certificati sicuri.

Il provider SUN include:un'implementazione dell'algoritmo DSA (Digital Signature Algorithm), un algoritmo MD5 e SHA-1 di MessageDigest, un KeyPairGenerator per DSA, AlgorithmParameter ed AlgorithmParameterGenerator per DSA, un KeyFactory per DSA, un CertificateFactory  per certificati X.509 e per CRLs, un'implementazione del KeyStore proprietario JKS.

Le estensioni JCE(Java Cryptographic Extension) e JSSE(Java Secure Sockects extension) implementano ed estendono le tecniche  crittografiche definite dalla JCA fornendo CSP alternativi a SUN.
Invece i restanti set di package offrono funzionalità di sicurezza aggiuntive e sono quindi complementari alla JCA.

• JAAS:servizi di autenticazione, amministrazione e autorizzazione
• CertPath:gestione dei certificati e catene di certificati
• JGSS:meccanismi di comunicazione generici e specifici per beyberos v5

JCE

Java Cryptographic Extension

La JCE ha il compito di fornire  un'implementazione completa delle funzionalità di cifratura e decifratura dichiarate dalla JCA.
JCE offre supporto:

• cifrari simmetrici a blocco e a flusso
• cifrari asimmetrici
• cifrari con password

applicazioni su:

• Data
• I/O streams
• Serializable Object

in meccanismi quali:

• MAC(Message Authentication Code)
• KeyGenerator/KeyAgreement

JCA-Message Digest

Java Criptography Architecture offre la classe "engine" MessageDigest astratta che provvede a fare da design per offrire la funzionalità di cifratura di messaggi sicuri con algoritmo SHA-1 o MD5, questo messaggio criptato è detto: Message Digest o semplicemente indicato con MD.

Un message digest è un messaggio in chiaro di lunghezza variabile tradotto in un messaggio "sicuro" di lunghezza fissa.

Un MD ha due proprietà:

1. se x->h(x), e y ed x sono diversi, non si può avere h(y)=h(x)
2. non si possono avere collisioni 

Ad esempio in Internet è utilizzato MD5-128 bit che non garantisce nulla per quanto riguarda la collisione.
Le API Java sono:

• MessageDigest.getInstance("MD5")  per ottenere un MD
• .update(plaintext) per calcolare MD con il testo in chiaro
• .digest() per leggere il message digest

JCA-Message Authentication Code(MAC)

MACs usa una chiave per preservare l'integrità del messaggio.JCA supporta gli algoritmi:

• HMAC/SHA-1
• HMAC/MD5

Le API Java sono:

• KeyGenerator.getInstance("HMACMD5") e .generateKey() per generare la chiave
• Mac.getInstance("HMACMD5") crea un oggetto MAC
• .init(plaintext) e .doFinal() inizializza un MAC object
• .update(plaintext) e .doFinal() calcolano il MAC object con testo in chiaro