Newsgroup: it.comp.os.linux.sys
Titolo: Eseguire comando all' arrivo di una mail

Ciao a tutti.
Ho la necessità di poter eseguire un determinato comando (con
parametri) su un server all' arrivo di una mail (opportunamente
formattata contente appunto i parametri)
.
Pensavo di utilizzare fetchmail o simili per scaricare la posta di un
determinato account...
Non ho nessun tipo di esperienza nell' invio / ricezione posta...
Secondo voi è fattibile?
Qualche dritta?
Grazie!

Alessandro ha scritto:

Mettila in | su /etc/mail/aliases o configura un transport di
postfix.


diciamo che è arabo... :-)
Io non ho record MX che puntano a quell' host... l' host dovra
prelevarsi a scadenze regoalari le nuove mail da un server POP3...
Puoi farmi un esempio in una configurazione di questo tipo qui?

 formattata contente appunto i parametri)
Guarda il thread di due giorni fa "come faccio fare ad una macchina qualcosa
di automatico?".
-- 
Massimo Bacilieri AKA Crononauta


ok ci do un occhiata

 prelevarsi a scadenze regoalari le nuove mail da un server POP3...
Puoi usare il parametro -m di fetchmail e impostare come comando uno script 
che analizzi il contenuto della mail ed esegua il comando.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.


Ok
devo orientarmi quindi su fetchmail per fare il controllo/esecuzione
di script comandati via mail?!

 di script comandati via mail?!
Dipende. Se la mail la ricevi via SMTP userai l'MTA, se la scarichi via pop3 
userai fetchmail.



ho configurato fetchmail per scaricare le mail da un account
gmail.com...
Come faccio però a dirgli di buttare le mail in un file al posto di
inoltrarle ad un altro utente?


Facebook: Massimo Bacilieri

 Facebook: Massimo Bacilieri
hehehe acrobatico e dir poco...
diciamo che il mio scopo sarebbe quello di processare il corpo della
mail attraverso uno script eseguito immediatamente dopo il fetch della
posta...
è per questo che chiedevo come poter salvare in un file...
per ora sto usando un pipe e greppone tipo
 watch -n 5 "fetchmail -d0 -v 
pop.gmail.com
 | grep SMTP
dove nel .fetchmailrc ho:

...
poll 
pop.gmail.com
 with proto POP3
user '
indiriz...@gmail.com
' there with password 'password'
options keep ssl sslfingerprint '44:A8:E9:2C:FB:A9:7E:
6D:F9:DB:F3:62:B2:9E:F1:A9'
sslcertck sslcertpath /etc/ssl/certs/
Facendo così effettivamente ottengo il corpo del messaggio...
C'è qualche soluzione più buona ma che non mi obblighi ad installare
postfix o altri MTA?

...
in realtà non uso il watch... ho usato watch solo per il test..

