Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ General
➜ asymmetric Base64Decode -> Base64Encode
|
asymmetric Base64Decode -> Base64Encode
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Fiendish
USA (2,558 posts) Bio
Global Moderator |
| Date
| Sat 30 Mar 2013 07:47 PM (UTC) Amended on Sat 30 Mar 2013 07:58 PM (UTC) by Fiendish
|
| Message
| Common specs for Base64 indicate that the output character set is [a-zA-Z0-9+/]*=?=?, but MUSHclient Base64Decode("a+==") returns "k" which encodes to "aw==". Is your Base64Encode method guaranteed to produce alphanumeric(asymmetric from decode) results?
My bigger question is whether the result (with trailing equals stripped) is safe for naming aliases based on match pattern or if you have a better way. |
https://github.com/fiendish/aardwolfclientpackage | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #1 on Sat 30 Mar 2013 10:51 PM (UTC) |
| Message
| According to this site, at least:
http://www.motobit.com/util/base64-decoder-encoder.asp
The correct encoding for "k" is indeed "aw==".
Your example of "a+==" contains a stray extra two bits (the difference between "w" and "+").
However as Wikipedia says:
http://en.wikipedia.org/wiki/Base64
Quote:
A single '=' indicates that the 4 characters will decode to only 2 bytes, while 2 '='s indicates that the 4 characters will decode to only a single byte.
So the trailing "==" overrides those stray bits, because they specify that the group only decodes to one byte.
Quote:
My bigger question is whether the result (with trailing equals stripped) is safe for naming aliases based on match pattern or if you have a better way.
Well you can't have "+" or "/" in names, so I guess not in any case.
I suggest you MD5 sum the match pattern, which will work for any length match pattern. Prepend a character (like "A") to the front in case the MD5 sum starts with a number, and "hey presto!" you are done! |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Fiendish
USA (2,558 posts) Bio
Global Moderator |
| Date
| Reply #2 on Sat 30 Mar 2013 10:58 PM (UTC) Amended on Sat 30 Mar 2013 11:00 PM (UTC) by Fiendish
|
| Message
| | Except that MD5, being a hash and not a byte conversion, does not prevent many-to-one matching. |
https://github.com/fiendish/aardwolfclientpackage | | Top |
|
| Posted by
| Fiendish
USA (2,558 posts) Bio
Global Moderator |
| Date
| Reply #3 on Sat 30 Mar 2013 11:02 PM (UTC) |
| Message
|
Quote:
Well you can't have "+" or "/" in names, so I guess not in any case.
And I'm wondering if this is a real problem, because I can't seem to find any Base64 output that actually contains them. |
https://github.com/fiendish/aardwolfclientpackage | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #4 on Sat 30 Mar 2013 11:18 PM (UTC) |
| Message
| For a start, the base64 approach could give you very long labels, especially as the base64-encoded stuff is 4/3 times the size of the original.
Just because you haven't seen "+" or "/" in output doesn't mean it won't happen. It would require certain combinations of adjacent bits for that to occur.
Whilst MD5 can have collisions, and they can even be deliberately caused with carefully constructed text, the likelihood of them randomly occurring is very low.
Remember, Git uses filenames internally which are the MD5 sum of their contents, and they aren't too worried about name clashes.
You could reduce the chance of collisions by appending the size to the hash (extra numbers at the end won't hurt). That way, two match strings would have to be the same length, and have the same MD5 sum, but differ in content, to cause a problem. I doubt you need to worry about it.
http://stackoverflow.com/questions/1323013/what-are-the-chances-that-two-messages-have-the-same-md5-digest-and-the-same-sha
To be safer you could use: utils.sha256 |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
13,417 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top