search for: metzdowd

There were a few notes in this thread that may indicate open areas for development. I forward merely as FYI. http://www.metzdowd.com/pipermail/cryptography/2015-January/024231.html ---------- Forwarded message ---------- From: Peter Gutmann <pgut001 at cs.auckland.ac.nz> Date: Sun, Jan 4, 2015 at 9:29 PM Subject: Re: [Cryptography] Why aren?t we using SSH for everything? To: calestyo at scientia.net, pgut001 at cs.auc...

...vendors and people with more inclination to argue on mailing lists than write good software (cf. the sftp process). -d On Mon, 5 Jan 2015, grarpamp wrote: > There were a few notes in this thread that may indicate open areas for > development. I forward merely as FYI. > > http://www.metzdowd.com/pipermail/cryptography/2015-January/024231.htm > l > > ---------- Forwarded message ---------- > From: Peter Gutmann <pgut001 at cs.auckland.ac.nz> > Date: Sun, Jan 4, 2015 at 9:29 PM > Subject: Re: [Cryptography] Why aren?t we using SSH for everything? > To: calesty...

...d maybe be don in addition. Especially since the main idea behind the attack is obviously not limited to the initial authentication phase when a password is entered and characters would be sent one-by-one... but applicable more generally to any interactive sessions. Cheers, Chris. [0] http://www.metzdowd.com/pipermail/cryptography/2015-January/024284.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/2015010...

...topic for Dovecot list, but I might think instead about separate > inbound and outbound MTAs to achieve containment of inbound MTA > compromise. > > Robert (and Harald), thanks, > > Ron > > [1] Among very many threads, on GCC bug 30475, in April this year: > http://www.metzdowd.com/pipermail/cryptography/2014-April/021074.html Hi Ron, Firstly these questions mostly relate to MTA configuration and are hence probably on the wrong list now; however: I second Reindl's views here. The issues you describe as vulnerabilities all stem from bad configuration. Run Postfix...

...ed by the cryptographic community. Another option would be to try to generate our own curve. However, I have no idea what pitfalls there are when doing that. If any of you have well informed suggestions to make about elliptic curves, please let me know. I'm subscribed to the randombit.net and metzdowd.com cryptography mailing lists, so anything you hear there you don't have to repeat. I would certainly switch curves if the new one is not less suspect than the secp curves, and if it allows at least a few ECDH or ECDSA operations per second on low-powered devices. By the way, if you are runnin...

...ed by the cryptographic community. Another option would be to try to generate our own curve. However, I have no idea what pitfalls there are when doing that. If any of you have well informed suggestions to make about elliptic curves, please let me know. I'm subscribed to the randombit.net and metzdowd.com cryptography mailing lists, so anything you hear there you don't have to repeat. I would certainly switch curves if the new one is not less suspect than the secp curves, and if it allows at least a few ECDH or ECDSA operations per second on low-powered devices. By the way, if you are runnin...

For the encryption functionality in the ZFS filesystem we use AES in CCM or GCM mode at the block level to provide confidentiality and authentication. There is also a SHA256 checksum per block (of the ciphertext) that forms a Merkle tree of all the blocks in the pool. Note that I have to store the full IV in the block. A block here is a ZFS block which is any power of two from 512 bytes to