ho detto una cassata...
facendo così non vedo il contenuto del messaggio :-(((

...
fetchmail -d0 
pop.gmail.com
 --bsmtp -
così printa nello stdout il testo della mail...
fetchmail -d0 
pop.gmail.com
 --bsmtp - | grep qualcosa | grep
qaulcos'altro
mi permette di verificare se la mail è conforme per poter eseguire un
determinato comando...
può andare bene ?


Facebook: Massimo Bacilieri

 può andare bene ?
Ma ascolta... leggere quel cavolo di man e fare la cosa più semplice?
poll MIOSERVER with proto POP3 user UTENTE there with password PASSWORD
       mda "/usr/local/bin/mioscript.sh %F %T"


 Qualche dritta?
Oltre all'uso proprio di fetchmail, una possibilita`
e` usare il file .forward nella dir dell'utente
destinatario dell'email.
Questo file, oltre a definire un forward, appunto,
consente di mandare l'email in pipe ad un programma.
Questo per quanto riguarda l'esecuzione.
Una domanda e`: come fai ad evitare che qualcun'altro
mandi un email con dei comandi a suo piacimento?
bye,
-- 
piergiorgio


Facebook: Massimo Bacilieri

 dei comandi a suo piacimento?
La firma con gpg? ;-)


wrote:

L' idea è quella di generare un ID che viene inviato al mittente e che
ha una determinata validità...
es di flowchart:
mittente: chiedo di eseguire >shutdown -r<
script: ok , accetto la mail perche $mittente è nella lista dei
possibili esecutori
script: optional: (controllo se comando è in un elenco di comandi che
sono autorizzato ad eseguire.)
script: ti genero un $id_random e gli assegno una $id_validità di 600
secondi ad esempio.
script: notifico al $mittente che ho ricevuto un comando e che se
vuole che venga eseguito
script: deve farmi pervenire in tempo (date +%s + $id_validità) una
seconda mail contenete l' $id_random.
mittente: invia una seconda mail con <$id_random>
script: cavolo, mi è arrivata un' altra mail da $mittente prima della
scadenza di $id_validità e contiene l' $id_random che ho generato
prima
script: mi tocca eseguire il comando che avevo ricevuto in precedenza
script: e gli faccio sapere al mittente che sto per fare/ho fatto
quanto mi è stato chiesto.
Il tutto via pop3 over SSL.
può filare come ragionamento?

 Facebook: Massimo Bacilieri
diciamo che la mail che contiene il comando dovrà avere un determinato
formato
es.
<-<comando>->
quindi se ottengo sullo stout header+corpo grep "<-<" | grep ">->" sul
contenuto mi indica subito che potrebbe essere una mail contenente un
comando...

 comando...
Se vuoi farti del male, questa è una delle varie possibilità:
.fetchmailrc :
poll 
pop3.sarcazzo.it
...
mda '/usr/bin/procmail -d %T'
.procmailrc :
MAILDIR=$HOME/Mail
:0c
^Subject: ESEGUI
comandi_ricevuti
:0
^Subject: ESEGUI
| formail -I "" | awk '{ system($0);}'
In questo modo ogni volta che manderai una mail all'indirizzo scaricato con
subject "ESEGUI", quanto scriverai nel corpo della mail verrà eseguito come
fossero comandi, e ne conserverà una copia in $HOME/Mail/comandi_ricevuti.
Naturalmente coi permessi dell'utente che invoca fetchmail.
Ah, è chiaro che se vuoi dare dei comandi che abbiano un output, dovrai
gestire l'output da qualche parte (che so, potresti redirigerlo su un file
di appoggio e fartelo rimandare con mutt, a piacere).
Ovviamente dal punto di vista della sicurezza è una bestialità abnorme, però
se è quello che vuoi fare...



leggi 2 messaggi sopra il flowchart che ho in mente...
Detta come l' hai detta tu son d'accordo che è un pericolo, ma credo
che per come l' ho studiata possa garantire un po' di sicurezza..poi
magari mi è sfuggito qualcosa...

 magari mi è sfuggito qualcosa...
Per come l'hai studiata, IMHO faresti di gran lunga meglio a dare una
sessione ssh all'utente!



per questioni sempre di sicurezza o per praticità...?
il problema è che questo sistema dovrà raggiungere delle linux box
appese a dei pali (antenne) senza monitor ne tanto meno tastiera che
non potranno essere raggiungibili via ssh per via di router etc etc
che non gestirò...
Per questo volevo adottare questa soluzione...
Come potrei fare altrimenti, considerando che in uscita quella rete ha
solo pop, smtp, www e poco altro di aperto?

 solo pop, smtp, www e poco altro di aperto?
Piazzi su quelle box un bel sshd sulla porta 80!


 sessione ssh all'utente!
Ma per praticità o sicurezza questo?
Purtroppo sarà una linuxbox montata su di un palo e connessa via wifi
quindi non raggiungibile da niente e da nessuno fisicamente.
La rete wifi verso internet permette pochi protocolli in uscita tra i
quali smtp, pop3,smtps, pop3s,ftp, www e in entrata praticamente nulla
per via dei router/nat da me non gestiti.
per questo che pensavo a questa soluzione per scopi amministrativi,
chessò far ripartire un servizio per esempio...
Altre soluzioni purtroppo non riesco a vederne...

 per via dei router/nat da me non gestiti.
allora non hai bisogno di farti chissà che viaggi, quella del pipe in awk
che esegue i comandi della mail IMHO può andare bene, se si tu a dare i comandi.
Il fetchmail lo fai in pop3s, che fa un'autenticazione ssl, e a quel punto
se tu a tua volta invii la mail alla mbox "ponte" in smtps, e lui la scarica
in pop3s, tutta la comunicazione è crittografata, per cui non ci sono rischi
di intercettazione delle password. Non più di una normale sessione ssh almeno.
Tanto per sicurezza, puoi mettere nelle mail che invii tu come comando un
campo di controllo, che so un X-LocalCMD + una password che ti scegli, e che
che poi vai a testare subito con formail durante il controllo con procmail.
Se il campo X-LocalCMD non corrisponde, scarti la mail, in questo modo eviti
che delle mail "spazzatura" all'e-mail "ponte" possano far attivare chissà cosa.


 solo pop, smtp, www e poco altro di aperto?
Per esempio ti metti in casa un server openvpn che ascolta sulla 443/TCP e 
un demone openvpn su ogni endpoint che parla su quella porta. Funziona anche 
se hai di mezzo proxy (purché supportino il CONNECT).


 puň filare come ragionamento?
Direi proprio di no. Non offre alcuna sicurezza questo sistema, specie 
considerando che č tutto in chiaro su protocolli in chiaro senza alcun 
metodo di challenge/response.
E' come se uno urlasse in piazza la propria password e l'altro l'accettasse 
solo se la sente ripetere in entro 2 minuti


 se hai di mezzo proxy (purché supportino il CONNECT).
Ci potrebbe essere uno o più proxy prima di internet...
Altre soluzioni

 La firma con gpg? ;-)
