PennMUSH Community

Ticket #5739 (closed suggested feature: fixed)

Opened 6 years ago

Last modified 1 year ago

Softcode encryption functions issue...

Reported by: anonymous Assigned to: devteam
Priority: minor Milestone: 1.8.3p4
Keywords: Cc:
Visibility: Public

Description (Last modified by raevnos)

1.7.7p11

This is an issue with the encrypt and decryp I noticed just recently, and am 
not sure if anyone else has ever noticed it...

Essentially, if you use the encrypt and decrypt softcode functions with a 
password that includes numbers, the output of the encrypt function is so 
loaded with special characters, such as % ( ) \ , { } [ ],  that it is 
essentially impossible to decrypt the text due to the parsing of those 
characters. I know these sometimes appear when using all text passwords, 
notably [ ] and \, but they are not nearly as common. In any case, I wanted to 
bring it up if for some reason it hasn't been in the past, and wonder if 
perhaps there was some way of correcting the behavior to make it less 
difficult to deal with.

-
Noltar

-- 

--- Noltar uth Mormadar ---| KorongilMUSH Code & Theme Wizard
Email: noltar@korongil.org | http://www.korongil.org/
http://noltar.korongil.org | telnet://mush.korongil.org:6250
--------------------------------------------------------------
'Myth based on Legend, Legend based on Fact, Fact is Reality.'
- Noltar uth Mormadar
--------------------------------------------------------------


Change History

03/02/03 09:31:50 changed by Alan Schwartz <dunemush@pennmush.org>

Quoting noltar@korongil.org (noltar@korongil.org):
> 1.7.7p11
> 
> This is an issue with the encrypt and decryp I noticed just recently, and am 
> not sure if anyone else has ever noticed it...
> 
> Essentially, if you use the encrypt and decrypt softcode functions with a 
> password that includes numbers, the output of the encrypt function is so 
> loaded with special characters, such as % ( ) \ , { } [ ],  that it is 
> essentially impossible to decrypt the text due to the parsing of those 
> characters. I know these sometimes appear when using all text passwords, 
> notably [ ] and \, but they are not nearly as common. In any case, I wanted to 
> bring it up if for some reason it hasn't been in the past, and wonder if 
> perhaps there was some way of correcting the behavior to make it less 
> difficult to deal with.

It's true that encrypt returns these characters, but not true that you
can't decrypt them. I have shown people how to do so (by ensuring
that you protect the output appropriately from extra evaluation).

However, I'd be happy to add a second encrypt/decrypt pair that
spews in base64 - probably once I get to SSL support in general,
as the SSL library provides this.

 - Alan

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Javelin@M*U*S*H (mush.pennmush.org 4201) |           Alan Schwartz
                                         |       dunemush@pennmush.org
Paul@DuneMUSH, and Javelin elsewhere     |     PennMUSH Server Maintainer
=-------------------------------------------------------------------------=
   PennMUSH God's Guide: http://www.pennmush.org/~alansz/guide.html
        PennMUSH Source: http://ftp.pennmush.org/Source
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

12/01/04 05:11:49 changed by

base64 encryption armoring

01/02/07 07:55:40 changed by raevnos

  • type changed from priority feature to suggested feature.
  • description changed.

05/01/07 13:43:01 changed by raevnos

  • milestone set to 1.8.3p3.

encrypt64() and decode64()?

05/24/07 09:26:19 changed by raevnos

  • milestone changed from 1.8.3p3 to 1.8.3p4.

07/07/07 15:45:08 changed by raevnos

  • status changed from new to closed.
  • resolution set to fixed.