Re: [cryptography] Kernel space vs userspace RNG
The linux kernel also has a shared DMA buffer system which might be able to help with that latency, but that is a good point nonetheless. Latency could probably also be helped further by splitting that procedure into a collector and a processor/output function, to keep the overhead on DMA buffer usage to a minimum. It'd have to use a little more memory as the tradeoff, and preallocate that as much as possible to avoid losing that again on allocation, but that'd probably be acceptable in most cases if implemented relatively conservatively. On May 9, 2016 3:16:34 PM PDT, Russell Leidich <pke...@gmail.com> wrote: >"Interrupts don't need to be polled in a loop in the kernel, though. As >long as the interrupt handler being used to collect the data is quick >enough, it wouldn't necessarily need to be resource intensive. There >are >only going to be 15 or 24 interrupt lines on most x86 systems, anyway. >All >else being equal, such an interrupt handler in the kernel would >actually >probably hog less CPU cycles than it would in userspace just because it >doesn't need to poll at all for that information." > >Correct, interrupts do not require polling (except in weird >circumstances >not relevant here). The tight loop I was referring to is required to >extract randomness from DMA bursts to or from main memory by sampling >the >timedelta stream during said bursts. It's not really a polling loop >because >it's not waiting for anything to finish, but it creates a similar >latency >bottleneck because it must gather enough entropy before issuing an >output. >Nevertheless, doing so should be much faster than relying on interrupt >timing alone. In principle, the latency could be truncated by doing >little >bursts here and there in between userspace time slices. > >Before you say this is all crap... The timedelta stream (and more >simply, >its histogram) is quite informative. At one point, I was able to >determine >that I was browsing the internet just by using timedeltaprofile. On >further >investigation, I found that I could identify which website I was >looking at >using a sufficent number of timedelta samples. I could even tell _which >company_ I was reading about on a particular investment website, >probably >due to the characteristic differences in latency spikes between the >pages >in question. (I had to train myself on the histograms first, of course, >so >you couldn't use this as an attack if you knew nothing about the >website >being visited. It also required profiling during load, not after load.) >This was all done from an orthogonal userspace with no kernel access. >Spooky! Someone needs to virtualize userspace timestamp access before >this >becomes a problem, but I'm not holding my breath. I'm by no means the >first >person to discover this sort of thing, either. There are plenty of >similar >issues with Java or Javascript, for example. > > >-------- > >___ >cryptography mailing list >cryptography@randombit.net >http://lists.randombit.net/mailman/listinfo/cryptography -- Michael Greene Software Engineer mgre...@securityinnovation.com___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Kernel space vs userspace RNG
deltas across a process boundary to predict its output >to >any useful extent. Cache miss and timing attacks are useless, as is a >parallel instance of Enranda. If anyone can prove otherwise, it would >make >a very interesting read. > >The ideal physical random number generator, I think, would be an analog >computer of macroscopic size, like something soldered together inside a >clear case. That's the only way we could verify its functionality. I >would >never buy something labelled "random number generator" that comes in a >black box containing 10 nanometer features or whatever. Who knows how >that >would actually work under the hood. > > > > >___ >cryptography mailing list >cryptography@randombit.net >http://lists.randombit.net/mailman/listinfo/cryptography -- Michael Greene Software Engineer mgre...@securityinnovation.com___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Kernel space vs userspace RNG
One technical reason could be that at least some of the entropy sources are also in the kernel, so it makes some sense to put the RNG there, too. It'd probably be more implementation effort to be able use the same entropy sources in a userspace tool. Another justification could be that it is more difficult to modify kernel memory than it is to modify userspace memory, so it might be considered more trustworthy. On May 5, 2016 2:40:51 AM PDT, shawn wilson <ag4ve...@gmail.com> wrote: >Just reflecting on the Linux RNG thread a bit ago, is there any >technical >reason to have RNG in kernel space? There are things like haveged which >seem to work really well and putting or charging code in any kernel can >be >a bit of a battle (as it should be with code as complex as that >involving >crypto - wouldn't want people missing an exploit your new system >exposes >and accepting it*). So I wonder what the gain is for putting RNGs in >the >kernel. > >The only argument I can think of against this is non technical - if you >rely on users to pick their RNG implementation, they are liable to get >it >wrong. This may be valid but I'm still curious about the technical >reasons >for RNG in kernel space. > >Also, if kernel space is really necessary, I'd think publishing as a >dkms >type package would gain more traction for getting into mainline (but >this >is probably OT here) > >* Obviously that same argument can be made of userspace programs but >I'd >much prefer my exploits happen at a less privileged ring whenever >possible >:) > > > > >___ >cryptography mailing list >cryptography@randombit.net >http://lists.randombit.net/mailman/listinfo/cryptography -- Michael Greene Software Engineer mgre...@securityinnovation.com___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] RSA signatures without padding
It is my understanding that, on a very basic level, using RSA without padding allows computing “valid” signatures for new messages by combining two existing signatures, because a^d * b^d == (a * b) ^ d The use of sha256 in this case probably makes this task slightly more annoying, but by no means impossible - it raises the bar only to crafting a message m where Hm(m) == H(m1) * H(m2) mod N. With padding the scheme becomes H = (PAD(SHA256(M))) which makes the resulting signature probabilistic rather than deterministic, and combining signatures to create new signatures no longer works. It is also my understanding that the malleability problem with textbook (i.e. unpadded) RSA relates to encryption/decryption rather than signing/verification, not signing/verification, but I could be wrong about that. -- Michael Greene Software Engineer mgre...@securityinnovation.com On Jul 10, 2015, at 1:15 PM, Filip Paun paunfi...@gmail.com wrote: Suppose I have a message M for which I generate an RSA-2048 digital signature as follows: H = SHA-256(M) S = H^d mod N Assume N = p*q is properly generated and d is the RSA private key. And I verify the signature as follows: S^e mod N == H' where H' is the SHA-256 of the message to be authenticated. Assume e is the RSA public key. Since I've not used any padding then are there any flaws with the above approach? What if e = 3? What if e = 2^16+1? Your guidance is much appreciated. Thank you, Filip ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography smime.p7s Description: S/MIME cryptographic signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] OpenPGP in Python: Security evaluations?
For PGPy i really suggest to make a wrapper API to facilitate replacement of python-gnupg with PGPy. One of my big goals for PGPy is to have a good, consistent, API, and I think providing such a wrapper actually moves away from that goal rather than toward it. Besides, PGPy cannot yet do all of the things that the RFCs ask of it yet, so there would likely be holes in any such wrapper - and I think the time it would take me to implement would be better spent actually improving RFC compliance. I wouldn’t necessarily shun the existence of such a wrapper, but I have neither the time nor the desire to write it myself. -- Michael Greene Software Engineer mgre...@securityinnovation.com Message: 4 Date: Fri, 12 Jun 2015 12:39:16 +0200 From: Fabio Pietrosanti (naif) - lists li...@infosecurity.ch mailto:li...@infosecurity.ch To: cryptography@randombit.net mailto:cryptography@randombit.net Subject: Re: [cryptography] OpenPGP in Python: Security evaluations? Message-ID: 557ab6d4.6080...@infosecurity.ch mailto:557ab6d4.6080...@infosecurity.ch Content-Type: text/plain; charset=windows-1252 On 6/12/15 6:05 AM, Michael Greene wrote: Hello there, I am the author of PGPy - I figured I?d chime in here, even though I have clearly noticed this discussion a little bit late. When I decided that taking up the project of building a pure-Python OpenPGP implementation would be worthwhile, I did so after evaluating all of the existing Python libraries I could manage to find. The main reason I started the project was because very nearly all of the Python libraries for working with PGP were either wrappers around the gpg binary, or GPGME bindings (which itself is a wrapper around the gpg binary, but written in C). I'm a fan of PGPy approach, because it rely on native crypto but implement the OpenPGP packets formats in pure python enabling full application control without having to do dirty stuff (such as python-gnupg relying on gpg making executing gpg in /dev/shm/ leading to tons of issues). The integration of third party security software based on execution of cmdline is very dirty, architectually speaking, and most gpg and Tor library must do that. Regarding GPGME, is it really exec()uting the gpg binary or is it calling directly the gpg as a library? We're considering switching the server-side operations of GPG of GlobaLeaks to PGPy or OpenPGP-Python, given proper streaming support (for memory/buffering reasons) and a public security audit that can be arranged. signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] OpenPGP in Python: Security evaluations?
I think the trend appears to be the opposite - you have a consumer in one process and a producer in another process. If the consumer gets compromised (like a web server), then the secrets don't get compromised as easily because the producer is out of process. Right, and we’re not trying to integrate that far - I probably should have explained that a little more clearly. The idea is that we want tasks relating to managing and using keys to live in one process space, instead of duplicating them across two, and to eliminate the need to use Popen and pipes to accomplish that communication. It’s a lot slower because of the additional overhead, and it just feels kludgey. As you mentioned libassuan, a better method of IPC is needed than just Popen and pipes, and there’s no reason PGPy couldn’t be used in that way. Thanks for the other information, though, that is useful for me. Our earlier internal audit was focused primarily on finding some of that low-hanging fruit. Since PGPy is all Python, compilers aren’t much help in this case. Other than pylint, which doesn’t touch on anything security related, I don’t know of any analysis tools that support Python. Coverity Scan appears to only support Java, C/C++, and C#. Do you or anyone else on the list know of any that are worth checking out? -- Michael Greene Software Engineer mgre...@securityinnovation.com On Jun 12, 2015, at 4:05 AM, Jeffrey Walton noloa...@gmail.com wrote: The main problem we were interested in solving here was to be able to keep key management tasks within a single memory address space, to avoid the problems relating to securely sending passphrases to other processes, and to be able to use the keys without the additional disk IO involved in needing to import the key into an on-disk keyring before being able to use it for anything. I think the trend appears to be the opposite - you have a consumer in one process and a producer in another process. If the consumer gets compromised (like a web server), then the secrets don't get compromised as easily because the producer is out of process. I'm pretty sure GnuPG switched to that model. Libassuan is the dependency that's part of that mechanism. And I believe Microsoft's CryptoNG uses it too (but I may be wrong). We did an internal security audit of PGPy 0.3.0 shortly before releasing it, but I would definitely be grateful for additional eyes on the code, maybe when 0.4.0 comes out (which I am working toward). If anyone is interested, wants to share concerns, etc, I would welcome the discussion. There are are a few ways to approach it. The first thing I would do is pick the low hanging fruit. Its like folks like Bellovin and Guttman say: why go through the crypto when you can go around it? Get static and dynamic analyzers on the library. Compilers and their warning system are a good first line defense. Clang and its sanitzers are a good tool (https://docs.python.org/devguide/clang.html). And don't forget about Coverity's free scanning service for FOSS software (https://scan.coverity.com/). Once the low hanging fruit is picked, then move onto the specialized audits, like secure coding for the platform, platform security integration, and cryptography. Jeff On Fri, Jun 12, 2015 at 12:05 AM, Michael Greene mgre...@securityinnovation.com wrote: Hello there, I am the author of PGPy - I figured I’d chime in here, even though I have clearly noticed this discussion a little bit late. When I decided that taking up the project of building a pure-Python OpenPGP implementation would be worthwhile, I did so after evaluating all of the existing Python libraries I could manage to find. The main reason I started the project was because very nearly all of the Python libraries for working with PGP were either wrappers around the gpg binary, or GPGME bindings (which itself is a wrapper around the gpg binary, but written in C). To be honest, I’m not sure if calling PGPy “pure-Python” is necessarily 100% correct. Although PGPy itself is 100% implemented in Python, I did not implement any of the actual crypto myself - that is handled by the Cryptography library, which uses cffi to invoke methods from existing libraries (the default currently being OpenSSL, but the possibility to plug into alternate backends exists as well) So basically, practically the only way to be able to use PGP in Python was, one way or another, to call out to the GPG binary (and as it turns out, platform portability in that context is a difficult proposition - the largest category of related StackOverflow questions I happened across while searching for as many of these libraries as I could were questions from people who were having difficulty getting them to work on different platforms - often Windows, but probably not all of them. That particular issue was not something we were necessarily gunning for, but it might be nice for a handful of people
Re: [cryptography] OpenPGP in Python: Security evaluations?
Hello there, I am the author of PGPy - I figured I’d chime in here, even though I have clearly noticed this discussion a little bit late. When I decided that taking up the project of building a pure-Python OpenPGP implementation would be worthwhile, I did so after evaluating all of the existing Python libraries I could manage to find. The main reason I started the project was because very nearly all of the Python libraries for working with PGP were either wrappers around the gpg binary, or GPGME bindings (which itself is a wrapper around the gpg binary, but written in C). To be honest, I’m not sure if calling PGPy “pure-Python” is necessarily 100% correct. Although PGPy itself is 100% implemented in Python, I did not implement any of the actual crypto myself - that is handled by the Cryptography library, which uses cffi to invoke methods from existing libraries (the default currently being OpenSSL, but the possibility to plug into alternate backends exists as well) So basically, practically the only way to be able to use PGP in Python was, one way or another, to call out to the GPG binary (and as it turns out, platform portability in that context is a difficult proposition - the largest category of related StackOverflow questions I happened across while searching for as many of these libraries as I could were questions from people who were having difficulty getting them to work on different platforms - often Windows, but probably not all of them. That particular issue was not something we were necessarily gunning for, but it might be nice for a handful of people, at least.) The main problem we were interested in solving here was to be able to keep key management tasks within a single memory address space, to avoid the problems relating to securely sending passphrases to other processes, and to be able to use the keys without the additional disk IO involved in needing to import the key into an on-disk keyring before being able to use it for anything. As a bonus, it turns out that doing the parsing natively in Python and not having to incur the additional overhead of spinning up an external process and communicate with it over pipes is actually tangibly faster, especially when repeating relatively quick operations (like signing a number of separate things in a row). We did an internal security audit of PGPy 0.3.0 shortly before releasing it, but I would definitely be grateful for additional eyes on the code, maybe when 0.4.0 comes out (which I am working toward). If anyone is interested, wants to share concerns, etc, I would welcome the discussion. -- Michael Greene Software Engineer mgre...@securityinnovation.com smime.p7s Description: S/MIME cryptographic signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
