1

I'm using Base64 for encode a very huge JSON string with thousands of data, after encoded I'm storing on disk. Later I'm retrieving again from disk and decoding it again into readable normal string JSON.

public static String encryptString(String string) {     
    byte[] bytesEncoded = Base64.getMimeEncoder().encode(string.getBytes());
    return (new String(bytesEncoded));
}

public static String decryptString(String string) {
    byte[] bytesDecoded = Base64.getMimeDecoder().decode(string);
    return (new String(bytesDecoded));
}

Does a limitation exist in the size of the Base64 encode and decode functions? Or am I able to encode and decode super big strings?

halfer
  • 19,824
  • 17
  • 99
  • 186
NullPointerException
  • 36,107
  • 79
  • 222
  • 382
  • 2
    No, other than the memory needed to store all these characters in memory. But Base64 is by no means an encryption method, and there's no reason to name your method encryptString() and to use it at all. Why don't you store the JSON directly on disk? – JB Nizet Mar 13 '19 at 09:47
  • 2
    Why would you do that? Base64 is meant as a way to represent binary data in text. Since your source is text, it's not useful. Base64 is *not* an encryption. – RealSkeptic Mar 13 '19 at 09:47
  • @JBNizet I need to store the data in a non human readable way, because it's personal data, I tryed to using google Tink to encrypt but is too much complex for this simple operation, before i was using jasypt, but now it's deprecated, so i opted for encoding it into base64. Now the json is stored in a non human readable style. You have a better alternative which is not super complex as Tink? – NullPointerException Mar 13 '19 at 09:50
  • @RealSkeptic read my previous comment please – NullPointerException Mar 13 '19 at 09:51
  • *ignoring the naming of methods* There no as such limit, but the IO operations can take serious time to produce results. Regarding sizes, you can read a similar answer explaining that [Base64 encoded data maximum size](https://stackoverflow.com/a/7609180/11065438) – Pushkar Adhikari Mar 13 '19 at 09:51
  • 3
    Base64 is human-readable. Any script-kiddie can take it, decode it and read it. A script kiddie is a human. If you don't want it to be readable, choose a good password, derive a secret key from that password using a proper cryptographic password-based encryption algorithm, and encrypt it. – JB Nizet Mar 13 '19 at 09:52
  • @PushkarAdhikari the title is similar but the content is very different. How much time whould take a json of 10 kb for example? – NullPointerException Mar 13 '19 at 09:52
  • Side note: You are converting bytes to a string and vice versa without specifying an encoding. Don't do that! – Seelenvirtuose Mar 13 '19 at 09:52
  • @Seelenvirtuose the string is in UTF-8, what should i add to the code to not generate problems? I tested it with rare chars and it worked fine – NullPointerException Mar 13 '19 at 09:54
  • Then why not specifying UTF-8 as the encoding? – Seelenvirtuose Mar 13 '19 at 09:54
  • @JBNizet if you need to use a machine/program for decoding it then it's not human readable, and this personal data are not super secret data, just names and a little more – NullPointerException Mar 13 '19 at 09:55
  • You have to pass `utf-8` **expilicitly** to the `getBytes()` and `new String()` - otherwise, if you run it when the default encoding is *not* `utf-8`, you will run into problems. – RealSkeptic Mar 13 '19 at 09:56
  • @RealSkeptic please can you post a sample code with the specified UTF8 in the correct places? – NullPointerException Mar 13 '19 at 09:58
  • Just to be clear, what you'll have with base64 is a protection against people who want to access your data, but are not savvy enough to see that it's base64 encoded, google for "online base64 decoder", copy and paste the text, and hit submit. You don't even need to know how to program to read base64. – JB Nizet Mar 13 '19 at 09:59
  • @JBNizet yes I understand it, but google Tink is super complex for this easy and simple requirement and operation, and jasypt is deprecated, so in this case use google Tink for encrypt is similar to kill flies with cannons. So if doesn't exist a simple and easy alternative is much better to simply encode it, as this is not crytical data like credit cards or similar. If you have a better alternative with simple implementation tell me. – NullPointerException Mar 13 '19 at 10:01
  • 1
    In a larger context, if you end up saving Base64 personal data that gets leaked or accessed, it puts users of your program at risk. *All data is important* – Pushkar Adhikari Mar 13 '19 at 10:02
  • creating a password protected file may be a good idea rather than processing a large data – Akash Shah Mar 13 '19 at 10:07
  • If you want this data to be protected, proper crypto is the way. You can just use your OS to encrypt the disk partition where you store that. And protect your OS by a password. If it's OK to be readable by someone just able to identify that it's base64, then just write it in clear text, because protecting with base64 is basically equivalent to no protection at all. – JB Nizet Mar 13 '19 at 10:07
  • @JBNizet what do you think about the answer proposed by Pushkar. Is cipher a good option? is not deprecated? is recommended for the new java versions? – NullPointerException Mar 13 '19 at 10:09
  • Cipher is the standard Java class used to encrypt/decrypt data. So yes, it's *the* good option. Now, the code in the answer has many problems (it doesn't correctly transform strings to bytes and vice versa, and doesn't deal with exception in a good way). But it's on the right track. – JB Nizet Mar 13 '19 at 10:12
  • @JBNizet doesn't correctly transform strings to bytes and vice versa? please, can you post a correct answer or edit his answer? thank you very much – NullPointerException Mar 13 '19 at 10:20
  • @JBNizet I concur your view on my answer. but I was doing exactly what you say. showing a way, not the best way though. – Pushkar Adhikari Mar 13 '19 at 10:20
  • @NullPointerException he refers to the same encoding part he said before. Check this [SO answer](https://stackoverflow.com/a/1536123/11065438) – Pushkar Adhikari Mar 13 '19 at 10:21
  • I have updated the answer with @JBNizet 's suggestion. – Pushkar Adhikari Mar 13 '19 at 10:36

1 Answers1

1

No maximum size, but I'd like to also suggest different approach to encrypt and decrypt

Encrypt

public static String encrypt(String strClearText,String strKey) throws Exception{
    String strData="";

    try {
        SecretKeySpec skeyspec=new SecretKeySpec(strKey.getBytes(),"Blowfish");
        Cipher cipher=Cipher.getInstance("Blowfish");
        cipher.init(Cipher.ENCRYPT_MODE, skeyspec);
        String isoText = new String(strClearText.getBytes(StandardCharsets.UTF_8), StandardCharsets.ISO_8859_1); // there are shorthand ways of doing this, but this is for your explaination
        byte[] encrypted=cipher.doFinal(isoText.getBytes(StandardCharsets.ISO_8859_1));
        strData=Base64.getEncoder().encodeToString(encrypted);

    } catch (Exception e) {
        e.printStackTrace();
        throw new Exception(e);
    }
    return strData;
}

Decrypt

public static String decrypt(String strEncrypted,String strKey) throws Exception{
    String strData="";

    try {
        SecretKeySpec skeyspec=new SecretKeySpec(strKey.getBytes(),"Blowfish");
        Cipher cipher=Cipher.getInstance("Blowfish");
        cipher.init(Cipher.DECRYPT_MODE, skeyspec);
        byte[] decrypted=cipher.doFinal(Base64.getDecoder().decode(strEncrypted));
        isoStrData=new String(decrypted, StandardCharsets.ISO_8859_1);
        strData=new String(isoStrData.getBytes(StandardCharsets.ISO_8859_1), StandardCharsets.UTF_8);
    } catch (Exception e) {
        e.printStackTrace();
        throw new Exception(e);
    }
    return strData;
}

key can always be a constant in your program, but it is not recommended.

Pushkar Adhikari
  • 510
  • 2
  • 9