Direi di si, e` l'unica soluzione.
Avendo cura di fare il key-exchange in modo _sicuro_,
cioe` non per connessione remota, ma andando sul posto.
bye,
-- 
piergiorgio

 Altre soluzioni
La soluzione corretta e` quella di whiplash.
Devi copiare, in modo sicuro, una chiave pubblica
(di una coppia privata/pubblica, ovviamente), sul
server remoto. Questo in modo *sicuro*, cioe` NON
tramite connessione al server via internet.
Ogni email deve essere firmata (pgp/gpg) con la
chiave privata e lo script, per prima cosa, deve
verificare la correttezza della firma.
bye,
-- 
piergiorgio

 di intercettazione delle password. Non più di una normale sessione ssh almeno.
E` un po' debole.
Per prima cosa *devi* essere sicuro che non ci sono
altri server smtp nel mezzo, secondo, sul server, la
posta giace in plain-text, con tutti i comandi e le
password varie.
Quindi questo funziona solo se entrambe sono valide:
1) c'e` un unico server nel mezzo
2) hai il controllo completo del server
bye,
-- 
piergiorgio

 verificare la correttezza della firma.
Casomai, il server deve avere un suo keypair privata/pubblica, chi manda la
mail deve averne un altro, e le chiavi possono [0] essere firmate tra loro.
Dopodiché il mittente cifra la mail con recipient il destinatario, e quello la
decifra.
[0] *possono*, perché per mandare mail cifrate non c'è bisogno che le chiavi
siano firmate. Però ovviamente, se firmi una chiave, sei sicuro dell'identità..
ma se è un server, e la chiave sul server magari la generi tu... ;)
Fila il mio ragionamento?
Ciao,
David
-- 
 . ''`.  Debian maintainer | 
http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- 
http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- 
http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

 Fila il mio ragionamento?
Eccessivo, a mio avviso.
A meno che non si voglia anche nascondere i comandi.
bye,
-- 
piergiorgio

 altri server smtp nel mezzo, 
Uhm hai ragione, non avevo pensato ai relay intermedi... in realtà
sarebbe risolvibile alla radice se il pop3s se lo mettesse su lui,
avendone la possibilità :-)
-- 
Massimo Bacilieri AKA Crononauta


 sicura, mentre non lo e` affatto.
Non ci siamo capiti, o forse non avevo capito io.
Tu parlavi di _firmare_ il messaggio da mandare, io di _criptarlo_ (o
crittografarlo, se preferisci).
Se lo firmi e basta, è un gioco da ragazzi: togli via la firma GPG (che è in
chiaro) e la rifirmi con una chiave tua.
Se il messaggio è crittato, dovresti anche avere il testo in chiaro, che NON
hai (a meno di keylogger o altre robe strane sull'host del mittente, ma questa
è fantascienza IMVHO), e non credo basterebbe neppure.
Il mio ragionamento fila se si parla di crittografare le mail, se è semplice
firma allora sì, basta scambiarsi la chiave pubblica in un modo sicuro.


 firma allora sì, basta scambiarsi la chiave pubblica in un modo sicuro.
Il problema, credo, fosse essere sicuri che l'email
contenente i comandi sia effettivamente mandata da
chi ha l'autorizzazione ad eseguire quei comandi.
Nel caso di email da proteggere, hai, penso, ragione.
bye,
-- 
piergiorgio

 avendone la possibilità :-)
