I'm using this encrypting function psoted by a member:

Public Function SimpleCrypt(ByVal Text As String)

        Dim strTempChar As String = ""
        Dim i As Integer
        For i = 1 To Text.Length
            If Asc(Mid$(Text, i, 1)) < 128 Then
                strTempChar = _
          CType(Asc(Mid$(Text, i, 1)) + 128, String)
            ElseIf Asc(Mid$(Text, i, 1)) > 128 Then
                strTempChar = _
          CType(Asc(Mid$(Text, i, 1)) - 128, String)
            End If
            Mid$(Text, i, 1) = _
                Chr(CType(strTempChar, Integer))
        Next i
        Return Text
    End Function

My problem is when i try to encrypt a string containing the number '5'.
On my database(oracle 11g r2 XE) the number 5 is encrypted as the letter M, but on VB it shows as µ. So when I compare the contents of the my password textbox to the one in my database, they won't match.

Dani AI

Generated

This is an encoding/charset problem rather than a numeric bug in the routine. The posted routine flips the high bit (adds 128) so the result is a character code > 127. VB.NET strings are Unicode, but the Oracle client/server and any intermediate drivers will convert characters according to their character sets. Characters above 127 can be mapped, converted or lost differently on each side, so the same byte sequence can appear as different glyphs in the VB UI and in Oracle.

Quick ways to diagnose

  • Ask Oracle what bytes it actually stored (the numeric values). For example:
SELECT DUMP(password_column) FROM your_table WHERE ...;
SELECT value FROM NLS_DATABASE_PARAMETERS WHERE parameter = 'NLS_CHARACTERSET';
  • In VB use Unicode-aware functions (AscW/ChrW) when you need codepoints, and examine the exact bytes with System.Text.Encoding before sending to the DB.

Fixes that work reliably

  • Stop storing arbitrary high-bit characters as text. Produce binary output and store it safely:
    • Store encrypted bytes in a RAW or BLOB column, or
    • Encode the bytes to Base64 (text-safe) and store that string. Base64 avoids charset conversion entirely.
  • Use .NET encoding and base64 helpers so storage is deterministic:
Dim raw() As Byte = Encoding.UTF8.GetBytes(yourBytesOrPlaintext)
Dim b64 As String = Convert.ToBase64String(raw)

And reverse with Convert.FromBase64String.

Security note and tieback to earlier suggestions

  • is right that this routine is very weak. pointed to alternative code — if you switch to a standard crypto API, combine it with Base64 or RAW/BLOB storage to avoid charset issues. For password storage prefer a slow, salted hash (PBKDF2/bcrypt/scrypt) rather than reversible homegrown "encryption" (see OWASP password storage guidance: Password Storage Cheat Sheet).

References: Microsoft docs for Unicode/byte handling and Base64 (see Convert.ToBase64String and System.Text.Encoding).

Recommended Answers

All 6 Replies

This encryption is at very basic level, best advice don't use it u can find more encryption Try . Actually this is in c# but you can easily converted to vb.net by online code converter.
Hope this will help you

You could try the encrypt/decrypt functions posted by sandeepparekh9 here

thank you!

can u please explain me the entire code?

It looks like it has been documented pretty thoroughly.

since m new to vb.net ...can u please explain me the entire code ?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.