Posso sviluppare strumenti basati su SSH negli Stati Uniti?

6

È risaputo che lo sviluppo di strumenti di crittografia open source è molto problematico negli Stati Uniti: tutti i software basati su ssh open source sono stati sviluppati specificamente al di fuori degli Stati Uniti di A a causa delle restrizioni all'esportazione USA.

link

Mentre si trova negli Stati Uniti, cosa succede se volessi riutilizzare un codice ssh con licenza MIT, come da OpenSSH, Dropbear o PuTTY, e scrivere alcune funzionalità su di esso, e pubblicare i risultati come open-source sotto una licenza simile a quella con cui ho acquisito il codice originale?

Non sono una persona matematica, quindi i miei contributi SSH saranno probabilmente costituiti solo da parti di integrazione di livello profondo: ad esempio, creando vari tipi di client di trasferimento file basati su ssh.

Sto aprendo la porta per essere potenzialmente perseguito in un procedimento penale per violazioni dell'esportazione negli Stati Uniti?

    
posta cnst 29.12.2012 - 22:43
fonte

3 risposte

9

La maggior parte delle forti restrizioni alle esportazioni criptate sono state eliminate, ma non tutte. Ad esempio, non puoi vendere a "Stati canaglia" o organizzazioni terroristiche.

Wikipedia: esportazione di crittografia negli Stati Uniti

Come sempre, però, consulta un avvocato, non Internet, per quanto riguarda la consulenza legale.

    
risposta data 30.12.2012 - 01:22
fonte
1

Un trucco spesso usato dai gruppi statunitensi che vogliono fare uso di una capacità di crittografia è spesso un modo di caricare separatamente questa capacità. Costruisci la tua applicazione in modo tale da non essere distribuita usando il codice sorgente cripto e fornisci istruzioni aggiuntive su come ottenere il codice sorgente preferito dal creatore e costruirlo / collegarlo al codice che stai fornendo.

Funziona fin tanto che non stai modificando le librerie, ma solo costruendole sopra.

Il chilometraggio varia in base al linguaggio di sviluppo e ai tecnici esperti degli utenti.

È anche bello in quanto impone un certo livello di astrazione - se hai solo una superficie suface limitata per le API che non vuoi esportare, significa anche che hai solo un affidamento limitato su di esse, e potrebbe fare di più facilmente aggiornarli o cambiarli se in seguito dovessi trovare qualcos'altro che ti piace di più.

    
risposta data 31.12.2012 - 18:44
fonte
0

Penso che finché nessun codice di crittografia reale viene ripubblicato insieme ai nuovi strumenti basati su ssh, allora tali strumenti basati su ssh possono essere scritti negli Stati Uniti.

Direi che potrebbe limitare la possibilità di implementare effettivamente l'integrazione a livello più profondo tra i prodotti ssh esistenti e quelli per i quali si cerca l'integrazione ssh: ad esempio, fare un client sftp potrebbe risultare un po 'complicato, a seconda di quanto sono state efficaci le astrazioni nel codice originale che è stato importato per essere hackerato.

Ma, fondamentalmente, pubblicare un set di patch solitario che faccia l'integrazione tra il codice basato su ssh esistente ei client del filesystem, dovrebbe, IMHO, essere una scommessa sicura da fare. Assicurati che nessuna implementazione ssh originale o alcuna funzione crittografica siano pubblicate insieme a tali patch.

    
risposta data 30.12.2012 - 02:00
fonte

Leggi altre domande sui tag