James Sabre

Pat Farrell wrote:

James Sabre wrote:So by that token your correction to my key should be correct but it isn't . DES keys should have odd parity so your corrected key bytes should have been
{1, 2, 2, 4, 4, 7, 7, 8}

Yet your correction is still wrong, since DES ignores the lowest order bit. Your "7" is the same as my "6" and your "1" is the same as "0".

Details matter. Stop being an a**

The pot calling the kettle black!
byte[] keyBytes = { 1, 2, 3, 4, 5, 6, 7, 8 }; final DESKeySpec keySpec = new DESKeySpec(keyBytes); SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DES"); SecretKey key = keyFactory.generateSecret(keySpec); System.out.println(Arrays.toString(key.getEncoded()));

Pat Farrell wrote:

James Sabre wrote:Sorry Pat but that 'nit' is irrelevant in the context of this thread and is just a distraction.

Huh? Why this response?

Too many folks try to write crypto code from examples they pull from books or websites. They don't understand what they are doing, and don't understand any of the subtleties. Yet as this thread shows, its all about subtleties. So good example code should be correct. If you had used AES, the keys you used were OK, but they were wrong for DES. If you are claiming to be an expert, and complaining about irrelevant comments, then I think that your example code should actually be correct.

So by that token your correction to my key should be correct but it isn't . DES keys should have odd parity so your corrected key bytes should have been
{1, 2, 2, 4, 4, 7, 7, 8}

Many years ago when I wrote the example I deliberately kept it very very simple and linear. You could have criticised my exception handling and you could have criticised the fact that the key was stored in the code and I would have agreed with you but I would not have changed anything. To fix both of these would have taken the focus away from the heart of the code that shows that ECB block mode is unsafe because ciphertext can be spliced to create forgeries.

I still think your nit-pick is irrelevant to the original discussion. The OP was quite rightly worried about the fact that some of his ciphertext blocks in different messages were the same. I pointed out that this was a natural consequence of using ECB block mode and I provided a simple example that illustrated how his observation could be used to forge messages. To introduce the fact that I had not used the correct parity for the key bytes added nothing to the discussion and diverted attention away from ECB. I will let readers of this thread judge whether or not your diversion is relevant.

I have locked horns with you in the past and know that I don't have debating skills, the technical expertise, the will or the stamina to continue with this.

sai srinivas jonnalagadda wrote:no james.
because this logic is needed at many places where DB operations are not there.
I found one solution.
divide the input number by some big number (assumed to be maximum value of int) and then concat both quotient and reminder which is definitely be a unique number.

How can it be? There are an infinite number of big numbers and only 2^32 ints! You cannot make any simple manipulations of a big number that will create a unique int!

sai srinivas jonnalagadda wrote:
problem is i am doing some database operations with those numbers. the maximum limit for that column is 2power32 -1.. i cannot change the data type for that column
so, I must convert them uniquely into int sized values, so that i can insert them in tables.
I want a algorithm kind of thing which generates random unique number based on the digits of the input number.

There are an infinite number of large numbers and only 2^32 ints so you cannot possibly make the mapping unique just by simple manipulation. Since you already have a database then why not just use a database table mapping the big integers to the small integers. You can use auto-increment when inserting the big numbers.

sai srinivas jonnalagadda wrote:that is right. but I need a good approach of generating unique numbers.
i don't want to increment values from 0 blindly.

Why not! They are numbers and they are unique. There is obviously more to your requirement then you have said.

One possibility - create a map between the numbers and an int. Start the int values at 0 and increment each time you add a big number.

Raymond Tong wrote:
If you want to replace ALL without regular expression, try with \Q..\E sequence.

That is absolutely true and I considered posting this information but the OP seems not to understand even the minimum about regular expressions since he obviously did not recognise the most fundamental meta characters. The conclusion is that the OP just wants to replace literally and then what is the point of going to the trouble of parsing a regular expression when the replace() method will achieve the same result?

Pat Farrell wrote:
One nit on James' excellent explaination.

Sorry Pat but that 'nit' is irrelevant in the context of this thread and is just a distraction.

The first parameter to replaceAll() is a regular expression and in regular expressions the characters '(' ,')' and '*' are meta characters that have a special meaning. I suspect you just need to use the replace() method which takes the first argument literally.

Trevor Basden wrote:Here is the code I am using to initialize the Cipher. I'm unsure which mode of encryption is the default.

