Re: Fix VIA Padlock RNG support ?
Hi Geoff, On Sun, Sep 21, 2008 at 11:20:35PM -0400, Geoff Thorpe wrote: Looking at this in more detail, the current s/w PRNG implementation keeps a running 'entropy' count and when that reaches a certain threshold, it stops maintaining an entropy counter because the PRNG is considered sufficiently seeded. Each platform (roughly speaking) has its own implementation of RAND_poll() which does some canonical seeding, which may be enough to get the PRNG off the ground, or if not, the application will need to RAND_add() (or RAND_seed()) some more entropy before the PRNG is ready. In any case, this doesn't adapt so well to a model where entropy sources live as callbacks and get called by the PRNG when required. It's more a model where an entropy source should just stuff its entropy into the PRNG as soon as it gets a chance, and preferably as much of the stuff as it has handy. It can always add more later and no harm will be done, but there's no obvious way to add a hook to ask for entropy automatically. Sounds perfectly reasonable and I totally understand. It really is strange that you have to poll for random numbers rather than somebody feeding them into you. With this in mind, I'm wondering if the simplest thing to do isn't just to have the padlock (or any other) engine call RAND_add() with some entropy during the init() handler of the ENGINE itself (rather than in a RAND_METHOD). That doesn't solve the problem of adding more entropy as time goes by, but it's better than the current situation (only having a RAND_METHOD mechanism you can't use at all), and moreover it requires no interface changes, just implementation... Thoughts? Sounds completely fine with me. I'll do some experimentation after I'm finished with the PadLock PHE (hashing) stuff and cook up a patch. Since I'm currently quite busy it will probably take some time. -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: Fix VIA Padlock RNG support ?
Hi again, On Thursday 11 September 2008 09:32:14 Geoff Thorpe wrote: On Thursday 11 September 2008 09:06:39 Harald Welte wrote: On Thu, Sep 11, 2008 at 10:22:38PM +1200, Michal Ludvig wrote: Have a look here: http://marc.info/?l=openssl-devm=109113625526391w=2 and in the corresponding thread for the discussion. FWIW even in the Linux kernel the hardware RNGs (incl. VIA PadLock) are not used directly for RNG output but instead to feed the entropy pool. I quite agree with the reasons why OpenSSL shouldn't use whatever it gets from PadLock RNG *directly* as a stream of random numbers. Unfortunately as soon as PadLock engine registers as a RNG provider OpenSSL won't do any post-processing of the random data and therefore the best bet at that time was not to use PadLock's RNG. Yes, after reviewing the discussion and documentation I tend to agree. So the best option really is to make OpenSSL use the userspace interface for the kernel random number generator, and feed that kernel RNG's entropy pool from the hardware RNG. O, right, I see know. Yes this is a bit crap. The problem IMHO is that RAND_METHOD is the wholesale replacement interface. Ie. the entire software PRNG sits behind that interface, no matter how it obtains its entropy, and using an alternative RAND_METHOD will completely bypass the software PRNG. This makes sense for the other ***_METHOD interfaces, because they're alternatives to the s/w implementations - they can be used simultaneously, but work on completely separated contexts. In the case of the PRNG, there are no separated contexts nor point to having s/w and replacement PRNGs working independently. I think the sensible thing would be to stick with the s/w PRNG implementation and have it expose an inner interface for its entropy sources and let engines plug themselves into *that*, rather than acting as alternatives/replacements for the entire PRNG. Looking at this in more detail, the current s/w PRNG implementation keeps a running 'entropy' count and when that reaches a certain threshold, it stops maintaining an entropy counter because the PRNG is considered sufficiently seeded. Each platform (roughly speaking) has its own implementation of RAND_poll() which does some canonical seeding, which may be enough to get the PRNG off the ground, or if not, the application will need to RAND_add() (or RAND_seed()) some more entropy before the PRNG is ready. In any case, this doesn't adapt so well to a model where entropy sources live as callbacks and get called by the PRNG when required. It's more a model where an entropy source should just stuff its entropy into the PRNG as soon as it gets a chance, and preferably as much of the stuff as it has handy. It can always add more later and no harm will be done, but there's no obvious way to add a hook to ask for entropy automatically. With this in mind, I'm wondering if the simplest thing to do isn't just to have the padlock (or any other) engine call RAND_add() with some entropy during the init() handler of the ENGINE itself (rather than in a RAND_METHOD). That doesn't solve the problem of adding more entropy as time goes by, but it's better than the current situation (only having a RAND_METHOD mechanism you can't use at all), and moreover it requires no interface changes, just implementation... Thoughts? Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: VIA Padlock Hashing Engine [Was: Fix VIA Padlock RNG support ?]
BTW, my memory is vague here, is this Padlock block only able to do one-shot hashing? Yes, but a technique bypassing this limitation was proposed and proven to work (as per end of SHA1 thread mentioned earlier). Technique involved crashing of hashing instruction into non-accessible page. And that was what I wanted to pursue, but never got time to. Which is why there was no real follow-up:-( For reference, the plan was to setup intermediate buffer followed by non-accessible page upon engine setup, i.e. once, and then serialize access to it with thread synchronizing primitives. I reckon that serializing threads is OK, because system is more likely to starve for data than for hashing compute power (1Gbps NIC vs. ~2Gbps hashing rate). Strangely enough, I've got uncommitted code to add support for thread-local-storage ... :-) (It's one of the components in the work I'm doing for async-crypto.) So if you take the approach you suggesting above, it should be relatively simple to generalise it later, to avoid locking/serialisation. Setting up the intermediate buffer followed by guard page is quite expensive operation, so you don't want to do it too often. You definitely don't want to do it upon -init, and I personally would be reluctant to do it even on per-thread basis. Being library provider we don't know how short-lived threads are, and better assume the worst. Then it might be problematic to clean-up upon thread termination, not to mention that such buffer is expensive resource by itself. Basically one has to figure out what impact would serialization have and weigh it against costs caused by per-thread initialization. But as mentioned, I think serialization on per-process buffer would be appropriate in this case. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Fix VIA Padlock RNG support ?
I don't think there's any taboo or a strong opposition against the patch. It's just that Andy hasn't followed up, I sort of given up and moved to other projects and the whole thing has gone forgotten. Ok. I hope after my re-merge and testing we can get it integrated this time. BTW, my memory is vague here, is this Padlock block only able to do one-shot hashing? Yes, in all current CPU's (up to the C7), it is. There's a beatiful workaround by Michal and Andy which they have implemented in phe_sum by making the process page fault every time they need to copy in a new buffer (since the PHE is context-switch safe). I'd call it a clever hack rather than a beautiful workaround. IMO playing with SEGV handlers inside a library like libcrypto is begging to be bitten by unintended consequences. But should it prevent us from trying? I mean if we will be bitten, we'll then actually know, which is better than speculating about it:-) But what's worst that can happen? Another signal delivered asynchronously and handler causing SEGV? One can mask all maskable signals upon sigaction(SIGSEGV)... A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Fix VIA Padlock RNG support ?
Hi Harald and Geoff, Harald Welte wrote: I searched the list archives but couldn't find anything apart from that single message by Michal to the list. He is talking about someobody having asked him to add testsuite support, but he didn't exactly know what he needs to add. I could not find any evidence of any prior or later discussion on that subject. Maybe Michal could enlighten us :) There has been some discussion regarding SHA1 and SHA256 support in 2005 on openssl-dev list. I was dealing mainly with Andy Polyakov on the OpenSSL side at that time. Have a look here: http://marc.info/?t=11278167611r=1w=4 for a thread about SHA1 integration and here: http://marc.info/?l=openssl-devm=112782644132216w=4 for SHA256 patch. And finally the one you already knew about. That's the final works for me version ready to be committed to openssl tree current at that time (may not apply smoothly anymore, I don't know): http://marc.info/?l=openssl-devm=115243758508970w=4 I don't think there's any taboo or a strong opposition against the patch. It's just that Andy hasn't followed up, I sort of given up and moved to other projects and the whole thing has gone forgotten. As for the RNG stuff, if you are able to find any references to discussion and/or cvs commits regarding the deactivation by OpenSSL maintainers then that would make it easier for me to follow up too. TIA. At http://www.logix.cz/michal/devel/padlock/index.xp?show_selected=1msgid=1050 I found the quote Stock OpenSSL as packaged in linux distros or as available from openssl.org has the RNG engine intentionally disabled. Thus no-RNG. My patches have it enables, so you see RNG. See the source for the reasons to enable/disable RNG. which seems to indicate that Michal Ludvig's original code has it enabled, but OpenSSL mainline disabled it. I searched the list archives and RT before, but didn't find anything on either the RNG or the SHA issue. Have a look here: http://marc.info/?l=openssl-devm=109113625526391w=2 and in the corresponding thread for the discussion. FWIW even in the Linux kernel the hardware RNGs (incl. VIA PadLock) are not used directly for RNG output but instead to feed the entropy pool. I quite agree with the reasons why OpenSSL shouldn't use whatever it gets from PadLock RNG *directly* as a stream of random numbers. Unfortunately as soon as PadLock engine registers as a RNG provider OpenSSL won't do any post-processing of the random data and therefore the best bet at that time was not to use PadLock's RNG. Michal __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Fix VIA Padlock RNG support ?
Michal, thanks so much for your detailed feedback. It is much appreciated. On Thu, Sep 11, 2008 at 10:22:38PM +1200, Michal Ludvig wrote: And finally the one you already knew about. That's the final works for me version ready to be committed to openssl tree current at that time (may not apply smoothly anymore, I don't know): http://marc.info/?l=openssl-devm=115243758508970w=4 Ok, let me dig that out, merge it with current ssl version of openssl, give it some testing and resubmit it to the mailinglist for inclusion. I don't think there's any taboo or a strong opposition against the patch. It's just that Andy hasn't followed up, I sort of given up and moved to other projects and the whole thing has gone forgotten. Ok. I hope after my re-merge and testing we can get it integrated this time. which seems to indicate that Michal Ludvig's original code has it enabled, but OpenSSL mainline disabled it. Have a look here: http://marc.info/?l=openssl-devm=109113625526391w=2 and in the corresponding thread for the discussion. FWIW even in the Linux kernel the hardware RNGs (incl. VIA PadLock) are not used directly for RNG output but instead to feed the entropy pool. I quite agree with the reasons why OpenSSL shouldn't use whatever it gets from PadLock RNG *directly* as a stream of random numbers. Unfortunately as soon as PadLock engine registers as a RNG provider OpenSSL won't do any post-processing of the random data and therefore the best bet at that time was not to use PadLock's RNG. Yes, after reviewing the discussion and documentation I tend to agree. So the best option really is to make OpenSSL use the userspace interface for the kernel random number generator, and feed that kernel RNG's entropy pool from the hardware RNG. I'll submit a patch to OpenSSL which gives a more detailed description in the comment since I think it is sort of like a FAQ for those people who actually discover the padlocn no-RNG flag :) Cheers, -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: Fix VIA Padlock RNG support ?
On Thursday 11 September 2008 09:06:39 Harald Welte wrote: On Thu, Sep 11, 2008 at 10:22:38PM +1200, Michal Ludvig wrote: And finally the one you already knew about. That's the final works for me version ready to be committed to openssl tree current at that time (may not apply smoothly anymore, I don't know): http://marc.info/?l=openssl-devm=115243758508970w=4 Ok, let me dig that out, merge it with current ssl version of openssl, give it some testing and resubmit it to the mailinglist for inclusion. Thanks, let me know how you get on. I don't think there's any taboo or a strong opposition against the patch. It's just that Andy hasn't followed up, I sort of given up and moved to other projects and the whole thing has gone forgotten. Ok. I hope after my re-merge and testing we can get it integrated this time. BTW, my memory is vague here, is this Padlock block only able to do one-shot hashing? Have a look here: http://marc.info/?l=openssl-devm=109113625526391w=2 and in the corresponding thread for the discussion. FWIW even in the Linux kernel the hardware RNGs (incl. VIA PadLock) are not used directly for RNG output but instead to feed the entropy pool. I quite agree with the reasons why OpenSSL shouldn't use whatever it gets from PadLock RNG *directly* as a stream of random numbers. Unfortunately as soon as PadLock engine registers as a RNG provider OpenSSL won't do any post-processing of the random data and therefore the best bet at that time was not to use PadLock's RNG. Yes, after reviewing the discussion and documentation I tend to agree. So the best option really is to make OpenSSL use the userspace interface for the kernel random number generator, and feed that kernel RNG's entropy pool from the hardware RNG. O, right, I see know. Yes this is a bit crap. The problem IMHO is that RAND_METHOD is the wholesale replacement interface. Ie. the entire software PRNG sits behind that interface, no matter how it obtains its entropy, and using an alternative RAND_METHOD will completely bypass the software PRNG. This makes sense for the other ***_METHOD interfaces, because they're alternatives to the s/w implementations - they can be used simultaneously, but work on completely separated contexts. In the case of the PRNG, there are no separated contexts nor point to having s/w and replacement PRNGs working independently. I think the sensible thing would be to stick with the s/w PRNG implementation and have it expose an inner interface for its entropy sources and let engines plug themselves into *that*, rather than acting as alternatives/replacements for the entire PRNG. I'll submit a patch to OpenSSL which gives a more detailed description in the comment since I think it is sort of like a FAQ for those people who actually discover the padlocn no-RNG flag :) I will see if I can sketch an ENTROPY_METHOD that would improve this situation. Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Fix VIA Padlock RNG support ?
On Thu, Sep 11, 2008 at 09:06:39PM +0800, Harald Welte wrote: Yes, after reviewing the discussion and documentation I tend to agree. So the best option really is to make OpenSSL use the userspace interface for the kernel random number generator, and feed that kernel RNG's entropy pool from the hardware RNG. Please don't do this in an engine; the extra syscalls will murder performance. One of the nicest things about the VIA crypto accellerator is that it is really just so many extra, unprivileged instructions. So you don't have to do any system calls or even any special memory accesses to use it -- so you don't incur performance side-effects that make your whole program run slowly though the crypto seems to run fast. The right thing to do is to *fix the Engine interface and the RNG code* so an Engine can supply random bits without replacing the entire RNG. Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: VIA Padlock Hashing Engine [Was: Fix VIA Padlock RNG support ?]
I don't think there's any taboo or a strong opposition against the patch. It's just that Andy hasn't followed up, I sort of given up and moved to other projects and the whole thing has gone forgotten. Ok. I hope after my re-merge and testing we can get it integrated this time. BTW, my memory is vague here, is this Padlock block only able to do one-shot hashing? Yes, but a technique bypassing this limitation was proposed and proven to work (as per end of SHA1 thread mentioned earlier). Technique involved crashing of hashing instruction into non-accessible page. And that was what I wanted to pursue, but never got time to. Which is why there was no real follow-up:-( For reference, the plan was to setup intermediate buffer followed by non-accessible page upon engine setup, i.e. once, and then serialize access to it with thread synchronizing primitives. I reckon that serializing threads is OK, because system is more likely to starve for data than for hashing compute power (1Gbps NIC vs. ~2Gbps hashing rate). A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: VIA Padlock Hashing Engine [Was: Fix VIA Padlock RNG support ?]
On Thursday 11 September 2008 15:16:48 Andy Polyakov wrote: BTW, my memory is vague here, is this Padlock block only able to do one-shot hashing? Yes, but a technique bypassing this limitation was proposed and proven to work (as per end of SHA1 thread mentioned earlier). Technique involved crashing of hashing instruction into non-accessible page. And that was what I wanted to pursue, but never got time to. Which is why there was no real follow-up:-( For reference, the plan was to setup intermediate buffer followed by non-accessible page upon engine setup, i.e. once, and then serialize access to it with thread synchronizing primitives. I reckon that serializing threads is OK, because system is more likely to starve for data than for hashing compute power (1Gbps NIC vs. ~2Gbps hashing rate). A. Strangely enough, I've got uncommitted code to add support for thread-local-storage ... :-) (It's one of the components in the work I'm doing for async-crypto.) So if you take the approach you suggesting above, it should be relatively simple to generalise it later, to avoid locking/serialisation. Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Fix VIA Padlock RNG support ?
On Thu, Sep 11, 2008 at 09:32:14AM -0400, Geoff Thorpe wrote: I don't think there's any taboo or a strong opposition against the patch. It's just that Andy hasn't followed up, I sort of given up and moved to other projects and the whole thing has gone forgotten. Ok. I hope after my re-merge and testing we can get it integrated this time. BTW, my memory is vague here, is this Padlock block only able to do one-shot hashing? Yes, in all current CPU's (up to the C7), it is. There's a beatiful workaround by Michal and Andy which they have implemented in phe_sum by making the process page fault every time they need to copy in a new buffer (since the PHE is context-switch safe). I have heard rumours that the new CN (Nano) can do incremental hashing. As soon as I have access to the hardware and the docs I'll add that on top of the old code. In any case, there are many applications, mainly network security apps such as ssh and opencpn for which the 8k buffer of Michal's patch is enough. Yes, after reviewing the discussion and documentation I tend to agree. So the best option really is to make OpenSSL use the userspace interface for the kernel random number generator, and feed that kernel RNG's entropy pool from the hardware RNG. O, right, I see know. Yes this is a bit crap. The problem IMHO is that RAND_METHOD is the wholesale replacement interface. Ie. the entire software PRNG sits behind that interface, no matter how it obtains its entropy, and using an alternative RAND_METHOD will completely bypass the software PRNG. yes, exactly. I'll submit a patch to OpenSSL which gives a more detailed description in the comment since I think it is sort of like a FAQ for those people who actually discover the padlocn no-RNG flag :) I will see if I can sketch an ENTROPY_METHOD that would improve this situation. great, thanks. -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: VIA Padlock Hashing Engine [Was: Fix VIA Padlock RNG support ?]
BTW, my memory is vague here, is this Padlock block only able to do one-shot hashing? Yes, but a technique bypassing this limitation was proposed and proven to work (as per end of SHA1 thread mentioned earlier). Proof of concept is here: http://logix.cz/michal/devel/padlock/phe_sum.xp Michal __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Fix VIA Padlock RNG support ?
On Fri, 12 Sep 2008, Harald Welte wrote: On Thu, Sep 11, 2008 at 09:32:14AM -0400, Geoff Thorpe wrote: I don't think there's any taboo or a strong opposition against the patch. It's just that Andy hasn't followed up, I sort of given up and moved to other projects and the whole thing has gone forgotten. Ok. I hope after my re-merge and testing we can get it integrated this time. BTW, my memory is vague here, is this Padlock block only able to do one-shot hashing? Yes, in all current CPU's (up to the C7), it is. There's a beatiful workaround by Michal and Andy which they have implemented in phe_sum by making the process page fault every time they need to copy in a new buffer (since the PHE is context-switch safe). I'd call it a clever hack rather than a beautiful workaround. IMO playing with SEGV handlers inside a library like libcrypto is begging to be bitten by unintended consequences. -d __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Fix VIA Padlock RNG support ?
Hi guys, ist has been 10 days since I posted this mail about certain questions with regard to the suboptimal integration of VIA padlock support in OpenSSL. Is there some kind of taboo against this topic or some bad history that I'm missing? If yes, I'm sorry to hear that. In any case, I am here, I have time, and I will do whatever it takes to the code to make you guys happy with it for integration. So please talk to me ;) Thanks again. On Mon, Sep 01, 2008 at 09:51:30PM +0800, Harald Welte wrote: Hi Michal, Hi OpenSSL developers, as part of my work for VIA, I am trying to find out what we can do to make sure the VIA Padlock RNG is activated by default. I have read the comments in the source code, referring that the RNG is not used the way that VIA recommends for secure applications. I have also read the padlock programming guides from http://linux.via.com.tw/support/beginDownload.action?eleid=181fid=261 and http://linux.via.com.tw/support/beginDownload.action?eleid=181fid=281 So from what I can tell, Michal Ludvig originally included RNG support in his patch, but it was deactivated by the OpenSSL maintainers due to security concerns. Can somebody please indicate what exactly those concerns were? I would be willing to put in some of my own time to come up with a patch to address the concerns, and then have that patch reviewed by OpenSSL guys, Michal as well as the respective Padlock security expert inside VIA. I also have a question about Michal's SHA1/224/256 patch at http://marc.info/?l=openssl-devm=115243758508970w=2 It never received any feedback on the list, and it wasn't merged into mainline OpenSSL. Was this simply lost? Can I (or VIA) do anything to help this along? Thanks in advance, -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: Fix VIA Padlock RNG support ?
* Harald Welte ([EMAIL PROTECTED]) wrote: Hi guys, ist has been 10 days since I posted this mail about certain questions with regard to the suboptimal integration of VIA padlock support in OpenSSL. Is there some kind of taboo against this topic or some bad history that I'm missing? If yes, I'm sorry to hear that. In any case, I am here, I have time, and I will do whatever it takes to the code to make you guys happy with it for integration. So please talk to me ;) Hi Harald, No taboo, no bad history that I'm aware of, just plain old open-source, everyone's-always-got-something-else-less-free-to-do indifference. Don't take it personally :-) I just took a look at Michal's SHA patch and nothing lept out as overly terrifying. Perhaps Michal will comment if he's aware of any discussion about it? (I don't recall.) Otherwise did you happen to search the request tracker or mail archives about this? (Ie. beyond the fact that Michal's post didn't have a threaded response.) As for the RNG stuff, if you are able to find any references to discussion and/or cvs commits regarding the deactivation by OpenSSL maintainers then that would make it easier for me to follow up too. TIA. Cheers, Geoff Thanks again. On Mon, Sep 01, 2008 at 09:51:30PM +0800, Harald Welte wrote: Hi Michal, Hi OpenSSL developers, as part of my work for VIA, I am trying to find out what we can do to make sure the VIA Padlock RNG is activated by default. I have read the comments in the source code, referring that the RNG is not used the way that VIA recommends for secure applications. I have also read the padlock programming guides from http://linux.via.com.tw/support/beginDownload.action?eleid=181fid=261 and http://linux.via.com.tw/support/beginDownload.action?eleid=181fid=281 So from what I can tell, Michal Ludvig originally included RNG support in his patch, but it was deactivated by the OpenSSL maintainers due to security concerns. Can somebody please indicate what exactly those concerns were? I would be willing to put in some of my own time to come up with a patch to address the concerns, and then have that patch reviewed by OpenSSL guys, Michal as well as the respective Padlock security expert inside VIA. I also have a question about Michal's SHA1/224/256 patch at http://marc.info/?l=openssl-devm=115243758508970w=2 It never received any feedback on the list, and it wasn't merged into mainline OpenSSL. Was this simply lost? Can I (or VIA) do anything to help this along? Thanks in advance, -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Fix VIA Padlock RNG support ?
Hi Geoff, thanks for your quick response. On Wed, Sep 10, 2008 at 09:56:36PM -0400, Geoff Thorpe wrote: No taboo, no bad history that I'm aware of, just plain old open-source, everyone's-always-got-something-else-less-free-to-do indifference. Don't take it personally :-) ok, thanks. that's good to hear. I just took a look at Michal's SHA patch and nothing lept out as overly terrifying. Perhaps Michal will comment if he's aware of any discussion about it? (I don't recall.) Otherwise did you happen to search the request tracker or mail archives about this? (Ie. beyond the fact that Michal's post didn't have a threaded response.) I searched the list archives but couldn't find anything apart from that single message by Michal to the list. He is talking about someobody having asked him to add testsuite support, but he didn't exactly know what he needs to add. I could not find any evidence of any prior or later discussion on that subject. Maybe Michal could enlighten us :) As for the RNG stuff, if you are able to find any references to discussion and/or cvs commits regarding the deactivation by OpenSSL maintainers then that would make it easier for me to follow up too. TIA. At http://www.logix.cz/michal/devel/padlock/index.xp?show_selected=1msgid=1050 I found the quote Stock OpenSSL as packaged in linux distros or as available from openssl.org has the RNG engine intentionally disabled. Thus no-RNG. My patches have it enables, so you see RNG. See the source for the reasons to enable/disable RNG. which seems to indicate that Michal Ludvig's original code has it enabled, but OpenSSL mainline disabled it. I searched the list archives and RT before, but didn't find anything on either the RNG or the SHA issue. Cheers, -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