O più semplicemente crittando la mail con gpg.
Critti il comando con la chiave pubblica dell'endpoint e con la chiave 
privata del master.
Solo l'endpoint può decrittarla e solo il master può averla spedita.
3 righe di script per invocare gpg.


 Solo l'endpoint può decrittarla e solo il master può averla spedita.
Beh, diciamo che anche questo e` un po' eccessivo.
Per prima cosa non serve una doppia crittograffazione,
basta una + firma (crittografata).
Secondo, l'endpoint, come gia` scritto, deve avere la
chiave privata non crittografata, per poter eseguire
lo script senza interazione utente.
Questo, a seconda dei casi, potrebbe essere un problema.
Se e` necessario solo essere sicuri del mittente, basta
la firma, se si vuole anche nascondere il messaggio, cioe`
la serie di comandi, allora bisogna essere sicuri che la
seconda chiave privata sia protetta in qualche modo.
bye,
-- 
piergiorgio

 seconda chiave privata sia protetta in qualche modo.
La sua privata è sul suo disco. Più protetta di così :)
Qui non si parla di mettere in piedi un sistema per l'NSA, ma solo di avere 
un sistema semplice per far eseguire comandi via mail ad un host remoto. La 
protezione dell'endpoint è ovviamente considerata implicita; non 
sussisterebbe il problema di pensare a come proteggere la comunicazione se 
l'endpoint non fosse protetto.
In ogni caso anche questo sistema non garantisce protezione da un attacco 
banale come il reply attack. Per tutelarsi anche da questo è necessario 
avere un qualche tipo di challenge-response oppure un sistema OTP come OPIE.


 OTP come OPIE.
Pensavo anche a qualcosa del genere.
bye,
-- 
piergiorgio

 in questo contesto? Thanks!
Sniffi la mail e la reinvii. A prescindere dal contenuto crittografato se 
non hai un sistema di challenge-response/OTP, l'endpoint riceverà una mail 
che ha la stessa validità della precedente e quindi rieseguirà la stessa 
operazione.
Per esempio se la mail richiedeva un reboot potresti forzare il reboot 
decine di volte semplicemente rimandando la stessa mail. Bisogna quindi che 
la mail cambi di volta in volta.


 che la mail cambi di volta in volta.
Ah! Infatti, mi girava per la testa una cosa del
genere, ma non ci ero arrivato direttamente.
Direi che la soluzione e` quella da te citata, cioe`
avere una lista di "codici" unici, condivisa, che
consenta di ottenere l'unicita` dei messaggi.
bye,
-- 
piergiorgio

 stessa operazione.
Interessante e giusta considerazione.
In realtà, potrebbe bastare qualcosa di più banale di un otp
per garantire la non replicabilità di un comando già inviato.
Pensavo a un campo index nella mail di comando, per cui il server
ricevente non esguirà più di una volta una mail con un certo indice.

 un testo correlato.
Quale sarebbe il testo correlato?


 Quale sarebbe il testo correlato?
Questo testo che stiamo scrivendo, per esempio.
bye,
-- 
piergiorgio

 serie di problemi correlati.
Questo si risolve facilmente con il padding. Poi come detto qui non siamo 
all'NSA, e una semplice chiave a 1024 bit è strasufficiente per gli scopi 
che ci si prefigge. Sarebbe anche sufficiente semplcemente un sistema di 
challenge-response senza crittografia dato che non penso debbano passare 
dati sensibili ma solo comandi.
Le minacce da cui tutelarsi in questo contesto sono secondo me solo tre, in 
ordine di importanza:
* protezione da reply attack
* autenticazione del master
* protezione del contenuto.


 * protezione del contenuto.
