Update pt.text

1 files changed, 28 insertions, 28 deletions

diff --git a/pages/features/cryptography/pt.text b/pages/features/cryptography/pt.text
index a511522..fe14c62 100644
--- a/pages/features/cryptography/pt.text
+++ b/pages/features/cryptography/pt.text
@@ -21,65 +21,65 @@ Temos três planos para futuramente superar esses problemas potenciais:
 
 # Também planejamos incluir com o Bitmask um filtro de _bloom_ das 10.000 senhas mais comumente usadas. Segundo algumas pesquisas, 98,8% de todos os usuários escolhem uma senha entre essas 10.000. Um filtro de _bloom_ é relativamente pequeno e podemos simplesmente proibir que o usuário selecione qualquer uma dessas senhas (embora com alguns falso positivos).
 
-# Allow providers to forbid authentication via the web application. Authentication would happen via the Bitmask app, which would then load the website with the session token it obtained. This way, the critical SRP authentication code is never loaded from the provider.
+# Permitir que os provedores proibam autenticação via aplicação web. A autenticação deveria acontecer pelo aplicativo do Bitmask que, em seguida, carregaria o website com um token de seção obtido. Desta forma, o código crítico de autenticação da SRS nunca é carregado do provedor.
 
-For more information, see:
+Para mais informações, ver:
 
 * http://srp.stanford.edu
 * https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
 * https://xato.net/passwords/more-top-worst-passwords
 
-h2. Transport - TLS
+h2. Transporte - TLS
 
-The Bitmask client frequently makes various connections using TLS to the provider. For example, to check to see if there is an update to the list of VPN gateways.
+O cliente Bitmask frequentemente realiza várias conexões com o provedor usando TLS. Por exemplo, para verificar se existe uma atualização da lista de gateways de VPN.
 
-When a service provider is first added by Bitmask, the CA certificate from the provider is downloaded via a normal TLS connection authenticated using existing x.509 CA system. This is the only moment that Bitmask relies on the CA system.
+Quando um provedor de serviço é adicionado pelo BItmask, o certificado CA é baixado do provedor por uma conexão TLS comum autenticada usando o sistema x.509 CA existente. Este é o único momento em que o Bitmask depende do sistema de CA.
 
-All subsequent connections with that provider use the provider-specific CA to authenticate the TLS connection. Essentially, this is a form of certificate pinning and TOFU. In order for an outside attacker to impersonate a provider, they would need to present a false x.509 server certificate authenticated by a Certificate Authority, and then intercept and rewrite all subsequent traffic between the Bitmask client and provider.
+Todas as conexões subsequentes com aquele provedor usam o CA específico do provedor para autenticar a conexão TLS. Essencialmente, esta é uma forma de _pinning certificate_ e TOFU. Para que um atacante personifique um provedor, será preciso apresentar um certificado x.509 falso de servidor autenticado por uma Autoridade Certificadora, e assim interceptar e reescrever todo o tráfego subsequente entre o cliente Bitmask e o provedor.
 
-If a provider has been pre-seeded with the Bitmask application, then the fingerprint of the provider-specific CA certificate is known in advance. In these cases, the x.509 CA system is never relied upon.
+Se um provedor já foi sido semeado previamente (pre-seeded) com uma aplicação Bitmask, então a impressão digital do certificado CA específico do provedor já é conhecida de antemão. Nesses casos, o sistema CA x.509 nunca é invocado.
 
-The provider-specific CA certificates use 4096 bit RSA with SHA256 digest, by default. The server certificates use 4096 bit RSA with SHA256 digest, by default. These defaults are easily changed.
+Os certificados CA específicos de provedores usam RSA de 4096 bit com SHA256 digest, por padrão. Os certificados do servidor usamRSA de 4096 bit com SHA256 digest, por padrão. Estes padrões podem ser alterados facilmente.
 
-All TLS connections use PFS ciphers.
+Todas as conexões TLS usan cifras PFS.
 
-h2. Storage - Soledad
+h2. Armazenamento - Soledad
 
