[qwertyuu]

AdamSpeight2008, on 14 August 2012 - 01:29 PM, said:

Not sure of what uint is. Then a useful skill to learn in Research.

Check the C# Documentation on MSDN

yep, went on google and found it right away... thanks for the whole Table, been searching this for a while!

So if I get it right, it's like an int32... but values are shifted so the minimum value is 0?

but, why would I use this... if my encrypted password is very very secure and goes over the 4,294,967,295 limit?

[Skydiver]

The point I was trying to make was that instead of using IntX.Parse(a) that you use IntX.Parse(a, 10) to force IntX to use base 10 parsing instead of its current behavior of detecting based on the leading characters.

This post has been edited by Skydiver: 14 August 2012 - 01:55 PM

[Skydiver]

As a side note, I hope that you do know that by limiting your cleartext alphabet to the values 10-35, 40-49, and 36 you are narrowing the search space for an attacker and thereby making it easier to try to break your encryption. Yes, I know that are only just experimenting with encryption, but this is something to bear in mind.

[qwertyuu]

Skydiver, on 14 August 2012 - 01:54 PM, said:

The point I was trying to make was that instead of using IntX.Parse(a) that you use IntX.Parse(a, 10) to force IntX to use base 10 parsing instead of its current behavior of detecting based on the leading characters.

Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhhhhhhhhhh!
And this... would work for encrypting and decrypting on the other side? Say I create a decrypter that took the base 10 value and reversed the maths... would I still have the 0112 as a result?

[Skydiver]

qwertyuu, on 14 August 2012 - 02:00 PM, said:

Skydiver, on 14 August 2012 - 01:54 PM, said:

The point I was trying to make was that instead of using IntX.Parse(a) that you use IntX.Parse(a, 10) to force IntX to use base 10 parsing instead of its current behavior of detecting based on the leading characters.

Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhhhhhhhhhh!
And this... would work for encrypting and decrypting on the other side? Say I create a decrypter that took the base 10 value and reversed the maths... would I still have the 0112 as a result?

That is only for parsing.

I've not dug into the IntX to see if there is a way to tell it to put leading 0's to pad numbers when converting from its internal representation to a string. At best, you'll get the value 112. The question is if you'll be able to generate the string "0112" again from the 112 value.

[qwertyuu]

Skydiver, on 14 August 2012 - 02:03 PM, said:

qwertyuu, on 14 August 2012 - 02:00 PM, said:

Skydiver, on 14 August 2012 - 01:54 PM, said:

The point I was trying to make was that instead of using IntX.Parse(a) that you use IntX.Parse(a, 10) to force IntX to use base 10 parsing instead of its current behavior of detecting based on the leading characters.

Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhhhhhhhhhh!
And this... would work for encrypting and decrypting on the other side? Say I create a decrypter that took the base 10 value and reversed the maths... would I still have the 0112 as a result?

That is only for parsing.

I've not dug into the IntX to see if there is a way to tell it to put leading 0's to pad numbers when converting from its internal representation to a string. At best, you'll get the value 112. The question is if you'll be able to generate the string "0112" again from the 112 value.

The thing is... if I don't have this 0 value on decryption, it may crash or shift the values so at some point I don't have the right letters showing up
This means... I should totally eradicate the 0's so I don't have to mess with the "is there a 0 there, or is there nothing at all?".