OK, su questo eravamo gia` daccordo...
bye,
-- 
piergiorgio

 AES-128.
Stai paragonando mele con pere. La lunghezza della chiave di un algoritmo 
simmetrico non ha alcuna relazione con quella di un algoritmo asimmetrico; 
sono proprio cose completamente scorrelate se non per il fatto che in 
entrambi i casi più lunga è, meglio è.
Una chiave RSA da 128 bit la scovi in poche ore con un PC. Una chiave di 
lunghezza analoga con AES ci metti qualche decina d'anni a trovarla. La 
stessa applicata a pene di segugio con RC4 nel WEP ci metti pochi minuti se 
hai abbastanza dati per poter applicare la crittanalisi.


 Una chiave RSA da 128 bit la scovi in poche ore con un PC.
http://www.rsa.com/rsalabs/node.asp?id=2091
:)


 nessuno che si possa applicare ad un testo sniffato in precedenza.
OK, possibile, ma, vedi, questo va precisato,
perche` dire che "solo brute force e` possibile"
non torna.
Immagino che tu possa aver ragione: probabilmente
in questo contesto l'unico attacco possibile e`
quello brute force. Da verificare, pero`... :-)
bye,
-- 
piergiorgio

 semplicemente un vuoto...
Sentite, bello il vostro "flame", ma interessante ed utile.
Che libro/i mi consigliate per imparare queste belle cose sulla 
crittografia?
Ciao,
ScriptJus 

 crittografia?
Applied cryptography di Schneier.
-- 
http://bofhskull.wordpress.com/

 Applied cryptography di Schneier.
Grazie mille.
L'amico di cui ti dicevo in un altro thread mesi fa č: Vazzoler.
Ti saluta dalla Cina.
Ciao,
ScriptJus 

 Applied cryptography di Schneier.
E per chi non sapesse chi Schneier e`:
http://geekz.co.uk/schneierfacts/
bye,
-- 
piergiorgio

 Ti saluta dalla Cina.
Andrea? Urcu.
Finito lontanuccio...
-- 
http://bofhskull.wordpress.com/

Scusate ma ormai per qualsiasi sito su cui uno si va a registrare il
metodo è quello del reply per la conferma...da ebay a qualsisasi
forum...
Non capisco perchè si sia finito a parlare di firme, cifratura,
etc...
Quello che non mi è chiaro: come ci si può sostiuire al destinatario
di una mail di conferma?

 di una mail di conferma?
Se posso intercettare il traffico tra l'endpoint ed Internet è un'operazione 
banale forgiare una mail di risposta.
Con mailsnarf + awk/perl/bash + sendmail lo fai anche in modo automatizzato 
in meno di 20 righe di codice.


 di una mail di conferma?
A questo proposito, io avrei un paio di amici
in Nigeria, con una cassa piena di dollari da
trasferire... uh... in luogo piu` "sicuro".
Potrei dargli la tua email, se sei interessato.
;-)
bye,
-- 
piergiorgio

Scusa la stessa registrazione su ebay funziona così...
Ho l' impressione che da una semplice domanda siamo arrivati a
discutere di sicurezza a livelli paranoici...
Mi ha fatto comunque piacere leggere le vostre opinioni sulla firma
perchè sono argomenti che purtroppo non conosco!
Però quello che non capisco è come uno script possa essere così
insicuro quando sulla rete esistono migliaia di servizi che adottano
all' incirca lo stesso metodo...
Comunque, visto che da una parte un pò di paura me l' avete messa...
...un altra idea che mi è venuta è quella di generare sempre un ID
numerico random, che può essere convalidato se dall' altra parte viene
eseguita un operazione matematica, che può essere semplicemente una
sottrazione oppure un algoritmo più complesso...
In questa maniera chi dovrà gestire questo sistema dovrà essere a
conoscenza dell' ID generato e dell' 'algoritmo' (passato a voce) da
applicare per la conferma...
Eviterei in questo modo di ricorrere alle firme (per praticità/
mobilità) e allo stesso tempo se qualcuno fosse nel mezzo a sniffare
il traffico non potrebbe/saprebbe cosa farsene di quell' ID...
giusto?

 sottrazione oppure un algoritmo più complesso...
Questo è appunto un challenge response :)
http://en.wikipedia.org/wiki/Challenge-response_authentication
Per esempio:
a) il master invia un messaggio con il comando ed un ID univoco (una stringa 
casuale di 8 byte)
b) lo slave risponde con un messaggio in cui riporta l'ID del comando ed un 
salt (una stringa casuale di 8 byte)
c) il master risponde con un messaggio in cui inserisce l'ID e l'md5 della 
concatenazione del salt del punto b) con una password preconcordata.
d) lo slave verifica la corrispondenza della password e se il messaggio di 
verifica è arrivato entro un tempo accettabile esegue il comando.
In perl sono 20 righe in tutto.


 il traffico non potrebbe/saprebbe cosa farsene di quell' ID...
Allora, lo scenario peggiore, ma non troppo improbabile, e`
qualcuno nel mezzo in grado di leggere e scrivere *tutti* i
dati/pacchetti/email/etc. in transito.
Non e` troppo improbabile perche` il tuo ISP e` gia` in grado
di fare cio`. Magari non l'ISP ufficialmente, ma qualcuno che
siede in sala macchine presso l'ISP stesso.
Se tu mandi un email al server, questa potrebbe essere letta,
modificata ed inoltrata successivamente al destinatario.
In aggiunta a questo, potrebbe essere valido non far sapere, a
chi sta nel mezzo, cosa il tuo server e` in grado di fare.
Quindi, mettiti nei panni del Man in the Middle, e prova a
vedere cosa riusciresti a fare, in funzione del protocollo
di sicurezza che hai scelto.
Una soluzione al problema e` avere due canali di comunicazione
indipendenti ed usare accorgimenti come "key-continuity" o PSK.
In questo scenario e` possible accorgersi di eventuali problemi.
Accorgersi solamente, non necessariamente risolverli od evitarli.
bye,
-- 
piergiorgio


