پروتکل Millicent برای تجارت الکترونیکی ارزان قیمت

چکیده: Millicent یک پروتکل سبک و ایمن برای تجارت الکترونیکی از طریق اینترنت است. این طراحی برای پشتیبانی از خریدهای کمتر از یک درصد طراحی شده است. این مبتنی بر اعتبار غیر متمرکز پول نقد الکترونیکی در سرور فروشنده بدون هیچ گونه ارتباط اضافی ، رمزگذاری گران قیمت یا پردازش خارج از خط است.

نوآوری های کلیدی Millicent استفاده از کارگزاران و اسکریپت است. کارگزاران از مدیریت حساب ، صورتحساب ، نگهداری اتصال و ایجاد حساب با فروشندگان مراقبت می کنند. اسکریپت پول نقد دیجیتالی است که فقط برای یک فروشنده خاص معتبر است. فروشنده به صورت محلی اسکریپت را برای جلوگیری از کلاهبرداری مشتری ، مانند هزینه های مضاعف ، تأیید می کند.

واژه‌های کلیدی: تجارت الکترونیکی ، پول نقد الکترونیکی ، اسکریپت ، کارگزار ، احراز هویت

فهرست

• پیش زمینه تجارت الکترونیکی
• دلهره
• امنیت و اعتماد
  • مدل اعتماد
  • امنیت
  • ساخت اسکریپت
  • اعتبار سنجی و انقضا
  • خواص
  • اسکریپت را روشن کنید
  • خصوصی و ایمن
  • ایمن بدون رمزگذاری
  • انبار
  • تولید اسکریپت دارای مجوز
  • کارگزاران چندگانه

  تعدادی پروتکل موجود و پیشنهادی برای تجارت الکترونیکی وجود دارد ، مانند مواردی از Digicash [2] ، بازار آزاد [14] ، Cybercash [1] ، اولین مجازی [3] و NetBill [12]. همه آنها برای معاملات متوسط تا بزرگ ، 5 دلار یا 10 دلار و بالاتر مناسب هستند ، زیرا هزینه های هر معامله به طور معمول چندین سنت به علاوه درصد است. هنگامی که این هزینه ها برای معاملات ارزان قیمت ، 50 سنت و کمتر اعمال می شود ، هزینه های معامله به یک مؤلفه مهم یا حتی غالب قیمت کل خرید تبدیل می شود و از این طریق به طور موثری برای کالاها و خدمات خریداری شده با استفاده از یکی از این پروتکل ها به طور مؤثر ایجاد می شود.

  مجبور کردن هزینه های آنلاین بالاتر از آستانه گزینه های ارائه دهندگان خدمات را کاهش می دهد. خدمات آنلاین که روزنامه ها ، مجلات ، کارهای مرجع و قیمت سهام را ارائه می دهند ، همه موارد جداگانه ای دارند که در صورت جداگانه می توانند ارزان باشند. امکان خرید کالاهای ارزان قیمت ، این خدمات را برای کاربران گاه به گاه در اینترنت جذاب تر می کند. علاوه بر این ، معاملات با قیمت پایین ایمن از انتشارات الکترونیکی Grash-Roots پشتیبانی می کند. کاربرانی که احتمالاً با یک ناشر ناشناخته یک حساب ده دلاری را باز نمی کند ، ممکن است مایل باشد چند سنت را برای خرید یک مقاله جالب خرج کند.

  در این بخش ، ما به چهار گزینه موجود برای تجارت اینترنتی نگاه می کنیم: حساب ها ، جمع آوری ، کارت های اعتباری و پول نقد دیجیتال ، و در مورد اینکه چرا آنها برای تجارت الکترونیکی ارزان قیمت مناسب نیستند ، بحث می کنیم. در بخش بعدی ، ما مدل خود را برای کاهش هزینه ها و ایجاد تجارت الکترونیکی سبک وزن توضیح می دهیم.

  ساده ترین مدل برای تجارت الکترونیکی این است که مشتریان بتوانند حساب های خود را با فروشندگان ایجاد کنند. هنگامی که مشتری می خواهد با فروشنده معامله انجام دهد ، مشتری خود را (ایمن) شناسایی می کند و فروشنده هزینه معامله را به حساب مشتری اضافه می کند. فروشندگان اطلاعات حساب را حفظ می کنند و به طور دوره ای مشتریان را صورتحساب می دهند.

  با حساب ها ، هزینه های معاملات و قیمت ها می تواند نسبتاً پایین باشد ، اما مقدار نسبتاً سربار وجود دارد. ممکن است یک حساب کاربری قبل از زمان ایجاد شود و در طی یک دوره طولانی نگهداری شود. این امر فقط در هنگام فرض رابطه نسبتاً دیرینه بین مشتری و یک فروشنده منطقی است. اغلب حداقل هزینه ماهانه در ارتباط با هر حساب وجود دارد. مشتری برای هر فروشنده حساب های جداگانه ای دارد و فروشنده باید برای هر مشتری حساب خود را حفظ کند. همه این سربارها کاربران گاه به گاه را از انجام خریدهای لحظه ای دلسرد می کنند.

  تجمع با انباشت معاملات در فروشنده ، هزینه های صورتحساب را بیش از توالی معاملات ارزان تر کم می کند تا اینکه از آستانه فراتر رود. تجمع شکل دیگری از حسابها است و برخی از مشکلات حساب را به اشتراک می گذارد. اگرچه تنظیم حساب تا حدودی ساده شده است ، اما فروشنده هنوز مشکل حفظ حساب ها ، جمع آوری معاملات به اندازه کافی برای یک بار معقول و نگه داشتن سوابق معامله برای حل اختلاف را دارد. همچنین ، مشتری باید با هزینه های جداگانه از هر فروشنده ، حداقل هزینه حساب و دشواری در رقابت با هزینه های کلاهبرداری مقابله کند.

  یک مدل ساده دیگر برای تجارت الکترونیکی استفاده از کارت اعتباری برای پرداخت هزینه خرید است. مشتریان کارت اعتباری دارند. فروشندگان در شرکت های کارت اعتباری ثبت نام می کنند. مشتریان شماره کارت اعتباری خود را به فروشندگان می دهند. فروشندگان برای پرداخت با شرکت های کارت اعتباری خود تماس می گیرند. شرکت های کارت اعتباری حسابداری و صورتحساب را اداره می کنند. روشهای مستقر (مانند SSL Netscape [13] بر اساس رمزگذاری کلید عمومی RSA [16]) برای اطمینان از انتقال ایمن شماره کارت اعتباری مشتری به فروشنده وجود دارد.

  متأسفانه ، معاملات کارت اعتباری (نسبتاً) گران است زیرا هر خرید شامل برقراری ارتباط با یک سرویس معامله کارت اعتباری متمرکز است. علاوه بر این ، شرکت های کارت اعتباری ویژگی های مختلفی مانند حسابداری ، بیمه و محافظت از کلاهبرداری را ارائه می دهند که به هزینه می افزاید و در هنگام خرید کالاهای ارزان قیمت لازم نیست.

  سرانجام ، مشتریان ممکن است مایل به ارائه شماره کارت اعتباری به فروشنده ای باشند که آنها به خوبی نمی دانند. اگرچه شرکت کارت اعتباری مشتری را در برابر هرگونه ضرر بیمه می کند ، اما هنوز هم مشکلی برای پاکسازی هرگونه مشکل وجود دارد.

  پول نقد دیجیتال به طور معمول توسط یک نهاد معتبر مرکزی (مانند یک بانک) صادر می شود. یکپارچگی پول نقد دیجیتال با امضای دیجیتال صادرکننده تضمین می شود ، به طوری که جعل پول نقد دیجیتال بسیار سخت است. با این حال ، کپی کردن الگوی بیت پول نقد دیجیتال برای تولید و خرج کردن پول نقد یکسان (و به همان اندازه معتبر) بسیار مهم است.

  در یک طرح نقدی دیجیتال آنلاین ، هنگامی که یک فروشنده پول نقد دیجیتالی دریافت می کند ، باید با صادرکننده تماس بگیرد تا ببیند آیا این معتبر است یا خیر. این ارتباطات اضافی باعث می شود سایت مرکزی یک تنگنا باشد و هزینه آن را به معامله اضافه می کند.

  در یک طرح خارج از خط (مانند یکی از پیشنهادات Digicash [2]) ، فروشنده پول نقد دیجیتال را در طول معامله تأیید می کند و سپس بعداً آن را به صادرکننده منتقل می کند تا هزینه های مضاعف را بررسی کند. این طرح هزینه محاسباتی را برای تأیید اعتبار نقدی دیجیتال به فروشنده اضافه می کند و پیام ها و رمزگذاری را به پروتکل اضافه می کند تا منبع هزینه های مضاعف را مشخص کند.

  هدف ما برای Millicent اجازه معاملات ارزان قیمت و در عین حال امن است. ما با استفاده از حساب های مبتنی بر اسکریپت و کارگزاران برای فروش اسکریپت به این هدف می رسیم.

  یک تکه اسکریپ نشان دهنده حسابی است که مشتری با یک فروشنده ایجاد کرده است. در هر زمان، یک فروشنده دارای اسکریپ های برجسته (حساب های باز) با مشتریان اخیرا فعال است. موجودی حساب به عنوان ارزش اسکریپ نگهداری می شود. وقتی مشتری خریدی با اسکریپ انجام می دهد، هزینه خرید از ارزش اسکریپ کسر می شود و اسکریپ جدید (با ارزش جدید/موجودی حساب) به عنوان تغییر برگردانده می شود. هنگامی که مشتری یک سری از تراکنش ها را انجام داد، می تواند ارزش باقیمانده اسکریپ را "نقد" کند (حساب را ببندد).

  کارگزاران به عنوان واسطه حسابداری بین مشتریان و فروشندگان عمل می کنند. مشتریان با کارگزاران روابط بلندمدت برقرار می کنند، تقریباً به همان روشی که با یک بانک، شرکت کارت اعتباری یا ارائه دهنده خدمات اینترنتی منعقد می کنند. کارگزاران اسکریپ فروشنده را به عنوان خدماتی به مشتریان و فروشندگان می خرند و می فروشند. اسکریپ کارگزار به عنوان یک ارز رایج برای مشتریان برای استفاده در هنگام خرید اسکریپ فروشنده و برای فروشندگانی که به عنوان بازپرداخت برای اسکریپ خرج نشده استفاده می کنند.

  Millicent سربار حساب ها را به چند روش کاهش می دهد:

  هزینه های ارتباطی با تأیید اسکریپ به صورت محلی در سایت فروشنده کاهش می یابد. در طول یک تراکنش معمولی تقریباً هیچ هزینه ارتباطی خاص Millicent وجود ندارد. همچنین نیازی به سرور متمرکز یا پروتکل پردازش تراکنش گران قیمت نیست.

  در یک طرح متمرکز، سایت مرکزی یک گلوگاه است. ارائه دهنده باید قدرت محاسباتی کافی برای مدیریت اوج نرخ تراکنش داشته باشد. در Millicent، هیچ سرور مرکزی وجود ندارد. کارگزاران زیادی می توانند وجود داشته باشند، یک کارگزار فقط در کسری از معاملات بین مشتری و فروشنده شرکت دارد و معاملاتی که شامل یک کارگزار می شود سبک وزن هستند.

  در اکثر طرح‌های مبتنی بر حساب، فروشنده موجودی حساب را حفظ می‌کند. در Millicent، مشتری موجودی حساب را حفظ می‌کند -- این موجودی در اسکریپ که توسط مشتری نگهداری می‌شود کدگذاری می‌شود. هیچ خطری برای فروشنده وجود ندارد زیرا امضای دیجیتال مانع از تغییر ارزش اسکریپ توسط مشتری می شود. از آنجایی که اسکریپ حاوی موجودی حساب و اثبات صحت آن مقدار است، فروشنده نیازی به جستجوی موجودی مشتری ندارد و فعالیت دیسک را ذخیره می کند.

  Millicent بهترین گزینه برای یک سری معاملات ارزان قیمت و معمولی است. ما برای ایجاد حساب اولیه بین کارگزاران و مشتریان و کارگزاران و فروشندگان به پروتکل های دیگر تکیه خواهیم کرد. سایر پروتکل‌های با ارزش بالاتر نیز برای انتقال وجوهی که هنگام تسویه حساب‌ها به صورت دوره‌ای رخ می‌دهد، استفاده می‌شود.

  مدل امنیتی Millicent بر این فرض استوار است که اسکریپ برای مقادیر کم استفاده می شود. رفتار مردم و کسب‌وکارها با سکه‌ها متفاوت از برخورد با اسکناس‌ها است، و با اسکناس‌های کوچک متفاوت از اسکناس‌های بزرگ رفتار می‌کنند. در Millicent، ما مردم را تصور می کنیم که با اسکریپ همانطور رفتار می کنند که با تغییر در جیب خود رفتار می کنند.

  از آنجایی که مردم هنگام خرید آب نبات از دستگاه خودپرداز نیازی به رسید ندارند، هنگام خرید یک کالا با استفاده از اسکریپ نیازی به رسید ندارند. اگر آنچه را که پرداخت کرده اند دریافت نکنند، شکایت می کنند و بازپرداخت می کنند. اگر هر از چند گاهی یک سکه گم می کنند، خیلی ناراحت نیستند.

  ما انتظار داریم که کاربران در یک زمان چند دلار اسکریپ داشته باشند. ما انتظار نداریم که آنها صدها و یا حتی ده ها دلار اوراق قرضه داشته باشند. در نتیجه، اسکریپ ارزش دزدیدن ندارد مگر اینکه بتوانید مقدار زیادی از آن را بدزدید. و اگر زیاد دزدی کنی، گرفتار می شوی.

  Millicent روابط اعتماد نامتقارن را بین این سه نهاد - مشتریان ، کارگزاران و فروشندگان فرض می کند. فرض بر این است که کارگزاران قابل اعتماد ترین ، سپس فروشندگان و سرانجام مشتریان هستند. تنها زمانی که مشتریان باید به آنها اعتماد کنند ، وقتی از مشکلات خدمات شکایت می کنند.

  ما معتقدیم که کارگزاران تمایل به مؤسسات مالی بزرگ ، مشهور و معتبر (مانند ویزا ، مستر کارت و بانک ها) یا ارائه دهندگان عمده اینترنت یا خدمات آنلاین دارند (مانند CompuServe ، NetCom یا AOL). ما انتظار داریم که بسیاری از فروشندگان طیف کاملی از اندازه و اعتماد به نفس را مانند دنیای واقعی پوشش دهند. سرانجام ، تعداد زیادی از مشتریانی وجود خواهند داشت که به طور کلی افراد قابل اعتماد هستند.

  سه عامل باعث می شود که کارگزار جعلی بی سود باشد. اول ، نرم افزار مشتری و فروشنده می توانند به طور مستقل اسکریپت را بررسی کرده و مانده حساب را حفظ کنند ، بنابراین هرگونه کلاهبرداری توسط کارگزار قابل تشخیص است. دوم ، مشتریان به هیچ وجه اسکریپت زیادی را در خود جای نمی دهند ، بنابراین یک کارگزار برای ایجاد سود بیشتر مجبور به انجام معاملات کلاهبرداری زیادی می شود و این باعث می شود که آنها گرفتار شوند. سرانجام ، شهرت یک کارگزار برای جذب مشتری مهم است و اگر مشتریان با کارگزار مشکلی داشته باشند ، یک کارگزار به سرعت اعتبار خود را از دست می دهد. تجارت تکراری مشتریان فعال برای یک کارگزار با ارزش تر از اسکریپری است که می تواند دزدی کند.

  کلاهبرداری فروشنده شامل تهیه کالا برای اسکریپت معتبر است. اگر این اتفاق بیفتد ، مشتریان از کارگزار خود شکایت می کنند و کارگزاران فروشندگانی را که باعث شکایات زیادی می شوند ، رها می کنند. این به عنوان یک مکانیسم پلیس مؤثر عمل می کند ، زیرا فروشندگان برای انجام آسان تجارت در Millicent به یک کارگزار نیاز دارند.

  در نتیجه ، پروتکل Millicent برای جلوگیری از کلاهبرداری مشتری (جعل و هزینه های مضاعف) ضمن ارائه تشخیص غیرمستقیم کارگزار و کلاهبرداری فروشنده ، کمرنگ می شود.

  امنیت معاملات Millicent از جنبه های مختلفی حاصل می شود.

  همه معاملات محافظت می شوند

  هر معامله Millicent مستلزم آن است که مشتری راز مرتبط با اسکریپت را بشناسد. این پروتکل هرگز راز را به طور واضح نمی فرستد ، بنابراین به دلیل استراق سمع هیچ خطری وجود ندارد. هیچ قطعه ای از اسکریپت قابل استفاده مجدد نیست ، بنابراین حمله پخش مجدد شکست خواهد خورد. هر درخواست با راز امضا می شود ، بنابراین هیچ راهی برای رهگیری اسکریپت و استفاده از اسکریپت برای ایجاد درخواست متفاوت وجود ندارد.

  معاملات ارزان قیمت می تواند به امنیت ارزان قیمت متکی باشد: ارزش استفاده از منابع رایانه ای گران قیمت برای سرقت اسکریپت ارزان قیمت نیست. علاوه بر این ، برای به دست آوردن پول زیادی ، بسیاری از کاربردهای غیرقانونی از اسکریپت را انجام می دهد ، و این احتمال گرفتار شدن را افزایش می دهد.

  • این ارزش در یک فروشنده خاص دارد.
  • فقط یک بار می توان هزینه کرد.
  • مقاوم در برابر دستکاری و جعل آن سخت است.
  • این فقط می تواند توسط صاحب حق آن هزینه شود.
  • این می تواند به طور مؤثر تولید و تأیید شود.
  • متن اسکریپ ارزش خود را نشان می دهد و فروشنده را مشخص می کند.
  • این اسکریپت دارای شماره سریال برای جلوگیری از هزینه های مضاعف است.
  • یک امضای دیجیتالی برای جلوگیری از دستکاری و جعل جعل وجود دارد.
  • مشتری هر استفاده از اسکریپت را با راز همراه با اسکریپت امضا می کند.
  • امضاها را می توان با استفاده از یک عملکرد سریع هش یک طرفه (مانند MD5 [15] یا SHA [11]) ایجاد و بررسی کرد.

  سه راز در تولید، اعتبارسنجی و هزینه کردن اسکریپ وجود دارد. برای اثبات مالکیت اسکریپ، یک راز به مشتری ارسال می شود. فروشنده از یک رمز، master_customer_secret استفاده می کند تا مشتری_secret را از اطلاعات مشتری در اسکریپ استخراج کند. راز سوم، master_scrip_secret، توسط فروشنده برای جلوگیری از دستکاری و جعل استفاده می شود.

  اسرار همگی به گونه ای به کار می روند که بدون افشای راز، آگاهی از راز را نشان می دهد. برای تأیید یک پیام، راز به پیام الحاق می‌شود و نتیجه برای تولید یک امضا هش می‌شود. پیام (بدون راز) و امضا - به دلیل ماهیت یک طرفه تابع هش - آگاهی از راز را ثابت می کند، زیرا امضای صحیح تنها در صورتی بدست می آید که راز را بدانید.

  اسکریپ دارای فیلدهای زیر است (شکل 1):

  • فروشنده فروشنده اسکریپ را شناسایی می کند.
  • Value ارزش اسکریپ را می دهد.
  • ID# شناسه منحصر به فرد اسکریپ است. بخشی از آن برای انتخاب master_scrip_secret مورد استفاده برای گواهی استفاده می شود.
  • Cust_ID# برای تولید راز مشتری استفاده می شود. بخشی از Cust_ID# برای انتخاب master_customer_secret استفاده می شود که در تولید راز مشتری نیز استفاده می شود.
  • Expires زمان انقضای اسکریپ است.
  • Props داده های اضافی هستند که ویژگی های مشتری (سن، وضعیت محل سکونت و غیره) را برای فروشنده توصیف می کنند.
  • گواهی امضای اسکریپ است.

  اسکریپ در دو مرحله اعتبار سنجی می شود. ابتدا (شکل 2)، گواهی مجدداً محاسبه شده و با گواهی ارسال شده با اسکریپ بررسی می شود. اگر اسکریپ دستکاری شده باشد، این دو گواهی مطابقت ندارند. دوم، یک شناسه یکتا (ID#) در بدنه اسکریپ گنجانده شده است و فروشنده می تواند با دیدن اینکه آیا آن شناسه را به عنوان قبلاً خرج شده ثبت کرده است، هزینه مضاعف را بررسی کند. تولید و اعتبارسنجی اسکریپ هر کدام به کمی دستکاری متن و یک عملیات هش نیاز دارد. تا زمانی که راز آن مشخص نباشد، اسکریپ را نمی توان جعل یا تغییر داد.

  فروشنده شناسه منحصربه‌فرد هر قطعه اسکریپ را که خرج می‌شود، ثبت می‌کند، به طوری که نمی‌توان آن را مجدداً با تقلب خرج کرد. برای نجات فروشنده از حفظ این رکورد برای همیشه، به هر قطعه اسکریپ یک زمان انقضا داده می شود. پس از انقضای اسکریپ، فروشنده دیگر نگران خرج شدن مجدد آن نیست و می تواند رکورد خود را از اسکریپ پاک کند.

  مشتریان مسئول تمدید یا نقد کردن اسکریپ قبل از انقضای آن هستند. اسکریپ قدیمی به فروشنده ارسال می شود که اسکریپ جدید را با زمان انقضای بعدی (و شماره سریال جدید) برمی گرداند. فروشندگان ممکن است هزینه کمی را برای این سرویس دریافت کنند و کاربران را از دریافت اسکریپ بیشتر از آنچه در آینده نزدیک نیاز دارند، منصرف کند.

  اسکریپ همچنین دارای فیلدهایی برای ذخیره خواص است که هنگام تولید اسکریپ توسط فروشنده یا کارگزار درج می شود. فیلدهای دقیق دارایی و مقادیر آنها به توافق بین کارگزاران و فروشندگان بستگی دارد. کارگزاران هنگام ایجاد حساب کاربری خود اطلاعات را از مشتریان دریافت می کنند و هنگام فروش اسکریپ فروشنده، مجموعه ای از قوانین را اجرا می کنند. البته فروشندگان مختارند که هر خاصیتی را که می خواهند در اسکریپ هایی که خودشان تولید می کنند بگنجانند.

  اطلاعاتی مانند وضعیت محل سکونت یا سن مصرف کننده به فروشنده در تصمیم گیری برای فروش کمک می کند. فقط در صورتی می توان مواد بزرگسال را خریداری کرد که اسکریپ نشان دهد که مشتری به اندازه کافی پیر است. هزینه‌های مالیات فروش دولتی می‌تواند به ملکی که در فهرست موجود است بستگی داشته باشد.

  اسکریپت اساس خانواده ای از پروتکل های Millicent است. ما سه مورد از آنها را شرح خواهیم داد و سادگی ، رازداری و امنیت آنها را مقایسه خواهیم کرد.(شرح مفصلی از پروتکل ها در پیوست است.)

  اولین ، "اسکریپت در شفاف" ، ساده ترین و کارآمدترین پروتکل است. این پایه و اساس دو پروتکل دیگر است ، اما ممکن است در عمل مفید نباشد زیرا خیلی ناامن است. دوم ، "خصوصی و ایمن" امن است و حریم خصوصی خوبی را ارائه می دهد ، اما گران تر است. سوم ، "ایمن بدون رمزگذاری" نیز ایمن است ، اما برای بهره وری بیشتر حریم خصوصی را معامله می کند.

  در ساده ترین پروتکل Millicent ممکن است ، مشتری فقط یک قطعه اسکریپت ناخوشایند را به صورت واضح (یعنی رمزگذاری نشده یا به هیچ وجه محافظت نمی شود) و به همراه هر درخواست به فروشنده ارسال می کند. فروشنده نتیجه مورد نظر را به همراه یک قطعه جدید از اسکریپت (همچنین در روش روشن) به عنوان تغییر باز می گرداند.

  این پروتکل تقریباً هیچ امنیتی را ارائه نمی دهد: شخص ثالث استراق سمع می تواند اسکریپت را به عنوان تغییر بازگرداند و خودش از آن استفاده کند. هنگامی که صاحب حق بعداً تلاش کرد تا اسکریپت را خرج کند ، فروشنده سابقه ای از آن را که قبلاً صرف شده بود ، خواهد داشت و از این درخواست امتناع می ورزد.

  برای افزودن امنیت و حریم خصوصی به پروتکل Millicent ، ما یک راز مشترک بین دو طرف ایجاد می کنیم و سپس از راز برای تنظیم یک کانال ارتباطات ایمن با استفاده از یک روش رمزگذاری کارآمد و متقارن استفاده می کنیم (مانند DES [10] ، RC4 [17]، یا ایده [6]).

  در Millicent ، از اسکریپت می توان برای ایجاد این کلید مشترک استفاده کرد. هنگامی که مشتری یک قطعه اولیه اسکریپت را برای یک فروشنده خریداری می کند ، یک راز بر اساس شناسه مشتری ایجاد می شود و با اسکریپت ایمن است (شکل 3). این امر مستلزم این است که معامله با استفاده از برخی از پروتکل های امن غیرقانونی انجام شود ، یا اینکه اسکریپت با استفاده از یک معامله Secure Millicent خریداری شود.

  فروشنده به طور مستقیم راز مرتبط با قطعه اسکریپت را ضبط نمی کند. در عوض ، شناسه مشتری (CUST_ID#) اسکریپت امکان محاسبه سریع راز را فراهم می کند. شناسه مشتری باید هر زمان که اسکریپت به مشتری جدید منتقل شود ، منحصر به فرد باشد ، اما نیازی به ارتباطی با هویت مشتری ندارد.

  هنگامی که فروشنده درخواست را دریافت می کند ، او راز مشتری را از شناسه مشتری در اسکریپت استخراج می کند ، کلید پیام را از راز مشتری گرفته و از کلید پیام برای رمزگشایی درخواست استفاده می کند. اسکریپت تغییر را می توان به روش واضح برگرداند ، در حالی که پاسخ و هرگونه اسرار جدید به مشتری رمزگذاری شده توسط کلید پیام بازگردانده می شود.

  در این پروتکل درخواست و پاسخ کاملاً خصوصی نگه داشته می شود. مگر اینکه یک استراق سمع راز مشتری را بشناسد ، او نمی تواند پیام ها را رمزگشایی کند. علاوه بر این ، یک Eavesdropper نمی تواند اسکریپت را سرقت کند زیرا بدون دانستن راز مشتری نمی تواند هزینه شود.

  بخش قبلی توضیح می دهد که چگونه راز مشترک توسط مشتری و فروشنده می تواند برای دستیابی به امنیت و حریم خصوصی مورد سوء استفاده قرار گیرد. اما یک کانال رمزگذاری شده تمام عیار ممکن است برای برخی از برنامه های کاربردی بیش از حد باشد. در این مورد ، سومین نوع پروتکل ، ما از حریم خصوصی درخواست و پاسخ برای از بین بردن استفاده از رمزگذاری استفاده می کنیم.

  همانطور که در پروتکل قبلی ، مشتری با اطمینان یک قطعه اولیه اسکریپت و راز مشتری را دریافت می کند. برای خرید ، مشتری درخواست ، اسکریپت و "امضای" درخواست را به فروشنده ارسال می کند. امضای به همان روشی که گواهی اسکریپت تولید می شود تولید می شود. اسکریپت و درخواست با راز مشتری هماهنگ می شوند. مشتری یک عملکرد هش یک طرفه رمزنگاری کارآمد را بر روی این رشته اجرا می کند و هش حاصل را به عنوان امضای ارسال می کند.

  هنگامی که فروشنده درخواست را دریافت می کند ، او راز مشتری را از اسکریپت استخراج می کند و امضای درخواست را بازسازی می کند. اگر اسکریپت یا درخواست به هر طریقی دستکاری شده باشد ، امضای مطابقت نخواهد داشت.(شکل 4).

  فروشنده اکنون درخواست را انجام می دهد و یک قطعه جدید از اسکریپت را به عنوان تغییر باز می گرداند. Scrip Change همان شناسه مشتری را به عنوان اسکریپت ارسال شده با درخواست به اشتراک می گذارد ، به طوری که می توان از راز اصلی مشتری برای صرف تغییر استفاده کرد. نیازی به رمزگذاری هیچ یک از پاسخ ها نیست. یک Eavesdropper نمی تواند اسکریپت را سرقت کند زیرا امضای درخواست بدون دانستن راز مشتری نمی تواند انجام شود. فروشنده ممکن است پاسخ را با راز مشتری امضا کند تا صحت مشتری را اثبات کند.

  بنابراین ، با تنها چند هش ، Millicent یک پروتکل سبک و ایمن را فراهم می کند.

  کارگزاران حساب مشتریان و فروشندگان را حفظ می کنند و همه معاملات پول واقعی را انجام می دهند. مشتری با استفاده از روش دیگری (مانند کارت اعتباری یا یک سیستم تجارت الکترونیکی با امنیت بالاتر) برای خرید برخی از اسکریپت های کارگزار ، یک حساب کاربری با یک کارگزار ایجاد می کند. مشتری سپس از اسکریپت کارگزار برای خرید اسکریپت فروشنده استفاده می کند.

  فروشنده و کارگزار رابطه تجاری طولانی مدت دارند. کارگزار اسکریپت فروشنده را به مشتریان می فروشد و به فروشنده می پردازد. برای نحوه دریافت کارگزار اسکریپت فروشنده ، می تواند مدلهای تجاری مختلفی وجود داشته باشد ، به عنوان مثال ، پیش پرداخت ، فروش حمل و نقل یا تولید دارای مجوز را پرداخت می کند. در همه مدل ها ، کارگزار می تواند اسکریپت فروش سود را ایجاد کند زیرا او به فروشنده (با تخفیف) برای اسکریپت به صورت عمده پرداخت می کند و قطعات جداگانه را به مشتریان می فروشد.

  هنگامی که مشتری می خواهد خرید کند ، مشتری برای به دست آوردن اسکریپت فروشنده لازم با کارگزار تماس می گیرد. مشتری از اسکریپت کارگزار خود برای پرداخت اسکریپت فروشنده با استفاده از پروتکل Millicent استفاده می کند. کارگزار اسکریپت فروشنده جدید را به همراه تغییر در اسکریپت کارگزار برمی گرداند.

  ما سه روش را بررسی خواهیم کرد که کارگزار اسکریپت فروشنده را دریافت می کند. مدل "انبار اسکریپت" رابطه گاه به گاه بین کارگزار و فروشنده را فرض می کند. مدل "تولید کننده اسکریپت دارای مجوز" رابطه قابل توجهی و طولانی مدت بین کارگزار و فروشنده را فرض می کند. مدل "کارگزار چندگانه" رابطه بین کارگزاران را فرض می کند ، اما نیازی به ارتباطی بین فروشنده و کارگزار ندارد.

  هنگامی که کارگزار به عنوان یک انبار اسکریپت عمل می کند ، کارگزار چندین قطعه اسکریپت را از یک فروشنده خریداری می کند. کارگزار اسکریپت را ذخیره می کند و قطعات را یک بار به مشتریان می فروشد (شکل 5B-5D).

  این مدل هیچ رابطه خاصی را بین فروشنده و کارگزار فرض نمی کند. زمانی که مشتریان کارگزار تقاضای کم تا متوسطی برای اسکریپ آن فروشنده داشته باشند، بهترین کار را دارد. کارگزار از پروتکل Millicent برای خرید اسکریپ از فروشنده به همان روشی که مشتری خرید می کند استفاده می کند. فروش اسکریپ در بلوک‌های بزرگ برای فروشنده کارآمدتر است زیرا هزینه‌های ارتباطی و تراکنش‌های مالی بر روی تمام قطعات اسکرپ مستهلک می‌شوند. ما فرض می کنیم که فروشنده نوعی تخفیف حجمی را برای تشویق کارگزاران به خرید بلوک های بزرگ اسکریپ ارائه می دهد. کارگزار زمانی سود می برد که اسکریپ را به قیمت کامل به مشتریان بفروشد. فروشنده برای اطمینان از هرگونه ویژگی مشتری کدگذاری شده در اسکریپ به کارگزار وابسته است.

  اگر مشتریان یک کارگزار اسکریپ زیادی را برای یک فروشنده خاص خریداری کنند، ممکن است برای فروشنده ای مطلوب باشد که به کارگزار برای تولید اسکریپ فروشنده «مجوز» بدهد. این به این معنی است که کارگزار اسکریپ تولید می کند که فروشنده می تواند آن را تأیید کرده و بپذیرد. فروشنده حق تولید اسکریپ را با استفاده از یک master_scrip_secret معین، یک سری شناسه اسکریپ، master_customer_secret و یک سری از شناسه های مشتری به کارگزار می فروشد. فروشنده می تواند اسکریپ دارای مجوز را تأیید کند زیرا master_scrip_secret از سری ID# اسکریپ و master_customer_secret از سری شناسه مشتری شناخته می شود.

  کارگزاران اسکریپ را تولید می کنند و از مشتریان پول جمع آوری می کنند. فروشندگان ارزش کل اسکریپ را که از یک کارگزار خاص نشات می گیرد، ثبت می کنند. هنگامی که تمام اسکریپ تولید شده تحت یک قرارداد خاص منقضی شده است، کارگزاران و فروشندگان می توانند تسویه حساب کنند. کارگزار احتمالاً برای تولید اسکریپ مقداری کارمزد می گیرد.

  یک مجوز یک سری خاص (محدوده منحصر به فرد از شناسه ها - ID#) از اسکریپ ها را برای یک دوره زمانی معین پوشش می دهد، و اسرار مشترک بین کارگزار و فروشنده فقط برای آن سری اعمال می شود. یک فروشنده می تواند با ارائه سری ها و اسرار مختلف به هر یک، مجوزهایی را برای کارگزاران مختلف صادر کند. البته، یک فروشنده می تواند اسکریپ خود را با استفاده از سری ها و رازهای خصوصی خود تولید کند.

  صدور مجوز تولید اسکریپ برای فروشنده و دلال کارآمدتر از مدل انبار اسکریپ است. ارتباط کمتری وجود دارد زیرا مجوز برای انتقال کوچکتر از چند قطعه اسکریپ است. فروشنده محاسبات کمتری انجام می دهد زیرا مجبور نیست خود اسکریپ را تولید کند. کارگزار مجبور نیست بلوک های بزرگی از اسکریپ را ذخیره کند، زیرا می تواند اسکریپ را در صورت تقاضا تولید کند. علاوه بر این، به کارگزار اجازه می دهد تا ویژگی های کاربر خاص را در هر قطعه از اسکریپ که تولید می کند رمزگذاری کند.

  در محیطی که چندین کارگزار وجود دارد، مشتری یک کارگزار ممکن است بخواهد از یک فروشنده مرتبط با کارگزار دیگری خرید کند. اگر فروشنده فقط بخواهد با کارگزار خود یک حساب داشته باشد (شاید برای ساده کردن حسابداری)، مشتری باید از طریق کارگزار فروشنده برای خرید اسکریپ فروشنده مراجعه کند.

  کل تراکنش به این صورت خواهد بود:

  • مشتری از کارگزار خود اسکریپ فروشنده می خواهد.
  • کارگزار مشتری سعی می کند حسابی را با فروشنده تنظیم کند.
  • فروشنده نام کارگزار مشتری را به دلال مشتری می گوید.
  • کارگزار مشتری اسکریپ کارگزاری را از کارگزار فروشنده می خرد.
  • کارگزار مشتری اسکریپ کارگزار فروشنده را به مشتری برمی گرداند.
  • مشتری اسکریپ فروشنده را از کارگزار فروشنده می خرد.
  • مشتری از اسکریپ فروشنده در فروشنده استفاده می کند.

  ایده تولید اسکریپ با مجوز را می توان گسترش داد تا کارگزاران بتوانند اسکریپ دلالی را برای کارگزاران دیگر تولید کنند.

  نمودارهای زیر (شکل 5A-E) مراحل مربوط به یک جلسه کامل (از جمله کارگزار خرید اسکریپت از فروشنده) را ارائه می دهد. مرحله اولیه (شکل 5a) فقط یک بار در هر جلسه اتفاق می افتد. مرحله دوم (شکل 5b) هر بار که مشتری هیچ اسکریپت ذخیره شده ای برای یک فروشنده ندارد ، اتفاق می افتد. مرحله سوم (شکل 5C) فقط در صورتی اتفاق می افتد که کارگزار برای خرید اسکریپت با فروشنده تماس بگیرد. برای تولید اسکریپت دارای مجوز لازم نیست. مرحله چهارم (شکل 5D) کارگزار را نشان می دهد که اسکریپت فروشنده را به مشتری باز می گرداند. مرحله پنجم (شکل 5E) مشتری را با استفاده از اسکریپت برای خرید از فروشنده نشان می دهد.

  مرحله آخر (شکل 5F) یک معامله معمولی را نشان می دهد. مشتری قبلاً اسکریپت فروشنده دارد و از آن برای خرید استفاده می کند. هیچ پیام یا تعامل اضافی با کارگزار وجود ندارد.

  ما اجرای اولیه Millicent [9] متشکل از مجموعه ای از کتابخانه ها را تولید کرده ایم ، و یک فروشنده و کارگزار که با استفاده از کتابخانه ها برای معاملات Millicent در یک شبکه با استفاده از TCP/IP نوشته شده است. اندازه گیری های ما نشان می دهد که پروتکل Millicent به اندازه کافی برای خریدهای فرعی کارآمد است. اجرای فروشنده ما می تواند حدود 1000 درخواست میلی لیتر در ثانیه (در یک آلفاست دیجیتال 400 4/233) را تأیید کند و از این تعداد ، بیشتر اوقات به انتقال اتصال TCP می رود.

  با استفاده از معاملات با هزینه صفر ، اسکریپت Millicent می تواند به عنوان یک قابلیت توزیع شده استفاده شود. با استفاده از این جنبه از اسکریپت ، اولین کاربرد ما از Millicent در مجموعه احراز هویت مانند Kerberos [5] برای خدمات فایروال شبکه ما است. ما یک رله TCP مبتنی بر جوراب [7] ، Rlogin Daemon ، FTP Daemon و Rlogin ، Telnet و FTP را اصلاح کرده ایم تا از اسکریپت Millicent برای انتقال اطلاعات تأیید اعتبار استفاده کنند. کاربر برای دریافت اسکریپت از یک کارگزار احراز هویت ، یک احراز هویت رمزنگاری (چالش/پاسخ رمزنگاری) را انجام می دهد. سپس ، برای بقیه روز ، کاربر می تواند از اسکریپت تأیید اعتبار برای خرید اسکریپت برای خدمات خاص فایروال استفاده کند.

  ما همچنین در حال کار بر روی خدمات World World Were (WWW) مبتنی بر Millicent هستیم. ما یک شبه شبه محلی ایجاد کرده ایم که تمام درخواست های مرورگر WWW مشتری را رهگیری می کند و هدر HTTP را اصلاح می کند تا اسکریپت را در صورت لزوم اضافه کند. سرور www درخواست HTTP را برای اسکریپت کافی برای خرید صفحه بررسی می کند و صفحه را با تغییر در پاسخ HTTP باز می گرداند. شبه پروکسی قبل از ارسال پاسخ به مرورگر ، تغییر را استخراج می کند. هنگامی که Millicent محبوب می شود ، عملکرد شبه پروکسی را می توان با مرورگر ادغام کرد.

  دامنه برنامه های بالقوه برای Millicent بسیار گسترده است. با استفاده از فناوری فعلی ، Millicent برای معاملات از چند دلار تا کمی یک دهم درصد مناسب است. قسمت بالایی از مدل اعتماد برای کارگزاران و در دسترس بودن پروتکل های جایگزین مناسب برای معاملات بالاتر از چند دلار است ، در حالی که محدوده پایین از یک تخمین محافظه کارانه بر اساس هزینه های محاسباتی یک کارگزار حاصل می شود. این محدوده قیمت بیشتر خدمات چاپی و اطلاعاتی را که در قالب آنلاین در دسترس خواهد بود - مجلات ، روزنامه ها ، دائر ycl المعارف ها ، شاخص ها ، خبرنامه ها و بانکهای اطلاعاتی را در بر می گیرد.

  مکی ماسون و واریان [8] استدلال می کنند که با توسعه اینترنت ، فشار بیشتری برای هزینه های مبتنی بر استفاده وجود خواهد داشت. خدمات اینترنتی رایگان فعلی مانند پست الکترونیکی ، نقل و انتقالات پرونده ، تلفن اینترنتی و کنفرانس از طریق تلفن باید هزینه شود. در پایین ترین سطح ، آنها تخمین می زنند که هزینه انتقال یک بسته در ستون فقرات اینترنت یک شش صدم یک درصد است. ما اعتقاد نداریم که Millicent برای چنین هزینه های سطح بسته کاملاً کارآمد است. برای اینها پیشنهادهایی مانند جاده ابریشم دیجیتال غیر کریپتوگرافی وجود دارد [4]. ما معتقدیم که Millicent می تواند برای هزینه های هر اتصال برای این خدمات استفاده شود.

  ما فرصت های رو به رشد برای خدمات اینترنتی ارزان قیمت را مشاهده می کنیم. این سرویس ها به یک پروتکل تجارت الکترونیکی مناسب نیاز دارند. ما معتقدیم که پروتکل Millicent کاندیدای خوبی برای این پروتکل است.

  در زیر شرح دقیق تری از پروتکل Millicent برای مشتری و فروشنده است. تعامل بین مشتری و کارگزار به همان پروتکل متکی است ، همانطور که در بدنه اصلی مقاله توضیح داده شده است.

  ما از نمادهای زیر استفاده می کنیم:

  X, Y, Z represents the string encoding the tuple X , Y , Z . H(X) is the result of hashing X with a cryptographic hash function, such as MD5. Y is the result of encrypting X with a cryptographic function, such as DES, under the key Y . A->ب: x به این معنی است که A X را به B ارسال می کند.

  قبل از ارائه پروتکل ، زمینه های آن را شرح می دهیم. ابتدا برخی از مواد تشکیل دهنده اسکریپت را لیست می کنیم. اسکریپت شامل نام فروشنده ، برخی از خصوصیات مشتری ، یک مقدار و زمان انقضا است:

  Vendor_ID: یک شناسه منحصر به فرد (یا نام) برای فروشنده. غرفه ها: هر داده ای که خصوصیات مشتری را توصیف می کند (احتمالاً از جمله نام). مقدار: مقدار اسکریپت. EXP: زمان انقضا برای اسکریپت. مشتری و فروشنده یک درخواست و پاسخ ایجاد می کنند. هر دوی این رشته های دلخواه هستند.

  درخواست: درخواست مشتری. پاسخ: پاسخ از فروشنده. ما فرض می کنیم که ، با فرمت آن ، پاسخ از درخواست قابل تشخیص است. علاوه بر این ، پروتکل به اسرار مختلف و شناسه های مربوطه برای آن رازها متکی است:

  master_script_secret: راز مورد استفاده برای صدور گواهینامه اسکریپت. master_script_secret فقط به فروشنده شناخته شده است (وقتی فروشنده اسکریپت خود را تولید می کند) یا فقط به فروشنده و کارگزار (هنگامی که کارگزار ممکن است اسکریپت تولید کند). id_series#: شناسه master_script_secret. فروشنده می تواند id_series# را به master_script_secret نقشه برداری کند. id_مان#: یک شناسه منحصر به فرد ، مانند شماره دنباله. فروشنده ID_SONEENCE# را برای حداکثر یک معامله در رابطه با id_series# می پذیرد. شناسه# = id_series# ، id_ownence# master_customer_secret: راز مورد استفاده برای تولید اسرار مشتری. master_customer_secret فقط به فروشنده و کارگزار شناخته شده است. CUST_ID_SERIES#: شناسه master_customer_secret. فروشنده می تواند cust_id_series# را به master_customer_secret نقشه برداری کند. CUST_ID_SONEENCE#: یک شناسه منحصر به فرد ، مانند شماره دنباله. همراه با cust_id_series# ، مشتری را مشخص می کند. CUST_ID# = CUST_ID_SERIES# ، CUST_ID_ONEENCE# CUSTERCET_SECRET = H (CUST_ID# ، MASTER_CUSTOMER_SECRET) راز را که فروشنده یا کارگزار برای مشتری ارسال می کند. مشتری این مقدار را به همراه CUST_ID# (اما نه Master_Customer_Secret) دریافت می کند. مشتری می تواند فروشنده_id و CUST_ID# را به Customer_Secret نقشه برداری کند. هم فروشنده و هم کارگزار می توانند مشتری_ secret را از cust_id# و master_customer_secret تولید کنند. هیچ کس دیگری مشتری را نمی شناسد. اسکریپت با ترکیب تمام زمینه های ذکر شده در بالا ، به شرح زیر تولید می شود:

  id_material = فروشنده_ید ، شناسه# ، CUST_ID# CERT_MATERIAL = PROPS ، مقدار ، exp scrip_body = id_material ، cert_material گواهی = h (scrip_body ، master_script_secret) این یک گواهی است که اثبات صحت scrip_body برای مشتری همراه با cust_id#. scrip = scrip_body ، گواهی فروشنده یا کارگزار اسکریپت را به مشتری می دهد. مشتری آن را به همراه یک درخواست به فروشنده ارائه می دهد.

  برای تغییر از معامله ، فروشنده اسکریپت جدید را با یک گواهی جدید صادر می کند. مقادیر جدید ممکن است با موارد قبلی در تمام مؤلفه های آنها به جز CUST_ID# و VENDOR_ID متفاوت باشد. اگر کارگزار در ابتدا master_script_secret را بشناسد و این مقدار یکسان باشد ، کارگزار در اصل قادر به ایجاد تغییر به جای فروشنده است. این ممکن است مطلوب نباشد ، زیرا این امر به معنای اعتماد غیر ضروری فروشنده به کارگزار است. از این رو ، هنگامی که فروشنده تغییر می کند ، برای فروشنده معقول است که از یک Master_Script_Secret جدید برای کارگزار شناخته شود. در هر صورت ، فروشنده باید مقدار جدیدی را برای شناسه# به عنوان محافظت در برابر تکرارها انتخاب کند. ما اسکریپت را برای اسکریپت جدید می نویسیم.

  در روش روشن (ناامن)

  customer -> vendor: scrip, request vendor ->مشتری: اسکریپت ، پاسخ

  customer -> vendor: vendor_id, cust_id#, customer_secret vendor ->مشتری: vendor_id ، cust_id#، customer_secret

  بیشتر ارتباطات برای اصالت و حفظ حریم خصوصی تحت مشتری_سکت است. رمزگذاری کمتر ، با افزایش کارآیی امکان پذیر است. به عنوان مثال ، برخی از قسمت های اسکریپت حساس نیستند و می توانند به صورت واضح ارسال شوند.

  این پاسخ شامل CERT است تا به مشتری اجازه دهد بررسی کند که پاسخ دریافت شده در واقع پاسخی به درخواست است.

  هر دو پیام شامل Vendor_ID و cust_id# به روش روشن می شوند تا به گیرنده اجازه دهد مشتری را تولید کند.

  customer->vendor: scrip, request, H(scrip, request, customer_secret) vendor->مشتری: اسکریپت '، پاسخ ، ح (اسکریپت' ، گواهی ، پاسخ ، مشتری_ secret)

  همه پیام ها به صورت واضح ارسال می شوند ، اما توسط امضاها (بر اساس مشتری_ secret) محافظت می شوند.

  از رمزگذاری استفاده نمی شود و فقط پنج هش در سرور لازم است تا یک درخواست را انجام دهند. هش ها عبارتند از: (1) برای بررسی اسکریپت قدیمی ، (2) برای بازسازی مشتری_secret ، (3) برای بررسی امضای مشتری ، (4) برای تولید اسکریپت جدید ، و (5) برای امضای پاسخ.

  این پاسخ شامل CERT است تا به مشتری اجازه دهد بررسی کند که پاسخ دریافت شده در واقع پاسخی به درخواست است.

  3 اولین شرکت Virtual Holdings ، URL: http://www. fv. com/

  5 J. Kohl ، C. Neuman ، سرویس تأیید اعتبار شبکه Kerberos (V5) ، IETF RFC 1510 ، URL: gopher: //ds2. internic. net/00/rfc/rfc1510. txt

  6 Xuejia Lai ، در مورد طراحی و امنیت رمزهای بلوک ، انستیتوی پردازش سیگنال و اطلاعات ، Eth-Zentrum ، Zurich ، Switzerland ، 1992.

  8 Jeffrey K. Mackie-Mason ، Hal R. Varian. برخی از سؤالات متداول در مورد قیمت گذاری مبتنی بر استفاده. دانشگاه میشیگان ، سپتامبر 1994 ، URL: ftp://gopher. econ. lsa. umich. edu/pub/papers/usefaqs. html

  9 Mark S. Manasse ، روشی برای تجارت الکترونیکی با قیمت پایین ، ثبت اختراع در انتظار ، URL: http://www. research. digital. com/src/personal/mark_manasse/uncommon/ucom. html

  10 موسسه ملی استاندارد و فناوری (NIST) ، استاندارد رمزگذاری داده ها (DES) ، انتشار استانداردهای پردازش اطلاعات فدرال 46-2 ، دسامبر 1993 ، URL: http://www. ncsl. nist. gov/fips/fips46-2. txt

  11 موسسه ملی استاندارد و فناوری (NIST) ، استاندارد هش استاندارد ، FIPS PUB 180-1: Secure Hash Standard ، آوریل 1995 ، URL: http://csrc. ncsl. nist. gov/fips/fip180-1. txt

  15 R. Rivest ، الگوریتم DIGEST پیام MD5 ، IETF RFC 1321 ، URL: gopher: //ds2. internic. net/00/rfc/rfc1321. txt