Okay, I've taken all of the comments away and done some experiments and found a solution that that has worked for me.
I summised that if the keys were being created correctly, perhaps it wasn't really the decryption that was failing, but the writting of the dycrypted data to the epg database.
I decided to find where the everyone authority was set in relation to the eHome folder, and it was the parent \ApplicationData\Microsoft folder.
I upped the authority for everyone to add modify and create rights as they were currently only set to read and execute.
Ran the guide update again, and bingo, it works.
Now I'm don't want to make wide ranging changes to the object authorities, so I decided to dig a little deeper.
I've found another copy of Vista that was downloading the epg data correctly previously and there is something interesting that's worth passing on.
Although the privaliges at the ApplicationData\Microsoft folder level were the same, they were not lower down at the eHome folder level.
In the working copy of Vista, does not inherit the priveliges from its parent ApplicationData\Microsoft folder, but on the non working system it does..
This mismatch seems to only be restricted to the eHome folder, all other subfolders of the ApplicationData\Microsoft folder have the same privaliges in both installations.
I checked another installation that didn't work and can confirm that too had inherited the parent priveliges.
As a final test I reset the everyone attributes on the ApplicationData\Microsoft folder back to read/execute and remove the inherited priveliges from the eHome folder. This was a simple case of turning off the inherit privelige flag on the eHome directory in the advanced security dialogue.
This now works perfectly.
Give it a go and see if it fixes your problems as well.
For MS, I guess you need to look into which update, or software installation could have changed the inherited priveliges flag on the eHome folder.
Job Done.