wrote:

Se però lo script prosegue con l' esecuzione solo se riceve un id a
cui è applicato un algoritmo,un man on the middle dovrebbe anallizzare
un certo numero di mail per poter risalire a quale algorimo applico
sull 'ID. giusto?

 sull 'ID. giusto?
Più o meno: se l'algoritmo è scelto bene, anche analizzandone una 
sequenza lunga a piacere non è possibile prevedere l'ID successivo.
Si chiamano one-time-password.
Questo è un perfetto esempio del perchè -in pochi campi quanto nella 
crittografia- è bene studiare invece di reinventare la ruota rischiando 
di combinar cazzate ;-)
Suggerisco di nuovo lo Schneier: sono 60$ ben spesi (almeno, la mia 
copia costava così, ma ha i suoi anni...)
-- 
http://bofhskull.wordpress.com/

D'accordo sull' algoritmo... una semplice sottrazione sarebbe
banale...
Se se già eliminassi ad esempio la prima e l' ultima cifra per poi
elevare al quadrato quanto rimane.. sarebbe già un algoritmo credo
abbastanza difficile da decifrare..
Per quanto riguarda la crittografia introduce troppi problemi di
configurazione/utilizzo da parte delle persone che dovranno utilizzare
questo sistema...
So di certo che non è il metodo più sicuro, ma quel che voglio è
garantire un buon rapporto sicurezza/usabilità...

 questo sistema...
Questo dipende soltanto da come è implementata, non dalla complessità 
crittografica in sè.
L'utente inserisce una stringa. Non ha alcun significato, per lui, 
quanto complesso è il processo che ha portato alla generazione di quella 
stringa... E se usi algoritmi "affidabili" per generarla, hai anche 
complessità minori: proprio perchè sono affidabili, qualcuno, da qualche 
parte, li ha già implementati. Tutto lavoro che non devi fare tu.
Pensa ai token RSA (e famiglia): c'è gente che usa l'homebanking pur 
avendo difficoltà a fare una divisione...
-- 
http://bofhskull.wordpress.com/


Chiaro.
Ma io sinceramente ho al momento solo una gran confusione su quanto
detto fin'ora...
In parole povere (da niubbi) cosa dovrei fare per avere qualcosa di
sicuro, senza ricorrere a configurazioni lato client?

 garantire un buon rapporto sicurezza/usabilità...
Introdurre meccanismi come quello che hai esposto sopra ("eliminare la prima 
e l'ultima cifra per poi elevare al quadrato") servono per ridurre 
l'usabilità senza influire sulla sicurezza. Allora tanto vale fregarsene 
della sicurezza direttamente.


 e quel che oggi abbiamo è il frutto di decenni di studi matematici.
Infatti, qualcuno disse che ogni principiante, in
ambito crittografico, ha inventato un algoritmo che
lui riteneva inviolabile... Per poi essere "violato"
con sforzo minimale.
Perfettamente d'accordo: non pensare di inventare
nulla, ma studiare almeno il minimo necessario per
soddisfare i proprio requisiti di sicurezza.
bye,
-- 
piergiorgio


wrote:

Io credo che cmq un algoritmo perchè possa essere scoperto richiede, a
seconda della complessità, un certo numero di valori catturati.
Su una comunicazione in cui ogni secondo l' algoritmo è applicato 100
volte, posso capire che sia possibile ricondurlo a una formula
matematica, ma su un applicazione che potrà scambiare dati 'cifrati'
ad esagerare 1 volta a settimana la vedo dura anche per i migliori
rookies...

 rookies...
A meno che il tuo "avversario" non abbia letto
questi
  post... :-)
