Thanks for your quick response Sebastien,
Sebastien Pouliot-2 wrote: > > > Daniel Nauck told me about this bug - and I'm still waiting for answers > to some questions. AFAICT the fact that this works under Windows is the > reason it does not work on Mono. > > Basically the same key, data and storage are used on both (mono and > ms.net) but the (undocumented) algorithm itself is different. So you > can't mix and match ms.net and mono with the same (membership) data > source. > Well, I am not sure if i got you right - even though encryption keys and data stored in database is the same both on mono and ms.net, due to difference in cipher algorithm implementations, application running under ms.net will not be able to decipher data encrypted under mono counterpart and vice versa? In this particular scenario this is not the case, as aforementioned 'bug' manifests itself even when not switching to ms.net and running application under mono only. When registering new user the data seems to be written to the database in an encrypted form, but whenever you'd try do decrypt it(for example when trying to log in) you'd get this "Bad padding" exception. Or maybe i cannot use current cipher keys(they work on windows for sure) under mono? Is 'special' mono version of keypair (decryptionKey, validationKey) required? If so how can i generate it? Sebastien Pouliot-2 wrote: > >> Are there any plans to fix this bug anytime soon? > Not without a bug report and not without test cases (that exclude the > above case). > Ok, am i free to fill in a bug (of course reading http://mono-project.com/Bugs first ;))? -- View this message in context: http://www.nabble.com/Bad-PKCS7-padding.-Invalid-length-when-using-asp.net-membership-provider---a-bug-in-mono--tp24955064p25253261.html Sent from the Mono - General mailing list archive at Nabble.com. _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
