On Thu, 28 Jul 2005 10:36:11 +0200, Zeljko Vrba said:
> For decryption there is no problem, of course. As for encryption.. it is
Well not supporting it _might_ help the sender to realize that he is
doing something strange (i.e. using a weak algorithm)
> but you have to have some kind of plugin f
Sven Fischer wrote:
Also, it isn't our fault, that M$ does use such simple crypto algorithms. I
personally share this opinion, but only for the encryption side. For
decryption, I don't understand why it should be a problem.
For decryption there is no problem, of course. As for encryption.. it
Werner Koch wrote:
> On Tue, 26 Jul 2005 19:22:06 +0200, Zeljko Vrba said:
>
>> Ugh, I hope that you'll _never,ever_ allow such low-grade insecure
>> algorithms in gpg or anything related to it, no matter what the public
>> demand is.
>
> For sure not in an application like gpg. However for cer
On Wed, 27 Jul 2005 11:32:51 +0200 (MET DST), Johan Wevers said:
> write a RC2 plugin if it's really needed. Or is there an easy way to add
> new algorithms to the current version of GnuPG that doesn't require
> changes in many places in the code?
It is actual pretty simple but limited by the fac
Zeljko Vrba wrote:
[40 bit RC2]
>Ugh, I hope that you'll _never,ever_ allow such low-grade insecure
>algorithms in gpg or anything related to it, no matter what the public
>demand is.
One could use GnuPG 1.0.6, the last version with the plugin system, and
write a RC2 plugin if it's really needed
On Tue, 26 Jul 2005 19:22:06 +0200, Zeljko Vrba said:
> Ugh, I hope that you'll _never,ever_ allow such low-grade insecure
> algorithms in gpg or anything related to it, no matter what the public
> demand is.
For sure not in an application like gpg. However for certain tools
(e.g. a crypto workb
Werner Koch wrote:
IIRC, we would need to implement a variant of RC2 to allow this. And
well, 40 bit RC2 keys are pretty ridiculous.
Ugh, I hope that you'll _never,ever_ allow such low-grade insecure
algorithms in gpg or anything related to it, no matter what the public
demand is.
best regar
On Tue, 26 Jul 2005 16:35:58 +0200, Sven Fischer said:
> out. Well, this seems to have a reason, since uncommenting and recompiling
> libgcrypt 1.2.1 let gpgsm try to decrypt the mail, but without success (it
> says no data). Where is the problem with this? Can I help in any way to
> decode the Ou
Hi all,
I have again the "I can't decode Outlook s/MIME mails" problem, 'cause I
receive mails from Outlook users that are obviously encrypted with 40bit
RC-2.
Just for my interest: In libgcrypt's rfc2268.c the RC2 algorithm is
implemented. But the ID for the RC2 the Outlook mails are sent is com