Il rischio e` che qualcuno venga a sapere del
trucco per altre vie, magari si trova con dei
sorgenti in mano, e prova ad usarlo.
Per questo conviene "chiedere" a chi ci ha gia`
sbattuto la testa, cosi` non rischi di sbatterla
anche tu allo stesso modo.
Il libro di Schneier che e` stato consigliato e`
un ottimo suggerimento, a mio avviso.
Anche perche` aiuta a scegliere il livello di
sicurezza in funzione della complessita` che
si vuole/puo` applicare.
bye,
-- 
piergiorgio

Mi avete convinto...
Presupponendo di utilizzare MD5 mi proponete un flowchart (da niubbio)
di quanto deve fare lo script e l' utente?
Ci voglio ragionare un pò su...
Questa potrebbe essermi un occasione per iniziare a capirne qualcosa
di più...

Che fate mi abbandonate ?! :-)

 Che fate mi abbandonate ?! :-)
Leggi nel mio post precedente, ti ho spiegato per filo e per segno cosa devi 
fare.


 Che fate mi abbandonate ?! :-)
Oh, e dammi il tempo di leggere i newsgroup! :-)
Direi, oltre i consigli di Flavio, potresti dare
un occhiata alla man page di gpg e compagni.
Giusto per farti un'idea di come si possa firmare
e/o crittografare un file.
Dato che questo funziona anche in pipe, non dovrebbe
essere difficile tirarne fuori uno script.
bye,
-- 
piergiorgio

 verifica è arrivato entro un tempo accettabile esegue il comando.
es:
mittente:
- comando da eseguire
- ID:2F4C2134BD2A2F2C
server risponde:
- 2F4C2134BD2A2F2C+DE2315FDCB4D6B1A
Corretto?
Hai un sito in cui riesca a capirci qualcosa di +?
Cosa intendi per concatenazione del salt del punto b?!
il client a questo punto cosa deve fare?d

Alessandro wrote:
[...]
Magari si riferiva all'altro posto.
IMHO, particolarmente interessante il punto:
e) crittografi e firmi con un sistema a chiave privata/pubblica
Dato che quasi tutto o tutto e` disponibile
gia` pronto e preparato.
bye,
-- 
piergiorgio

 Cosa intendi per concatenazione del salt del punto b?!
Parti dal presupposto che se non usi la crittografia a chiave pubblica ci 
deve essere un segreto condiviso che è una password.
##########################
# 3-way handshaking ;-)
##########################
Allora il master (chi comanda) manda allo slave (chi esegue) la mail con
- comando da eseguire
- ID: <codice casuale>
Lo slave manda al master una mail con:
- ID: <codice di cui sopra>
- X: <codice casuale>
Il master prende l'ID, lo concatena a X, e concatena una password nota ad 
entrambi i nodi. Quindi manda l'MD5 della concatenazione
- ID: <codice di cui sopra>
- Y: md5( $ID + $X + $PASSWORD)
Lo slave controlla che i dati corrispondano a quelli in suo possesso e se 
corrispondono esegue.
In bash in modo che possano essere concatenati si può fare come da files 
allegati (sono scritti alla benemeglio, ovviamente sono solo un esempio)
Puoi vedere il risultato concatenando in questo modo:
./master1 pippopluto | ./slave1 | ./master2 | ./slave2
Postano a video del debug per vedere quel che accade ad ogni passaggio.
Più di così non posso :-)


 - Show quoted text -
Che dire, grazie per la disponibilità.
Ora devo capirne qualcosa di più per mio conto, ma mi hai dato un'
ottima base su cui riflettere...
Ci sentiremo presto su queste pagine :-)
Grazie ancora

 Ci sentiremo presto su queste pagine
Pagine?
Quali pagine? :-)
/me che proprio trova non fruibili i newsgroup via web.


Con google groups non sono poì così male...

 Con google groups non sono poě cosě male...
Punti di vista. Personalmente di Google Groups mi piaceva il fatto che
ti mostrava i thread piu` attivi, ma da quando hanno tolto quella
possibilita` (senza considerare che tronca i subject) lo uso solo se devo
Enrico