Re: [cryptography] Quality of HAVEGE algorithm for entropy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! coderman wrote: On Tue, Nov 26, 2013 at 10:09 AM, Joachim Strömbergson joac...@strombergson.com wrote: ... I have concerns though on embedded SSL stacks that use Havege as entropy source on MCUs such as AVR32 and ARM. ... On an x86-based server you can use Havege, but use it to feed /dev/random, not as a RNG directly. The same goes for Jytter. good points! haveged should work fine on StrongArm, A8, A9, Xscale, anything with a high res timer like ARM Cycle Counter (in place of TSC). older ARM processors and x86 without high res TSC (pre-pentium?) will have trouble. Note that Havege is based on the assumption that instruction execution time varies and can be forced to vary as much as possible. On single-issue, RISC architectures with no or simple (such as SW controlled) cache memories you basically will have to hit main store in order to get a lot of variance. Then you also need a cycle timer, high res timer to be able to measure the variance. Another thing to note is that RDTSC is one of the instructions that VM-systems can (and will) simulate. This means that the source for Havege entropy will be synthetic and arbitrary from physical event. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKXBlIACgkQZoPr8HT30QEqcwCfS1Ux5rhm5QBHbnqr2gThKoTy x7AAoIw4AKhWBNLUMJSEDlD0KHsLjxC+ =Vm3Q -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email is unsecurable
Il 11/27/13, 10:01 PM, Jeffrey Walton ha scritto: The problem with DANE is the lack of DNSSEC. If we had both [...] When I refer to DANE, I also mean that DNSSEC must be there. We're getting there. Isn't the key distribution problem being pushed into DNS? The underlying problem still exists. To fix massive interception, that's passive, we do not need authenticated encryption. We just need to have a widely used and diffused opportunistic encryption with unauthenticated TLS on SMTP-to-SMTP communications. Authenticating keys with DNSSEC/DANE or TOFU, is imho a nice additional feature, but it's not required to fix the massive interception, that's passive. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Quality of HAVEGE algorithm for entropy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Stephan Mueller wrote: The only challenge that I see with Havege is that the algorithm is quite complex and that the description does not fully explain why and where the entropy comes from. Looking into the source code of oneiteration.h, the code is also not fully clear. Havege is (if I remember correctly) a magnificent example of Duff's Device: https://en.wikipedia.org/wiki/Duff's_device The code tries to force instruction cache misses at different points on the switch-loop thereby causing a lot of pipe flushes and instruction loads from lower level caches all the way to main store. A goof comparison to Havege is Jytter that basically (AFAIK) is trying to get entropy from the same source (measuring variance in instruction timing). But Havege tries to force the creation of variance and can thus generate higher rate of entropy. In my measurements I get kbps from Jytter byt Mbps from Havege. I have yet to compare the quality as measured using Dieharder, but from my memory Havege was really good. Considering the grilling I get with a similar RNG that I ask to be used as a seed source for /dev/random or other crypto libs (see thread http://lkml.org/lkml/2013/10/11/582), I would have concerns on the algorithm. As long as one does not rely on one source - and _always_ feed the entropy to the RNG-CSPRNG chain (not replace the chain and connect the source directly to /dev/random output like with Bull Mountain) I have a hard time to see where much controversy would emerge. As long as the source produces ok quality entropy. One issue I'm thinking of is if you have more than one source, but one of them dwafs the other sources in kapacity. Say having a microphone providing whitish noise at kbps rate and then having RdRand from your Haswell CPU generating data at Gbps speed, will the microphone entropy matter? - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKXCPMACgkQZoPr8HT30QHYugCgrtEwLV33ZS20PSvb/kvR8Fuq RgEAn1obSaBl/7V/IUqFMBk49bSeU1I/ =VCJ1 -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Quality of HAVEGE algorithm for entropy?
Am Donnerstag, 28. November 2013, 10:01:06 schrieb Joachim Strömbergson: Hi Joachim, Aloha! coderman wrote: On Tue, Nov 26, 2013 at 10:09 AM, Joachim Strömbergson joac...@strombergson.com wrote: ... I have concerns though on embedded SSL stacks that use Havege as entropy source on MCUs such as AVR32 and ARM. ... On an x86-based server you can use Havege, but use it to feed /dev/random, not as a RNG directly. The same goes for Jytter. good points! haveged should work fine on StrongArm, A8, A9, Xscale, anything with a high res timer like ARM Cycle Counter (in place of TSC). older ARM processors and x86 without high res TSC (pre-pentium?) will have trouble. Note that Havege is based on the assumption that instruction execution time varies and can be forced to vary as much as possible. On single-issue, RISC architectures with no or simple (such as SW controlled) cache memories you basically will have to hit main store in order to get a lot of variance. Then you also need a cycle timer, high res timer to be able to measure the variance. I am doing a lot of research in this area these days. If you imply that main storage means RAM outside the caches, I think your statement is not entirely correct. As a background: I have implemented a test that checks for variances in the execution time of instructions to support my RNG implementation provided in [1]. That test runs on bare metal, i.e. without any operating system (as otherwise the test results are impacted by the OS operation). To do that, I use memtest86 and replaced the existing tests with my own code. That code now executes without any OS like interruption (no scheduling, no interrupts). From the first rounds of testing, I think I see the following: - execution variations exist in any case unless the state of the CPU is flushed with serialization instructions (like CPUID) -- assuming that you also disable speedstep, power management and the like (I assume that the SMM code produces variations). - after flushing the CPU state, any code that runs inside the CPU shows no variations (even when the caches are flushed). Eg. the code of cpuid, rdtsc, rdtsc produces zero variations - after flushing the CPU state, but executing a couple of instructions which access memory (a fixed destination of memory), variations start to occur (it is something like 5 iterations of mov/movsl instructions are required -- below that threshold, no variations) == caches do kick in here which means that the variations do NOT solely depend on direct memory access, but it seems you have to hit L2 for seeing variations - disabling the caches completely introduces massive variations - flushing the CPU pipeline using MFENCE does not change any variation readings == My current hunch is that the differences in the clock speeds that drive the CPU versus the clock speed driving the memory locations that you access (either for instruction or data fetches) are the key driver of variations. But more testing is needed. Another thing to note is that RDTSC is one of the instructions that VM-systems can (and will) simulate. This means that the source for Havege entropy will be synthetic and arbitrary from physical event. I do not concur here, because even IF the VM host does some RDTSC emulation, the emulation code is subject to the fundamental jitter problem outlined above. Hence, I do not think that the jitter can be eliminated by virtualization. [1] http://www.chronox.de Ciao Stephan -- | Cui bono? | ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Quality of HAVEGE algorithm for entropy?
Am Donnerstag, 28. November 2013, 10:12:19 schrieb Joachim Strömbergson: Hi Joachim, Aloha! Stephan Mueller wrote: The only challenge that I see with Havege is that the algorithm is quite complex and that the description does not fully explain why and where the entropy comes from. Looking into the source code of oneiteration.h, the code is also not fully clear. Havege is (if I remember correctly) a magnificent example of Duff's Device: https://en.wikipedia.org/wiki/Duff's_device The code tries to force instruction cache misses at different points on the switch-loop thereby causing a lot of pipe flushes and instruction loads from lower level caches all the way to main store. A goof comparison to Havege is Jytter that basically (AFAIK) is trying to get entropy from the same source (measuring variance in instruction timing). But Havege tries to force the creation of variance and can thus generate higher rate of entropy. In my measurements I get kbps from Jytter byt Mbps from Havege. I have yet to compare the quality as measured using Dieharder, but from my memory Havege was really good. The problem is that dieharder Co only show the statistical quality. Based on my real-world attempts to the CPU jitter issue used as a noise source for /dev/random, the questions around the entropy of the data still remains -- see the email threat on LKML. Considering the grilling I get with a similar RNG that I ask to be used as a seed source for /dev/random or other crypto libs (see thread http://lkml.org/lkml/2013/10/11/582), I would have concerns on the algorithm. As long as one does not rely on one source - and _always_ feed the entropy to the RNG-CSPRNG chain (not replace the chain and connect the source directly to /dev/random output like with Bull Mountain) I have a hard time to see where much controversy would emerge. As long as the source produces ok quality entropy. Then please chime in on the LKML discussion in my support :-D One issue I'm thinking of is if you have more than one source, but one of them dwafs the other sources in kapacity. Say having a microphone providing whitish noise at kbps rate and then having RdRand from your Haswell CPU generating data at Gbps speed, will the microphone entropy matter? You are absolutely on spot. The key difference with a CPU jitter noise source vs the other noise sources in /dev/random is that the jitter is an on-demand production of entropy whereas the others are generated during the operation of the OS. That means, if you are not careful, the on-demand generation can easily outpace all other noise sources. That is why my current patch set only uses the jitter noise source as last resort, i.e. when /dev/random is about to block. As long as the other noise sources produce entropy, my jitter noise source is not even asked. With that approach, however, /dev/random will never block any more on any system. Ciao Stephan -- | Cui bono? | ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Quality of HAVEGE algorithm for entropy?
Am Donnerstag, 28. November 2013, 10:19:08 schrieb Joachim Strömbergson: Hi Joachim, Aloha! Stephan Mueller wrote: I would not concur with this statment: at runtime, you cannot verify entropy beyond simple pattern checks. Moreover, compression (i.e. whitening) is not meaningful when mixing it into /dev/random as it has its own whitening function. What I have argumented for is to have sanity checks on the sources to at least capture pathological cases. Things like stuck at zero/one. Then one could add simpler tests to detect major bias and values spanning much less than the value space. In this case, I fully concur that such tests are feasible and desireable. Ciao Stephan -- | Cui bono? | ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ntru-crypto - Open Source NTRU Public Key Cryptography Algorithm and Reference Code
Have you considered a patent licence that applies to all open source software, similar to Rogaway's OCB License 1? http://www.cs.ucdavis.edu/~rogaway/ocb/license1.pdf It has a clause that the whole software needs to be open source, not just the library, so it's similar to GPL in that regard. But it enables use in a wider range of open source software which doesn't use GPL. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Quality of HAVEGE algorithm for entropy?
On 28.11.2013 10:29, Stephan Mueller wrote: That is why my current patch set only uses the jitter noise source as last resort, i.e. when /dev/random is about to block. As long as the other noise sources produce entropy, my jitter noise source is not even asked. That sounds as if the jitter noise should be incorporated as a noise source into rngd. If it is available from userspace at least. rngd has the approach to feed the entropy pool if it falls below a certain watermark to avoid dominating the pool. regards, Jonas ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Entropy improvement: haveged + rngd together?
Am Donnerstag, 28. November 2013, 15:36:59 schrieb Fabio Pietrosanti: Hi Fabio, Greetings, following the answer on thread on the HAVEGE algorithm as an additional entropy source, at GlobaLeaks Project we are evaluating whenever not to add also rngd that's said to be able to use other hardware entropy source chipset ( Intel/AMD/VIA), available on the motherboard (Target OS: Linux) I'd like to ask a couple of questions: - Will haveged and rngd works well together in additionally feeding the entropy pool, or they will conflict somehow? They will not conflict as they use an IOCTL on /dev/random for injecting data. The code behind the IOCTL is able to handle even concurrent injections. So, multiple gatherers are ok. Though, bear in mind that you may not want inject entropy from one noise source via multiple paths. E.g. the Intel RDRAND instruction IS picked up by /dev/random and should therefore not used by rngd. - Isn't Linux Kernel already using the internal cryptographic chip on it's own, if available? Hardly. Intel RDRAND is currently the only chip used in /dev/random. Even though, the use is very limited (the output of /dev/random is XORed with an equally sized string from RDRAND). Any other hardware RNGs have drivers -- drivers/char/hw_random/* -- but they export their interface only to user space via /dev/hw_random. This interface is automatically sourced by rngd and injected into /dev/random. So, you see that these hardware RNGs can only be used via user space, even though kernel drivers make them available. The GlobaLeaks target is to avoid requiring any additional hardware to maintain the deployment process simple and the technical requirements cheap, so we're not focusing on external entropy source. That entropy improvement is going to be used for the already existing PGP operations done on files. Ciao Stephan -- | Cui bono? | ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] does the mixer pull or do the collectors push?
On 28/11/13 12:12 PM, Joachim Strömbergson wrote: One issue I'm thinking of is if you have more than one source, but one of them dwafs the other sources in kapacity. Say having a microphone providing whitish noise at kbps rate and then having RdRand from your Haswell CPU generating data at Gbps speed, will the microphone entropy matter? I'm thinking about the same issues, we're designing a classical RNG along the lines of three elements: collector \ \ collector - mixer --- expansion function/CSPRNG / collector / Here is my list of assumptions: /* * Assumption A:some of our collectors are borked. *A.2: we don't know which collectors are borked. *A.3: We do not rely on measurements of entropy * because a borked collector will deliver * false estimates. * Assumption B:Some of our collectors have very high * throughput, others very low. * Assumption B.2: Some are high quality, others are low quality. * Assumption C:At least one collector is good. * Assumption D:Core java, plus/minus Android. * * * Goal 1. Each collector should contribute to any request for a seed. * Goal 2. No blocking. Or minimal blocking... */ Our current thoughts are along the question of how the collector and mixer interface. Do the collectors push to the mixer or does the mixer pull from the collectors? Right now we're looking at a hybrid design of both: Collectors collect and save, and push into a mixer pool on their own when full. When the EF/CSPRNG pulls a seed from the mixer, it pulls from collectors, pulls from the pool, and mixes all that for the seed. Thoughts? iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] does the mixer pull or do the collectors push?
Power management is an issue. Therefore entropy collection cannot be periodic, not with high frequency anyways. Instead collection must happen as needed and/or opportunistically, and as much entropy should be collected as possible without increasing latency by too much. Opportunistic collection is fine, but opportunistic pushing into the mixer when there's no demand for CSPRNG outputs... is not power management friendly. Therefore: - for initial CSPRNG seeding the question is irrelevant: whether push or pull, we must wait until we have enough entropy from all the sources at hand; (since we're blocking and there may/should be multiple sources, some of which may involve slow I/O, async/concurrent polling is necessary so as to wait no longer than we must wait for the slowest source) - for opportunistic (but not periodic, at least not with short periods) mixing-in of new seeds, mixers should use consume entropy from all pools that have available entropy, without discriminating as to origin (since, after all, we're positing a properly-seeded CSPRNG). Remember, we started this long set of long threads because of a paper about /dev/urandom robustness. The assumption is partial compromise, and the goal is to recover (i.e., cause the attacker's knowledge of CSPRNG state to become stale) quickly. Suspend/resume, buses that allow external device-initated DMA to all physical memory, ... these are potential sources of partial compromise. Anytime there's a suspend event the system should encrypt sensitive state (e.g., filesystem keys, CSPRNG state), and decrypt it on resume. Since the encryption key in that case is likely to be a password-derived (i.e., weak) key, or it may be missing altogether (the user doesn't want to bother), CSPRNG reseeding on resume is... highly desirable. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] For hard of hearing, any ideas, hints, tips, pointers about how to get decrypted free the .sgstn StenoGraph StenoNote Stenographic Record of Public Meetings of Boston City Council?... o
For hard of hearing, any ideas, hints, tips, pointers about how to get decrypted free the .sgstn StenoGraph StenoNote Stenographic Record of Public Meetings of Boston City Council?... only .sgstn is available, not plain English text ! Example files. Scroll down at https://www.muckrock.com/foi/boston-3/full-plain-english-stenograph-record-last-city-council-public-meeting-6955/ _ _ _ _ _ COPY _ _ _ _ _ Pursuant to the Massachusetts Public Records Law, M.G.L. c.66, §10, I hereby request the following records for hard of hearing: Full plain English text Stenographic Record for hard of hearing of the last Public Meeting and 16 October 2013 to date Public Meetings of Boston City Council http://www.cityofboston.gov/contact/?id=138 including any and all accompanying materials, documents, files, computer files for example files with the following extensions .sgcap .ptf .rtf .xmptf .cv .txt .sgcvn .htm .html .sgngl .pdf .doc .docx .docm et al, any and all computer files related to stenographic records for hard of hearing. Please note Article 2.3 Contract for Stenographic Services Form CM11 City Of Boston Standard Contract General Conditions Article 2 -- Performance: 2.3 City is entitled to ownership and possession of all deliverables purchased or developed with Contract funds. All work papers, reports, questionnaires and other written materials prepared or collected by the Contractor in the course of completing the work to be performed under this Contract shall at all times be the exclusive property of the City. https://muckrock.s3.amazonaws.com/foia_files/fritch_37966_1.pdf I also request that, if appropriate, fees be waived as we believe this request is in the public interest, as suggested but not stipulated by the recommendations of the Massachusetts Supervisor of Public Records. The requested documents will be made available to the general public free of charge as part of the public information service at MuckRock.com, processed by a representative of the news media/press and is made in the process of news gathering and not for commercial usage. I expect the request to be filled in an accessible format, including for screen readers, which provide text-to-speech for persons unable to read print. Files that are not accessible to screen readers include, for example, .pdf image files as well as physical documents. In the event that fees cannot be waived, I would be grateful if you would inform me of the total charges in advance of fulfilling my request. I would prefer the request filled electronically, by e-mail attachment if available or CD-ROM if not. Thank you in advance for your anticipated cooperation in this matter. I look forward to receiving your response to this request within 10 business days, as the statute requires., https://www.muckrock.com/foi/boston-3/full-plain-english-stenograph-record-last-city-council-public-meeting-6955/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
