How secure is this

Question

To make this more applicable to other people I want to know how realistic it is the write code that will encrypt a message to the point where it is unlikely to be decrypted without the password. I figured the best way to do this was making hash algorithms and adding randomness. So how realistic is it for a code amateur to write sound encryption? Would any engineer be able to crack amateur encryption algorithms? EDIT: several of the answers have discussed attacks on the memory of computer which is useful information that I appreciate but I am more interested in knowing if the message can be decrypted directly. I assume the cryptoanalyser does not have access to the computer the obfuscated the message because if he did he could just look at my source code anyway and find the decryption algorithm. Here is my example:

public class Keys { // hold the methods and information used to lock, unlock, make the key, get the "keypad" after it has been locked, and a static method to change int[] to long[] 
// Fields
private String passphrase;
private long[] key;
private long keynum;
private long[] pad;
Random rands = new Random();
// Constructors
public Keys (String passphrase) // makes a key based of the given passphrase 
{
    this.passphrase = passphrase;
    key = keycipher(this.passphrase.toCharArray());
    key = keyfix(key);
    keynum = key[0];
    for (int i=1; i < key.length && key[i] != 0; i=i+1)
        if (i <key.length -1 && key[i] == key[i+1])
            keynum = keynum *key[i] +1;
       else if (i+1 < key.length)
        keynum = keynum * key[i] - key[i+1];
    else
            keynum = keynum * key[i] -1;
}

/**
 *used to lock and save a message in the pad field 
 * @param message2lock the input which will be locked using the key and saved as the field pad 
 */
public void lock (String message2lock)
{
   Message2Num holenums = new Message2Num(message2lock); // message2nums converts inout string to number []
   holenums.step1(); //uses custom cipher to change each character to a long 
   long[] hole =new long[holenums.step2().length];

   int t =0;

    for(int g : holenums.step2()) 
        /* // Step 2 uses the cipher from step 1 and hides it in random numbers by doubling the array length
        then making every even number in the array length a random number and every odd number the last random number 
        minus the original cipher number            
        */
    {
        hole[t] = (long) g;
        t++;
    }        
    hole = this.padding(hole);

    double p = (double) keynum;
    p = 3* Math.cos(p);
    long z = (long) p;
    for ( int i =0; i< hole.length; i++)
        hole[i] = hole[i] * keynum + z;
    hole = Message2Num.addcommas(hole);
    pad =hole;

}

*"How secure is this"* ... `private String passphrase;` ... not really secure. (http://stackoverflow.com/questions/8881291/why-is-char-preferred-over-string-for-passwords-in-java) — Tom, May 19 '16 at 13:38
["Schneier's Law"](https://www.schneier.com/blog/archives/2011/04/schneiers_law.html): "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break." So the answer is that it is not realistic to write your own encryption code. The best suggestion is to use the current standard: AES (Advanced Encryption Standard). For converting a password to a key use PBKDF1 (Password Based Key Derivation Function 2). — zaph, May 19 '16 at 13:40
This sort of thing should never be done for real systems, please please please stick to official functions that have accepted security and never use your own functions for security unless you really know what you're doing! — Scott Stainton, May 19 '16 at 13:40
@Tom Thanks! So I use a JTextField to get the String if instead of pulling string I pull String.tochar or whatever the method is will it be more secure or does the string issue make JTextFields insecure? — Czarking, May 19 '16 at 13:44
@zaph Yes I know about encryption standards like AES and such. This program is made for me and my friends to share secret data from one computer to another. Originally i tried using AES but I could not figure out how to send the key so I could decrypt on another computer :/ — Czarking, May 19 '16 at 13:46
@zaph well the fundamental problem with symmetric encryption is both users need to know the password and so eventually the password needs to be sent through an unsure channel and idk how to share an AES key through an unsecured channel. Or may I do not know enough about AES and my questions do not make sense. — Czarking, May 19 '16 at 14:00
If you want to get a password from the user using Swing, then use `JPasswordField`. — Tom, May 19 '16 at 14:01
The password does **not** need to be sent through an insecure channel. Even with asymmetric encryption the data is generally encrypted with symmetric encryption and the key the encrypted with asymmetric encryption. — zaph, May 19 '16 at 14:07
@zaph also in response to "Schneier's Law" perfect encryption is possible and will mostly likely happen in my lifetime due to quantum encryption. Anyone with a masters degree in quantum computing will one day be able to write unbreakable encryption algorithms. Or at least that's the goal — Czarking, May 19 '16 at 14:08
@zaph ok that makes sense. So if make an AES key with a password then someone on a different computer makes an AES key with the same password we would be able to decrypt each other's messages ? — Czarking, May 19 '16 at 14:10
Yes, that is the common method. PBKD2 adds a salt that can be shared publicly and adds iterations to make the operation slow. The salt and iteration count can be prepended to the encrypted data. — zaph, May 19 '16 at 14:13
The point to "Schneier's Law" is that substantial peer review is required, that is exactly what happened with AES. Also, do not assign to much weight to a masters degree or even PhD, I worked for years in an environment where a PhD or MD was a minimum requirement and they do not guarantee much. — zaph, May 19 '16 at 14:17

score 7 · Answer 1 · answered May 19 '16 at 13:45

Without looking at your code - two answers to two questions:

So how realistic is it for a code amateur to write sound encryption?

Unrealistic. Even professional cryptographer's implementations constantly get attacked, exposed, weakened. Apart from the math that needs to be solid, side channel attacks (e.g. in timing, power consumption) are possible and you might have leakages of data left over in memory.

In short: It's not worth implementing your own encryption unless this is specifically your business. Just use the existing implementations. If they have flaws, they'll have less flaws that your own and will be updated.

Would any engineer be able to crack amateur encryption algorithms?

Yes. Just yes. Because you will make rookie mistakes. Enough people have burnt their fingers on inappropriate implementations of encryption algorithms. Don't add yourself to the list.

If you do - don't call it encryption, rather name it obfuscation. This'd be something that an amateur can do "safely"

score 4 · Answer 2 · answered May 19 '16 at 13:46

"Schneier's Law": "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break."

So the answer is that it is not realistic to write your own encryption code, even if you are a experienced cryptographer.

The best suggestion for encryption is to use the current standard: AES (Advanced Encryption Standard).

For converting a password to a key use PBKDF2 (Password Based Key Derivation Function 2).

score 2 · Accepted Answer · 2016-05-19T14:00:13.313

There's a general advice on cryptography: don't roll your own, but use publicly available algorithms. This is for a pretty simple cause: even professionals are quite prone to mistakes, so it's recommended to only use algorithms that were widely tested. In addition, beginners are even more prone to make mistakes.

For example, let's consider your code:
private String passphrase;: You're using a String to store the password, so it'll remain in memory quite a time, even after it's not in use any more, and even longer due to the fact, that it's a attribute of an Object.

Only every second value contains actual data: that's "security through obscurity". Bad idea, as already Kerckhoff stated. In addition it's useless overhead, since it's pretty easy to revert the final executable to get the actual code.

The actual data is a string of randomnumber - actual data: Let me guess: Math.random(), or Random.nextInt()? That's not a cryptographical secure PRNG. In other words: another attack-vector to break the encryption.

Adding z to the overall result is a nice idea, except for one problem: z always lies in the range [-2, 2] and thus won't add much of security to the algorithm. At best case this would increase the effort by a factor of 5, while adding additional overhead to the algorithm and thus leaving data even longer in the RAM.

Encrypting everything at once: this gives the attacker more than enough time to get hold on both plain- and ciphertext, since during that time, all the data that should be encrypted remains in memory. Only thing that could be worse is the directly hand the key to the attacker.

This would only be a start of the list, and all of these attack-vectors are based on the pretty incomplete code you posted and extremely severe. Breaking this algo would be a child's play for any professional.

TL;DR

Never use your homemade cryptographic algorithms for anything security relevant. They're extremely errorprone and thus in most cases - especially when built by a beginner - pretty simple to break.

yes i used math.random() and yes I know about Secure Random just wasn't feeling it. I am assuming though that Eve only has the message output not my computer — Czarking, May 19 '16 at 14:05

score 1 · Answer 4 · answered May 19 '16 at 13:46

1

This is not secure. Don't do it. I would consider this professional malpractice.

Instead research and use standard symmetric or asymmetric cryptography.

answered May 19 '16 at 13:46

Brian Ensink

11,092
3
50
63

How secure is this

4 Answers4

TL;DR