<div dir="ltr">Ah, yes. That would do it.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 6, 2017 at 4:25 PM Ivan Lazar Miljenovic <<a href="mailto:ivan.miljenovic@gmail.com">ivan.miljenovic@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 7 July 2017 at 09:04, Rein Henrichs <<a href="mailto:rein.henrichs@gmail.com" target="_blank">rein.henrichs@gmail.com</a>> wrote:<br>
> I'm also not sure what benefit you would get from rolling your own versus<br>
> using AWS's server-side S3 bucket encryption[1], now that I think about it.<br>
><br>
> [1]<br>
> <a href="http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html" rel="noreferrer" target="_blank">http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html</a><br>
<br>
Due to regulatory requirements, we can't rely upon that and need to<br>
ensure we never put any private data in AWS that even someone with<br>
login access to AWS can read.<br>
<br>
><br>
> On Thu, Jul 6, 2017 at 3:56 PM Rein Henrichs <<a href="mailto:rein.henrichs@gmail.com" target="_blank">rein.henrichs@gmail.com</a>><br>
> wrote:<br>
>><br>
>> If you are not a security expert, I would strongly recommend against<br>
>> rolling your own encryption scheme. If you are a security expert, you would<br>
>> probably not be asking us for advice on how to roll your own encryption<br>
>> scheme. I would suggest that you find something off the rack that might meet<br>
>> your needs (whether it's written in Haskell or not) and make sure you<br>
>> understand how it works and what your threat model is well enough to decide<br>
>> whether it does, in fact, meet your needs.<br>
>><br>
>> On Thu, Jul 6, 2017 at 3:29 PM Ivan Lazar Miljenovic<br>
>> <<a href="mailto:ivan.miljenovic@gmail.com" target="_blank">ivan.miljenovic@gmail.com</a>> wrote:<br>
>>><br>
>>> On 7 July 2017 at 01:44, Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org" target="_blank">ietf-dane@dukhovni.org</a>> wrote:<br>
>>> ><br>
>>> >> On Jul 6, 2017, at 12:58 AM, Ivan Lazar Miljenovic<br>
>>> >> <<a href="mailto:ivan.miljenovic@gmail.com" target="_blank">ivan.miljenovic@gmail.com</a>> wrote:<br>
>>> >><br>
>>> >> I have a use case for needing to use public key cryptography to<br>
>>> >> encrypt a large amount of data in a streaming fashion (get it out of a<br>
>>> >> DB, encrypt, put into an AWS S3 bucket).<br>
>>> ><br>
>>> > What are the data-format requirements?  Do you need (binary) CMS<br>
>>> > output?<br>
>>> > GPG-compatible output?  Or just roll your own?<br>
>>><br>
>>> The intent is to be able to transfer data between two parties such<br>
>>> that only the recipient is able to view it (hence the usage of public<br>
>>> key cryptography).  GPG/PGP compatability is preferable as it's<br>
>>> common, but anything that is sufficiently standardised (as this will<br>
>>> potentially be used by others that aren't me doing so with Haskell and<br>
>>> thus can't just use a library to do so) will suffice.<br>
>>><br>
>>> (The other advantage of GPG/PGP is that the security testing team is<br>
>>> more familiar with it and thus likely to sign off on it.)<br>
>>><br>
>>> ><br>
>>> > Integrity protection can be tricky with large data streams.  Most data<br>
>>> > formats for enveloped data have a single MAC at the end, which means<br>
>>> > that the decoder has to consume all the data before it is known to be<br>
>>> > valid!<br>
>>> ><br>
>>> > So if you're in a position to avoid a standard all-in-one format, it<br>
>>> > makes sense to "packetize" the stream, with integrity protection for<br>
>>> > each "packet", and packet sequence numbers to preserve overall stream<br>
>>> > integrity.  With vast amounts of data, you'll want to be careful with<br>
>>> > the symmetric cipher modes, AEAD (AES-GCM, for example) protects only<br>
>>> > a limited amount of data before you need to rekey.  It may be simplest<br>
>>> > to just generate a new symmetric key for every N megabytes of data.<br>
>>> ><br>
>>> > With a careful design of the "packet" format, you can use in-memory<br>
>>> > crypto for each packet.  Don't forget to include an "end-of-stream"<br>
>>> > packet to defeat truncation attacks.<br>
>>><br>
>>> This sounds good in theory, but in practice I'm not versed enough in<br>
>>> security to want to try and roll my own if I could avoid it, and<br>
>>> trying to document such a format for others to use could be<br>
>>> problematic.allowed to post.<br>
>>><br>
>>> --<br>
>>> Ivan Lazar Miljenovic<br>
>>> <a href="mailto:Ivan.Miljenovic@gmail.com" target="_blank">Ivan.Miljenovic@gmail.com</a><br>
>>> <a href="http://IvanMiljenovic.wordpress.com" rel="noreferrer" target="_blank">http://IvanMiljenovic.wordpress.com</a><br>
>>> _______________________________________________<br>
>>> Haskell-Cafe mailing list<br>
>>> To (un)subscribe, modify options or view archives go to:<br>
>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
>>> Only members subscribed via the mailman list are allowed to post.<br>
<br>
<br>
<br>
--<br>
Ivan Lazar Miljenovic<br>
<a href="mailto:Ivan.Miljenovic@gmail.com" target="_blank">Ivan.Miljenovic@gmail.com</a><br>
<a href="http://IvanMiljenovic.wordpress.com" rel="noreferrer" target="_blank">http://IvanMiljenovic.wordpress.com</a><br>
</blockquote></div>