byte[] results = null; try { key = getKey(); secretKeySpec = new SecretKeySpec(key, algorithm); //algorithm = "AES" cipher = Cipher.getInstance(algorithm); cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec); results = cipher.doFinal(s); } finally { cipher = null; secretKeySpec = null; key = null; // empty everything for GC if (results == null) results = FAIL; //FAIL is a constant } return results;


Here are 3 encrypted... 32 bytes, 16 of which are the same each timeHex values. Original Strings are 16 characters long:
D2 C4 C3 5D 4C B2 BE C9 A8 C7 5F F4 B9 C1 0C 51 20 CD 06 16 4C 68 F5 F2 15 B1 22 E0 D0 14 EA F0 F6 97 85 22 B6 F5 4A 88 23 10 12 D3 20 80 A5 FF 20 CD 06 16 4C 68 F5 F2 15 B1 22 E0 D0 14 EA F0 39 B4 9E 42 39 DF D6 01 4B 6D 49 CB 74 36 2E 59 20 CD 06 16 4C 68 F5 F2 15 B1 22 E0 D0 14 EA F0

This code
cipher = Cipher.getInstance("AES");
actually gives you
cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");

As I said in my previous reply, ECB is generally not a good idea since it allow the splicing of ciphertext to forge valid ciphertext. You need to use one of the block modes such as CBC with a random IV.

The problem with using a random IV is that it has to be stored with the ciphertext and is a block long. For AES this means 16 byte extra with every ciphertext on top of the padding that must be applied. Using AES with CBC and PKCS5 padding means that your ciphertext is therefore between 17 (there is always at least 1 byte of padding) and 32 bytes longer than the bytes of the cleartext. There is nothing secret about the random IV so it is normal to write it as a prefix to the ciphertext so that it can be used in the decryption process.

If you don't specify the IV when initialiing then using
cipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec);
automatically generates a random IV for you which you can get from the Cipher using the method
byte[] getIV()
and you can prefix your doFinal() result with this.

When you come to decrypt then you must first read the IV and use that to initialise the decryption cipher. You can then decrypt the remainder using the doFinal() of the decryption cipher.

If you follow this approach you will get a different value for the ciphertext (see note) for a given cleartext every time you use it.

My standard example of forgery using ECB mode with DES (simple enough to modify to forge using AES as long as you have a long enough message)

import javax.crypto.Cipher; import javax.crypto.SecretKey; import javax.crypto.spec.SecretKeySpec; public class ForgeryThroughSplicingUsingECB { public static void main(String[] args) throws Exception { final String plaintext1 = "Pay Fred £100.00"; final String plaintext2 = "Pay Bill £10.00"; final SecretKey key = new SecretKeySpec(new byte[] { 1, 2, 3, 4, 5, 6, 7, 8 }, "DES"); Cipher cipher = Cipher.getInstance("DES/ECB/PKCS5Padding"); cipher.init(Cipher.ENCRYPT_MODE, key); final byte[] ciphertext1 = cipher.doFinal(plaintext1.getBytes("UTF-8")); final byte[] ciphertext2 = cipher.doFinal(plaintext2.getBytes("UTF-8")); final byte[] splicedCiphertext = new byte[ciphertext2.length]; for (int i = 0; i < 8; i++) { splicedCiphertext[i] = ciphertext2[i]; } for (int i = 8; i < ciphertext1.length; i++) { splicedCiphertext[i] = ciphertext1[i]; } cipher.init(Cipher.DECRYPT_MODE, key); final String splicedPlaintext = new String(cipher.doFinal(splicedCiphertext), "utf-8"); System.out.println("Forgery = " + splicedPlaintext); } }


Note - not strictly true since the secure random number generator could give the same result for two IVs but it is very much against the odds. You would need about 256 ^ 8 random IVs to have an even chance of getting a duplicate pair of IVs (the Birthday paradox).

Hunter McMillen wrote:The OP doesn't want to exit the loop, they want to catch the exception inside so they can continue iterating through the rest of the data.

Hunter

Looks like I misunderstood "exception is thrown in this case due to an invalid stat the loop could not continue with the processing the other valid stats". I took it to mean that the OP did not want to continue processing the other 'valid stats' but on re-reading I see that it can be read as meaning he did want to continue.

Catching an exception inside a loop is hardly innovative or novel.

You need to study http://download.oracle.com/javase/tutorial/essential/io/ and to look at the Javadoc for class java.io.File method mkdirs() .

ram bandakunta wrote:I searched for a solution where there was an exception thrown in a while loop or for loop,in this case i was using an iterator. when the exception is thrown in this case due to an invalid stat the loop could not continue with the processing the other valid stats, all i had to do was to put a try catch inside the for loop .......

I'm not sure this makes sense. If uncaught in the loop, an exception thrown inside the loop will automatically cause the loop to exit; no need to catch it inside the loop. What am I missing?

ram bandakunta wrote:Hi I wanted post the solution for the isuue i faced ,I do not have any question.

It's not obvious to me what the issue that you faced is!

varun nurav wrote:
please help !!

With what? You have posted this in the JDBC forum but I see nothing to do with databases. You have given an outline of a system but don't say what you are having trouble with. It seems to me you would benefit from going through the Java tutorial - http://download.oracle.com/javase/tutorial/ . Start at the "Getting Started" section and progress from there.