-The Bitmask application stores its data in [[Soledad => https://leap.se/soledad]], which handles encrypting this data, securely backing it up, and synchronizing it among a user's devices. In Soledad, local storage uses symmetric block encryption of the entire database using a single key. For data stored remotely, each individual document is separately encrypted using a key unique to that document.
+A aplicação Bitmask armazena seus próprios dados na [[Soledad => https://leap.se/soledad]], que lida com a encriptação desses dados, fazendo backups seguros, e sincroniza-os entre os dispositivos do usuário. Na Soledad, o armazenamento local utiliza bloco simétrico de encriptação de toda a base de dados usando uma única chave. Para os dados armazenados remotamente, cada documento é encriptado separadamente usando uma chave única para cada um deles.
 
-Both local storage and remote storage keys are derived from a master "storage secret." This long random storage secret is stored locally on disk, protected by symmetric encryption using a key derived from the user's password (scrypt is used as the key derivation function).
+Tanto as chaves do armazenamento local quanto as do remoto derivam de um "segredo de armazenamento" mestre. Este segredo longo e aleatório é armazenado localmente no disco, protegido por encriptação simétrica usando uma chave derivada da senha de usuário (scrypt é usado como função de derivação da chave).
 
-Currently, our scrypt parameters are:
+Atualmente, nossos parâmetros para o scrypt são:
 
-bc. N (CPU/memory cost parameter) = 2^14 = 16384
-p (paralelization parameter) = 1
-r (length of block mixed by SMix()) = 8
-dkLen (length of derived key) = 32 bytes = 256 bits
+bc. N (CPU/parâmetro de custo de memória) = 2^14 = 16384
+p (parâmetro de paralelização) = 1
+r (tamanho do bloco misturado pelo SMix()) = 8
+dkLen (tamanho da chave derivada) = 32 bytes = 256 bits
 
-We are considering using a larger N.
+Estamos vendo de usar um N maior.
 
-*Local storage*
+*Armazenamento local*
 
-p((. The block-encrypted local SQLite database uses @AES-256-CBC@ using the first 256 bits of [@storage_secret@]. See https://github.com/kalikaneko/python-u1dbcipher and http://sqlcipher.net.
+p((. A base de dados SQLite local encriptada em bloco usa @AES-256-CBC@ usando os primeiros 256 bits do [@segredo de armazenamento@]. Ver https://github.com/kalikaneko/python-u1dbcipher and http://sqlcipher.net.
 
-*Remote storage*
+*Armazenamento remoto*
 
-p((. Per-document encryption of documents stored remotely uses symmetric encryption with AES-256-CTR or XSalsa20 cipher using 256 bit keys. The library pycryptopp is used for this. The key and MAC used to encrypt each individual document are derived as follows:
+p((. A encriptação de cada documento no armazenamento remoto usa encriptação simétrica com AES-256-CTR ou cifra XSalsa20 usando chaves de 256 bit. Usamos a biblioteca pycryptopp para isso. A chave e o MAC usados para encriptar cada documento individualmente são derivados da seguinte forma:
 
 <pre style="margin-left: 2em">
-storage_secret_a = first 256 bits of storage secret
-storage_secret_b = everything after first 256 bits of storage secret
+storage_secret_a = primeiros 256 bits do segredo de armazenamento
+storage_secret_b = tudo que venha depois dos primeiros 256 bits do segredo de armazenamento
 document_key = hmac(document_id, storage_secret_b)
 document_mac = hmac(document_id | document_revision | iv | ciphertext, hmac(document_id, storage_secret_a)
 </pre>
 
-p((. Every document has its own key. The [@document_revision@] in the document MAC prevents a rollback to an old version of the document. HMAC uses SHA256.
+p((. Cada documento possui sua própria chave. A [@revisão do documento@] no MAC do documento previne a sobreposição de uma antiga versão sobre uma nova. HMAC usa SHA256.
 
-p((. Some documents in a user's remote data store are added by the provider, such as in the case of new incoming email. These documents use asymmetric encryption, with each document encrypted using the user's OpenPGP public key. The library we use for this is [[Isis's fork of python-gnupg => https://github.com/isislovecruft/python-gnupg]]. These documents are only temporarily stored this way: as soon as the client sees them, they get unencrypted and re-encrypted using the other methods.
+p((. Alguns documentos nos dados remotos de usuário são adicionados pelo provedor, tais como no caso de novos emails. Estes documentos usam encriptação assimétrica, sendo cada documento encriptado usando a chave pública OpenPGP do usuário. Usamos a biblioteca derivada do python-gnupg [[Isis => https://github.com/isislovecruft/python-gnupg]] para isso. Esses documentos são armazenados apenas temporariamente dessa forma: assim que o cliente os tiver visto, eles são desencriptados e re-encriptados usando os outros métodos.
 
-*Transport*
+*Transporte*
 
-p((. TLS, as above. Soon to be CurveZMQ.
+p((. TLS, como acima. Em breve será com CurveZMQ.
 
 h2. Encrypted Tunnel - OpenVPN