Recent Posts

Hi George,

At this time, no further HIME developments are planned.

Kind regards
Eddy

I was curious if there was any thoughts of implementing PBKDF2 functionality to allow native salted, multi-iteration hashes.

Hi,
The returned answer is correct. What did you expect it to be ?

Kind regards
Eddy

[hi_bin]

i'm newbie in programming.
i was use HIME unit in Delphi 7 to convert Huge Integer to binary number. But when i use the huge format, hi_bin, the result doesn't right convertion.

sample of code that i used:

Hime.PutReg(1, Memo1.Lines.Text, hi_Dec);
Memo3.Lines.Text := Hime.GetReg(1, hi_Bin);

for simple integer like "4" will result right answer :  "00000000000000000000000000000100"
but when the input is big integer like "681625562253729757562" will result wrong answer : "000000000000000000000000001001001111001101110100011101010111011001110111011110000111100101111010"

i use huge integer in my thesis about steganography in gif image.

how to solve that problem...

please help me....

Eddy

Wow, thanks for the info.



Peter

[mantissa * 256^exp]

I was not aware you already had a Forum which is great.

Hi Peter,

Good to hear from you.
Yes, I set up the forums some time ago but I did not make much publicity about it.
Perhaps I should send all my customers a notification mail.
Anyway, glad you found it ! 

Just a question regarding NUMS, ... its capabilities and what other features you are looking at implementing ?

NUMS is a mathematical library (a dll) I am developing now for arbitrary precision floating point and signed big integer calculations.
As you know, HIME has math functions for unsigned huge integers, but I got requests from users for adding floating point math functions.
Rather than to add such functionality in HIME, I chose to develop a new product, called NUMS.

NUMS is based on the same huge integer math kernel as HIME.
But NUMS can handle variables in 5 different data types: 4 numerical data types and a dynamic string data type:


1. "BinFloat", Binary base Arbitrary Precision Floating Point data type
This data type stores numbers in the format:

   mantissa * 256^exp

• 'mantissa' is a signed binary number of which the maximum length can be determined by the user. It can be upto 2^31 (2147483648) bits long. That is the equivalent of 646 million decimal digits !
• 'exp' is a binary number ranging from -2147483648 to +2147483647 ( -2^31 to 2^31 - 1)

2. "DecFloat", Decimal base Arbitrary Precision Floating Point data type
This data type stores numbers in the format:

   mantissa * 10^exp

This is a floating point number, simular to the BinFloat data type, except it is base 10.

• 'mantissa' is a signed binary number of which the maximum length can be determined by the user. It can be upto 2^31 (2147483648) bits long.
• 'exp' is a binary number ranging from -2147483648 to +2147483647 ( -2^31 to 2^31 - 1)

3. "Rational", rational number data type
This data type stores numbers in the format:

   nominator / denominator

• 'nominator' is a signed binary huge integer number. It can be upto 2^31 (2147483648) bits long.
• 'denominator' is an unsigned binary huge integer number. It can be upto 2^31 (2147483648) bits long.

So, a rational number consists (internally) always of 2 integer numbers.
 

4. "BigInt", big integer data type
This data type stores numbers in the format:

   big integer

• 'big integer' is a signed binary huge integer number. It can be upto 2^31 (2147483648) bits long. That is the equivalent of 646 million decimal digits !

5. "String", string data type
This data type stores alphanumerical string data upto 2^31 (2147483648) bytes long.

 

PROS AND CONS OF THE VARIOUS DATA TYPES

BinFloat
+ Fast math operations
- Possibility for base conversion errors when converting to and from decimal (No base conversion errors when converting to and from hexadecimal or binary).

DecFloat
+ No base conversion errors when converting to and from decimal.
- A little more overhead during math operations compared to BinFloats.

Rational
+ No rounding errors for +, -, *, / 
- Generally, slower math operations compared to above data types.

BigInt
+ No rounding errors when used for integer operations.
- Only suitable for integer number math.

 
NUMS is still under development. Functions implemented so far are:

• Basic math functions: +, -, *, /, e^x, LOG, x^2, square root, ABS, FIX (INT), FRAC
• Boolean functions:  =, <>, >, >=, <, <=,  CMP, IsZero
• Various functions to exchange data with NUMS
• Support functions to convert numbers between the various data types, set precision, etc.

Functions that are in preparation and will be added to the first release:

• x^y, LOG2, LOG10
• Trigonometric functions: SIN, COS, TAN, ASIN, ACOS, ATAN, SINH, COSH, TANH, ASINH, ACOSH, ATANH
• Pow, PowMod, Mod, ModInv for integers
• Matrix calculation functions

If you like to know more, just ask.

Kind regards
Eddy

 

Hi

I was not aware you already had a Forum which is great.

Just a question regarding NUMS, can you give us a bit of a description of its capabilities
and what other features you are looking at implementing ?


PM

[by reference]

Hi Theo,

Welcome on these forums !

HIME function parameters are passed (to HIME) by reference (and not by value). I think that this is the cause of your problem.
If a function parameter is passed by reference, the (HIME) function receives an address of the parameter and not the actual parameter value itself.
If you pass a parameter by value, its value is passed to HIME but HIME expects an address and interpretes the parameter value as an address.
That is why the error message reports "Read of address 00000003.". Probably, your function call passes the parameter value of 3, and HIME thinks that this is an address and tries to fetch the parameter at that address, which causes the access violation because that address does not belong to your program space.

So, please retry by passing the parameters to the HIME functions by reference.
I believe in Delphi this is done by using the "var" keyword in your function declarations.

Could you let me know if that did the trick ?   

Kind regards
Eddy

Greetings, I am a Delphi 2006 user and I am having trouble using Hime.dll .

First of all I used the HimeLib.pas given in the delphi example (made by Joγo Inαcio) and the only thing I added was a wrapper for hi_Hex2Huge in order to be able to use hex strings.

So far I've been able to put string data in HIME registers and retrieve them in order to validate that the contents of the registers are correct. The problem is that whenever I call one function (eg. hi_PowMod) the program gives me an "Access violation at address 004D11AE in module 'hime.dll'. Read of address 00000003." error.

I used the same data at your HIMEworkbench and it completed successful so I guess I am doing something wrong.

my function looks like that:

function MyPowMod(s1,s2,s3: String): String;
begin
  Hime.PutReg(1,s1,hi_Hex);
  Hime.PutReg(2,s2,hi_Hex);
  Hime.PutReg(3,s3,hi_Hex);
  Hime.HugePowMod(1,2,3,4);
  result:=Hime.GetReg(4,hi_Hex);
end;

Thanks for any help in advance

My P, Q and e values are from a know good RSA key, hence I should be able to calculate all the other components from these.

Gwyn,
That is correct.

Meanwhile, just thinking out loud:

• Is your plaintext pure ascii string or is it binary (perhaps containing possible zero bytes) ?
• After encryption, do you retrieve the ciphertext from HIME to restore it later in HIME, or do you just leave it in the HIME register ?
• Truncation: is you decrypted ciphertext (which should normally match your original plaintext) actually truncated (chopped off) or does it contain a series of correct characters/bytes and, following that, a series of incorrect characters ? From your first post I assume the latter, but it has me a little confused with 'truncation' 

Kind regards
Eddy