Good to hear from you too Michael.. I’m back in the downtown area these days – 
haven’t worked in this area since we last worked together at Nomura about 7 
years ago. Time flies eh? I’m about 2 or 3 blocks away from there and even 
intend to take lunch at some of those restaurants from that area when the 
weather gets a little more forgiving..

I’m still into Remedy work a bit of consulting and some developing. I kind of 
miss some of the older work we used to get that involved more development than 
customization. I had stayed away from ITSM kind of projects for the longest 
time, until I realized that if I kept staying away from it, I might soon have 
to start looking at an alternative solution to work with. I've had very brief 
opportunities to work with some complimentary products, but stayed with the 
mainstream Remedy products mostly.

As you may have figured out from some of my recent posts, I am currently 
working on an integration effort between Remedy and OIM (Oracle Identity 
Management) using their SPML (web services). I had a sticky pitch for a while, 
but it turned out it was because of some configuration settings from the OIM 
side. They (OIM admins) still haven’t figured out what that discrepancy might 
be but I’ve asked them to investigate the difference between a now working 
instance and the older non working one. This I figure would be useful 
information to have later while building the other production and training 
environments at this site..

Anyways getting back on topic, I’m yet to determine what length I may need to 
hold my encrypted string that holds the OIM configuration password... I have 
currently set it to 120 and for now will resort to the good old trial and error 
method, in the absence of the exact formula to use to determine it. OIM allows 
passwords of no more than length 8 and I have noticed that using an encryption 
key of length 38, a GUID, returns outputs of length averaging in between 75 to 
80.. So I created a field of length 120 to store that, hoping it would not 
cross that value.

Cheers

Joe

From: Michael Latham 
Sent: Monday, April 23, 2012 9:48 AM
Newsgroups: public.remedy.arsystem.general
To: arslist@ARSLIST.ORG 
Subject: Re: Working with ENCRYPT() function...

** 
I have been good Joe.  Just doing the usual Remedy consultant thing. And you?  
I see you are an arslist superstar by looking at your post history.  Cool that 
you stay involved with the community so much.  I wish I had the time!  Take 
care man and stay in touch! 

Mike



--------------------------------------------------------------------------------
Date: Fri, 20 Apr 2012 18:06:38 -0400
From: jdso...@shyle.net
Subject: Re: Working with ENCRYPT() function...
To: arslist@ARSLIST.ORG

** 
Yes I was interested in the character count as if I encrypted the input, I’d 
need to consider enough room for storage. I was tempted to build a 254 
character field to store it, but then curiosity got the better of me and I 
wanted to know if there was an algorithm to calculate the expected length of 
the encrypted text..

Yes I do remember you from Nomura. How have you been. 

Thank you for the info.. something that I can digest over the weekend..

Joe

From: Michael Latham 
Sent: Friday, April 20, 2012 5:47 PM
Newsgroups: public.remedy.arsystem.general
To: arslist@ARSLIST.ORG 
Subject: Re: Working with ENCRYPT() function...

** 
Hey Joe -

How have things been since Nomura - if you remember me from that project and 
you are in fact the same Joe De'Souza.  

To move along, encryption algorithms vary.  If I am not mistaken Remedy ARS 
uses DES block-cipher encryption in the ENCRYPT function.    DES in and of 
itself is symmetric from an algorithm standpoint. It uses one 64-bit key to 
encrypt a block of plaintext that is 64-bits into ciphered text.  It has one 
parity bit for each byte of the provided key which generates a key strength 
which is only 56-bits.



  Per BMC Documentation:

"The output is limited to the size of the field used for output, including the 
base-64 encoding.
Therefore, you are limited to encrypting a string that is 3/4 the size of the 
output field."

Using the passphrase method as a way to generate the encrypted text is achieved 
using, most probably, a key derivation and salt combination.

In order to decrypt ciphered text you would need to "code" an external DES 
ciphering utility in your language of choice that would encrypt the plain text 
based on the key provided or decrypt the ciphered text using the key provided.  
As long as you have the key you can go back and forth with the 
encryption/decryption.


By the way, why do you need to know the length of the output string?  I am 
assuming when you say length you mean character count or something similar.


Mike








--------------------------------------------------------------------------------
Date: Fri, 20 Apr 2012 13:48:37 -0400
From: jdso...@shyle.net
Subject: Working with ENCRYPT() function...
To: arslist@ARSLIST.ORG

** 

Is there a known algorithm to calculate the length of the output results of 
ENCRYPT based on the length of the input string and the encryption key 
parameters?

I vaguely remember that the length is 120. Or is that only the length of the 
encrypted value in Field 123?

Also how would one decrypt the contents of Field 123 if that is used for 
storing a password that is used for authenticating into an external app or wsdl?

Joe

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"

Reply via email to